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 <p...@pidster.com >> <mailto:p...@pidster.com>> 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 >> > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >> <mailto:tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>> >> wrote: >> > >> > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert >> <uid...@google.com <mailto:uid...@google.com> >> >> <mailto:uid...@google.com <mailto:uid...@google.com>>> wrote: >> >> >> >> >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> >> <tors...@lodderstedt.net >> <mailto:tors...@lodderstedt.net> <mailto:tors...@lodderstedt.net >> <mailto:tors...@lodderstedt.net>>> 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 >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
