+1 with optional extension for XML encoded
-cmort
On 6/10/10 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
