+1
On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> After taking a break from our previous debate(s) on the issue of which
> response format to support, I would like to suggest the following:
>
> - Support a single response format (including in the user-agent fragment)
> using JSON.
>
> My reason for this is very simple, while right now we have a very limited
> need (key/value pairs), we already have a few proposals which require a
> richer syntax. As OAuth matures, I expect more and more extensions to make
> use of the server response to include additional parameters (flat or
> structured). By using JSON, we can very easily support "namespaces" (i.e. {
> "access_token":"xyz","ext":{...} }), multiple token in a single response, etc.
>
> I appreciate the simplicity in using form-encoded (both code and library
> dependency wise), but long term, it will create a real limitation and will
> require extensions to also specify a different response format.
>
> Those worried about the need to include a JSON library in cases where it will
> be hard to do (embedded devices, etc.), can always extend the protocol to
> provide a way to receive key/value form-encoded pairs. However, they will
> need to figure out how to accommodate structured responses if they wish
> support it. I am certain that the vast majority of implementations will have
> no problem including a JSON library.
>
> Please respond only with yes or no (+/- 1). If you have a different proposal,
> please post it in a new thread. If you are going to vote against this, please
> indicate if your objection is blocking (i.e. you are opposed to it and will
> block a consensus call with this approach).
>
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
