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

[Joseph Smarr <[e-mail]>]

Oh, one other quick benefit of JSON (kind of an extension of point 1 below):

- no ambiguous treatment of whitespace or newlines (this is a problem I've
observed multiple times while helping developers debug OAuth 1.0
implementations--since they just split on & and =, they often don't trim
extra whitespace or newlines that were returned by the server, leading to
those spaces/newlines being part of the parsed attribute values, which then
cause broken signatures and are very hard to debug, since the chars are
invisible when printed). Not a problem with JSON.

On Mon, May 10, 2010 at 3:35 PM, Joseph Smarr <[e-mail]> wrote:

> Let me try to offer some of those "logical, positive statements in favour
> of the technical merits of JSON over the original format choice" for those
> that aren't familiar or haven't gleaned them from the thread thus far:
>
> - unambiguous spec for encoding/decoding (including how to represent spaces
> and unicode chars, both of which are common points of ambiguity in
> url-encoding that lead to bugs, confusion, and lack of ability to use
> built-in libraries, if available). For example, the OAuth PHP library does
> the following: return str_replace('+', ' ', str_replace('%7E', '~',
> rawurlencode($input)) -- yuck!
>
> - easier to read the encoded format (because it has clear sentinel braces,
> quoted attributes, and no url-encoding of parameters; only some backslashing
> of reserved chars)
>
> - widely available libraries with good track records in the wild, and
> increasingly built in to many platforms
>
> - extensible support for more representing more complex data structures in
> the future, if needed
>
> - simple enough that it's easy to understand, but just complex enough that
> it's not too tempting to roll your own parser (which leads empirically to
> better compliance due to use of common libraries)
>
> - more likely to be recognized and understood by developers, since they've
> seen it elsewhere in API response formats
>
> I think that about covers it. Again, it's an objective fact that
> url-encoding has caused confusion and bugs in OAuth 1.0 implementations, and
> it's also an objective fact that JSON has had a very high "just works" rate
> in the wild, to the point that it's the default API response format for many
> widely used APIs from large providers targeting many platforms. So this is
> not a choice based on "fashion", but based on trying to learn from history
> to increase developer success and remove the opportunity for subtle bugs,
> which was one of the major problems with OAuth 1.0a that prompted us to work
> on OAuth 2.0 in the first place.
>
> Thanks, js
>
> On Mon, May 10, 2010 at 11:33 AM, Pid <[e-mail]> wrote:
>
>> On 10/05/2010 15:56, Dick Hardt wrote:
>> >
>> > 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
>>
>> Is that the right message?  There's not much in the way of positive
>> arguments for JSON in that one.
>>
>>
>> > client libraries exist to parse JSON responses
>>
>> Meaning a dependency.
>>
>>
>> > client libraries do NOT exist to parse url encoded responses
>>
>> There aren't libraries to perform that type of decoding because it's
>> trivial, (as you acknowledged).
>>
>>
>> > Implementations of both OAuth 1.0 and WRAP improperly decoded the
>> responses.
>> > Also with reference to: "many developers have been caught just
>> splitting the parameters and forgetting to URL decode the token"
>>
>> With respect, I think this is pretty close to a straw man.  It would be
>> just as easy to argue that developers will make a mess of parsing JSON.
>>
>>
>>
>> Everyone seems to have, (in some cases grudgingly), agreed that it's
>> easier to decode/parse urlencoded data than JSON.
>>
>> There are definitely occasions when using JSON for data description &
>> transmission is advantageous, I just don't think this is one of them.
>> It's a proverbial sledgehammer for a tiny OAuth nut.
>>
>>
>> There should be something positive to say about JSON that establishes
>> why it is a better format for this purpose.
>>
>>
>> >> 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?
>>
>> Sure.  Two of them offer JSON as the default, including the putative
>> 'compromise' option.
>>
>> JSON and XML add complexity, as the editor states.  IMHO it's odd
>> therefore not to select the least complex as the default, if multiple
>> formats are offered.
>>
>>
>>
>> I appreciate that JSON is popular and there is a degree of devil's
>> advocacy to my position here, (as I've already said), but if it's not
>> possible to make a list of logical, positive statements in favour of the
>> technical merits of JSON over the original format choice then it
>> shouldn't be selected as the default.
>>
>>
>> p
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>