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

[Joseph Smarr <[e-mail]>]

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
>
>