+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...@hueniverse.com>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:tors...@lodderstedt.net] > > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
