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

[Simone Gianni <[e-mail]>]

+2¢ :D

There are hundreds of formats for a flat key->value "map", expecially when
you already know the native type of the value given the key. Http headers
are a format, HTTP form encoding is a well known and supported format and
already required by OAuth in other places.

JSON is nice, but to invoke a JSON parser (not to mention an XML parser) to
parse a simple map of key->value is overkill .. you can afford it if you are
just dealing with a javascript based client (exec('resp=' + json), and risk
injection) cause the javascript interpreter kicks in and the CPU you are
wasting is not yours :D

On the opposite, if the client is not a javascript based device and the CPU
is yours (for example, you are authenticating your own servers each on each
other) then it's uselessly overkill.

Another problem is generating JSON data. Again, encoding a key->value in
HTTP form encoding is quite CPU trivial and will have to be done anyway in
other parts of OAuth, serializing JSON is not (from a performance POV, not
from a programmer POV), unless you write the json string yourself which
gives JSON no benefit for the server guys.

Couldn't the specification mandate support for HTTP form encoding and
optionally use the HTTP header Content-type to provide alternative encodings
for the same key->value map? Some implementations will then support JSON
cause many clients will be JavaScript, some others may not cause are
specialized in other environments, some others may support YAML or other
representations to better suit their clients or optimize performances or
whatever.

Obviously, it changes if data is structured, in which case JSON or XML are
required, but it does not seem to be the case.

Simone

2010/5/7 Paul C. Bryan <[e-mail]>

> Here's my 2¢ worth...
>
> Criteria: If the structure of encoded data is guaranteed to be a flat
> list of name-value pairs, x-www-form-urlencoded seems sufficient. If the
> structure could be (arbitrarily) complex (e.g. nesting lists or
> associative arrays), then definitely use JSON.
>
> Why JSON instead of, say, XML? JSON unambiguously translates to and from
> commonly used (usually native) data structures in virtually every common
> scripting and programming language in existence.
>
> Paul
>
> -----Original Message-----
> From: Pid <[e-mail]>
> Reply-to: [e-mail]
> To: OAuth WG <[e-mail]>
> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> (Proposal)
> Date: Fri, 07 May 2010 15:19:54 +0100
>
> 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
> >>
> >
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>