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

[Joseph Smarr <[e-mail]>]

+1 to including JSON format, and perhaps making it the required format. In
my experience helping numerous developers debug their OAuth implementations,
url-encoding/decoding was often a source of bugs, since a) the libraries are
usually hand-built, b) url-encoding is known to be funky/inconsistent wrt +
vs. %20 and other such things, and c) it's very sensitive to things like a
trailing newline at the end of the response, which can easily be tokenized
as part of the the last value (since the normal implementations just split
on & and =). In contrast, I've never heard of any problems parsing JSON, nor
any encoding/decoding bugs related to working with JSON in other APIs
(something I *cannot* say about XML, which is way more finicky about
requiring its values to be properly encoded or escaped in CDATA etc.; I've
also seen way more inconsistency in support of XML parsers and their output
formats, whereas JSON always works exactly the same way and always "just
works").

So in conclusion, url-encoding has caused a lot of pain in OAuth 1.0, and
JSON is already widely supported (presumably including by most APIs that
you're building OAuth support to be able to access!), so I think it would
simplify the spec and increase ease/success of development to use JSON as a
request format. In fact, I think I'd like to push for it to be the
default/required format, given the positive attributes above. Does anyone
object, and if so, why?

Thanks, js

On Tue, Apr 20, 2010 at 8:10 AM, Eran Hammer-Lahav <[e-mail]>wrote:

> There seems to be support for this idea with some concerns about
> complexity. Someone needs to propose text for this including defining the
> request parameter and schema of the various reply formats.
>
> EHL
>
> > -----Original Message-----
> > From: Torsten Lodderstedt [mailto:[e-mail]]
> > Sent: Monday, April 19, 2010 4:48 AM
> > To: Eran Hammer-Lahav
> > Cc: Dick Hardt; OAuth WG
> > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> >
> >
> > > We can also offer both and define a client request parameter (as long
> > > as the server is required to make at least one format available).
> >
> > +1 on this
> >
> > regards,
> > Torsten.
> >
> > >
> > > EHL
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On
> > >> Behalf Of Dick Hardt
> > >> Sent: Sunday, April 18, 2010 9:30 PM
> > >> To: OAuth WG
> > >> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> > >>
> > >> The AS token endpoint response is encoded as application/x-www-form-
> > >> urlencoded
> > >>
> > >> While this reuses a well known and understood encoding standard, it
> > >> is uncommon for a client to receive a message encoded like this. Most
> > >> server responses are encoded as XML or JSON. Libraries are NOT
> > >> reedily available to parse application/x-www-form-urlencoded results
> > >> as this is something that is typically done in the web servers
> > >> framework. While parsing the name value pairs and URL un-encoding
> > >> them is not hard, many developers have been caught just splitting the
> > parameters and forgetting to URL decode the token.
> > >> Since the token is opaque and may contain characters that are
> > >> escaped, it is a difficult bug to detect.
> > >>
> > >> Potential options:
> > >>
> > >> 1) Do nothing, developers should read the specs and do the right
> thing.
> > >>
> > >> 2) Require that all parameters are URL safe so that there is no
> > >> encoding issue.
> > >>
> > >> 3) Return results as JSON, and recommend that parameters be URL safe.
> > >>
> > >> -- Dick
> > >> _______________________________________________
> > >> 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
>