All the issues around encoding in 1.0 were about signatures. This is no longer an issue.
EHL On Apr 20, 2010, at 14:19, "Joseph Smarr" <jsm...@gmail.com<mailto:jsm...@gmail.com>> wrote: On the one hand, I'm sympathetic to the "easy to write a parser yourself" argument for url-encoding, since in general I think you want to minimize any toolchain/library requirements to maximize adoption. On the other hand, I'd argue that OAuth 1.0 has shows url-encoding to be "deceptively easy" to implement yourself, plus there are *fewer* easy/good parsing libraries available, and that leads more developers to try and hand-code parsers that actually contain bugs. Now David, I'm sure your implementation has no bugs, but lots of "official OAuth libraries" did have bugs in their parsers, whereas JSON does have widely available, high-quality support, and it's just complex enough that you're not tempted to try and write a (buggy) version yourself, yet not so painful that it would be unthinkable to do so (compared to, say, a compliant XML parser). Thanks, js On Tue, Apr 20, 2010 at 12:56 PM, Paul C. Bryan <<mailto:em...@pbryan.net>em...@pbryan.net<mailto:em...@pbryan.net>> wrote: I'm struggling to imagine hardware that on the one hand would support OAuth, but on the other would be incapable of supporting JSON... -----Original Message----- From: David Recordon <<mailto:record...@gmail.com>record...@gmail.com<mailto:record...@gmail.com>> To: <mailto:jsm...@stanfordalumni.org> jsm...@stanfordalumni.org<mailto:jsm...@stanfordalumni.org> Cc: OAuth WG <<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON Date: Tue, 20 Apr 2010 12:45:05 -0700 Having written an implementation last night against the web server flow, I'm worried about adding JSON as a requirement for the response. While it might be easier for environments with JSON libraries, it's drastically more complex for environments (like embedded hardware) which doesn't support JSON. And writing basic form encoded parsing code really isn't that hard – especially if I can do it! On Tue, Apr 20, 2010 at 9:24 AM, Joseph Smarr <<mailto:jsm...@gmail.com>jsm...@gmail.com<mailto:jsm...@gmail.com>> wrote: > +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 > <<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto: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:<mailto:tors...@lodderstedt.net>tors...@lodderstedt.net<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: <mailto:oauth-boun...@ietf.org> >> > >> oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> >> > >> [mailto:<mailto:oauth-boun...@ietf.org>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 >> > >> <mailto:OAuth@ietf.org> OAuth@ietf.org<mailto:OAuth@ietf.org> >> > >> <https://www.ietf.org/mailman/listinfo/oauth> >> > >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ >> > > OAuth mailing list >> > > <mailto:OAuth@ietf.org> OAuth@ietf.org<mailto:OAuth@ietf.org> >> > > <https://www.ietf.org/mailman/listinfo/oauth> >> > > https://www.ietf.org/mailman/listinfo/oauth >> > > >> > >> > >> > >> >> _______________________________________________ >> OAuth mailing list >> <mailto:OAuth@ietf.org> OAuth@ietf.org<mailto:OAuth@ietf.org> >> <https://www.ietf.org/mailman/listinfo/oauth> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > <mailto:OAuth@ietf.org> OAuth@ietf.org<mailto:OAuth@ietf.org> > <https://www.ietf.org/mailman/listinfo/oauth> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list <mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
