Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

[Pid <[e-mail]>]

On 06/05/2010 18:29, Torsten Lodderstedt wrote:
> +1 , we've got really strong support for JSON and I'm also looking
> forward to review Erans proposal.

Sorry but I am going to continue being Devil's Advocate and keep asking
why JSON is better.  Just saying "we all want it" isn't a positive
argument in favor of the change.

> I checked back today with some of our service and client application
> developers. All of our services offer JSON and XML as transport format,
> no one even considered using application/x-www-form-urlencoded for
> encoding web services responses.
> 
> On the client side, things look even simpler. Our own client application
> generally use JSON on all platforms, incl. smartphones (Android,
> iPhone), handsets (J2ME), home entertainment, and home automation
> devices. Especially the later are really special since they use only a
> small subest of Java (no Java 5, no generics, ..) but JSON is apparently
> not a problem. 

How is it supported, out of interest?

> It is mainly prefered because it combines small
> resource/bandwitdh consumption with ease of use. 

Compared to what? XML obviously, but not x-www-form-urlencoded, I think.

> Our iPhone applications are built using external libraries, the
> experiences are good. As Joseph said, JSON is the "right horse to bet on". 

Why?

> Platform support is getting better in my observation. For example, 
> J2ME supports it and JavaScript is getting native JSON support as well.

Which is good, but doesn't explain why the format is better.

> From my point of view, the Oauth API should fit well into the world of
> HTTP-based services and choosing a completly different encoding
> (application/x-www-form-urlencoded) for OAuth might appear somehow weird
> to developers. 

Eh?  It's hardly a 'completely different' encoding, it's a key component
of most HTTP-based services.  POST?!

Ampersand separated name/value pairs are a familiar format to web
developers, it's not at all an intellectual challenge to consider their
use in a response.

> Moreover, what do developers really gain from that constraint? 

One can ask the same of JSON.  In fact I am asking that.  Still.


> OAuth just provides the tokens for invoking other services
> securly. If all the other services use JSON, applications need JSON
> libraries anyway. So why bother with that question with respect to OAuth?

It's a stretch to make that argument.  There's no guarantee that all
OAuth applications will use JSON unless it's mandated as part of the spec.


application/x-www-form-urlencoded is easy to understand, extremely
simple to implement & parse, has no dependencies and is comprehensively
supported already.

JSON is better than the above because:




(Please fill in the blank)



p

> regards,
> Torsten.
> 
> Am 06.05.2010 17:46, schrieb Joseph Smarr:
>> I'm hearing a lot of confusion on this thread.
>>
>> Evan-of course when attributes are sent *on-the-url* then they get
>> parsed automatically by the HTTP stack, but we're talking about the
>> response body, which every OAuth 1.0 library I've seen writes their
>> own (usually buggy) parser for, and that's where we're proposing to
>> use JSON. 
>>
>> I've seen good JSON library support on every platform I've needed to
>> work for, and it's becoming more and more common (look at Facebook's
>> new Graph API, for instance), so I doubt many platforms will be
>> without JSON parsers for much longer. That being said, it's prudent to
>> look at the state-of-the-art and verify that requiring JSON is not a
>> practical hindrance for iPhone developers, etc., but I still think
>> it's "betting on the right horse" and it's going to be a lot simpler
>> and less error-prone than either url-encoded values or XML.
>>
>> Eran-thanks for agreeing to write something up, and I agree we've got
>> strong support for JSON being the primary/only format for the response
>> body. I look forward to the proposed text and will happily review it.
>>
>> Thanks, js
>>
>> On Wed, May 5, 2010 at 3:35 PM, Pid <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On 05/05/2010 19:49, DeWitt Clinton wrote:
>>     > Having written more than one compliant JSON parser myself, it is
>>     most
>>     > certainly not "trivial", and not something that can be safely
>>     done with
>>     > a regular expression or other hacks.
>>     >
>>     > That said, it's not /hard/, and that alone is no reason not to
>>     mandate
>>     > JSON, but I do want people to be clear about what mandating JSON
>>     means.
>>     >  Clients will need a fully compliant parser.  Period.  If the
>>     OAuth spec
>>     > requires JSON, then it should require it by reference to RFC
>>     4627, not
>>     > just by giving some examples that demonstrate the curly braces.
>>     >
>>     > -DeWitt
>>
>>     I know it's late, but can I add my 2 cents - as a developer who'll be
>>     implementing this?
>>
>>
>>     In the original post, Dick suggested that developers were having
>>     trouble
>>     with the URL encoding format - but I respectfully suggest that JSON is
>>     going to be more problematic.
>>
>>     There's no guarantee that an external JSON parser will be
>>     available for
>>     a given platform/language/business, (perhaps because of licensing, if
>>     not other more technical reasons).  So that means writing one.
>>
>>     Writing a JSON parser just to cover the simple usage proposed won't be
>>     too tricky, but if the JSON response is so simple why bother
>>     adding this
>>     dependency at all?  I'm slightly baffled...
>>
>>
>>     URL encoding is required for at least one flow, so IMHO it might
>>     as well
>>     stay for the rest.  Simplicity is important.
>>
>>
>>     Can someone from the pro-JSON side offer a clearer explanation as
>>     to the
>>     benefits, so I can stop scratching my head about it all, please?
>>
>>
>>
>>     Respectfully,
>>
>>     Pid
>>
>>
>>     > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt
>>     > <[e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>>
>>     wrote:
>>     >
>>     >     Am 05.05.2010 20:01, schrieb Evan Gilbert:
>>     >>
>>     >>
>>     >>     On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert
>>     <[e-mail] <mailto:[e-mail]>
>>     >>     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>     >>
>>     >>
>>     >>
>>     >>         On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
>>     >>         <[e-mail]
>>     <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>>> wrote:
>>     >>
>>     >>             Even if not supported directly by the platform
>>     there are
>>     >>             many JSON libraries available these days.
>>     >>
>>     >>
>>     >>         It's not hard to add JSON support, but it's a factor in the
>>     >>         choice.
>>     >>
>>     >>
>>     >>
>>     >>             http://www.json.org/ lists 3 libraries for
>>     Objective-C alone.
>>     >>
>>     >>             Moreover, the JSON documents we are discussing now are
>>     >>             simple, something like
>>     >>
>>     >>
>>     >>             { "access_token": "SlAV32hkKG", "expires_in": "3600",
>>     >>             "refresh_token": "8xLOxBtZp8" }
>>     >>
>>     >>             Parsing such a document is not a challenge even without
>>     >>             library support.
>>     >>
>>     >>
>>     >>         Per notes above - the client needs to do understand form
>>     >>         encoding anyway. The client needs to parse the redirect_uri
>>     >>         and also needs to generate form encoded requests.
>>     >>
>>     >>
>>     >>     Also, for the User-Agent flow, parsing potentially
>>     untrusted JSON
>>     >>     in JavaScript is difficult. The normal path of using eval() is
>>     >>     unsafe and leads to XSS holes - you need to run regex
>>     matcher to
>>     >>     verify that the JSON content has no executable code.
>>     >
>>     >     You are right, using eval to parse JSON is dangerous and
>>     thus as far
>>     >     as I understand, the recommended way is to use a JSON parser
>>     (aka
>>     >     native JSON support)?
>>     >
>>     >     regards,
>>     >     Torsten.
>>     >
>>     >     _______________________________________________
>>     >     OAuth mailing list
>>     >     [e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>
>>     >     https://www.ietf.org/mailman/listinfo/oauth
>>     >
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > OAuth mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>   
>