Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[Dick Hardt <[e-mail]>]

On 2010-05-10, at 1:11 AM, Pid wrote:

> On 10/05/2010 07:57, Joseph Smarr wrote:
>>> 1. Server Response Format
>> 
>> I vote for B, though I could live with C. (A would make me sad though)
>> 
>> We've had a healthy and reasonable debate about the trade-offs here, but
>> I think the main counterargument for requiring JSON support is that it's
>> not quite yet a "no-brainer" to have JSON support in all environments
>> (e.g. iPhone libraries currently would need to statically link in an
>> available JSON library), whereas the counterarguments for A are the
>> well-documented problems properly decoding url-encoded params from OAuth
>> 1.0, plus the fact that it's not a common response format, whereas JSON
>> (and XML) are. Since I think JSON will continue to increase in use for
>> at least the next several years, the pain associated with requiring JSON
>> is likely to be  higher now than it will be in the future, and it's
>> already low enough that we've had this debate about whether it's already
>> acceptable or not-quite-yet. And JSON has been proven to "just work" in
>> terms of avoiding encoding/decoding headaches in the wild, which for
>> something like OAuth is really critical.
> 
> I don't believe this is an accurate summary.

Are you saying the information is not accurate or not a complete summary?

> 
> I asked for someone in the pro-JSON camp to describe the technical
> merits of that format over url encoded, but to date, there's no one who
> has responded.

per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html

client libraries exist to parse JSON responses
client libraries do NOT exist to parse url encoded responses

Implementations of both OAuth 1.0 and WRAP improperly decoded the responses.

> 
> The options we've been offered seem contrived to support JSON,

would you elaborate on why you think the options presented by the editor were contrived?