On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote: > On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer <jric...@mitre.org> > wrote: > >> > I couldn't find a conclusion to the May 2010 discussions about using > >> > x-www- > >> > form-urlencoded vs. json nor a rationale in the spec for using JSON. > >> > Why do I > >> > need to add a JSON lexer/parser to my library just to get key-value > >> > pairs that > >> > can be represented by form-urlencoded? > >> > >> Every modern platform has a JSON parser. > > > > While JSON is widespread, it is an additional requirement. I've done > > some work to define and XML encoding for OAuth tokens here: > > > > http://tools.ietf.org/html/draft-richer-oauth-xml-00 > > > > The draft still needs to be updated to point to the right sections of > > the OAuth2 spec, but the mechanics are still valid. > > Two queries on your spec: > - Have you considered using HTTP Accept: (content negotiation) rather than > a 'format' parameter? Regardless I suggest using MIME types rather than > 'json'/'xml'.
Yes, and I'm planning on putting that into the updated revision. I already had someone yell at me about its omission. :) This will be in addition to the format parameter, though, not in lieu of it. I also greatly prefer short names in the parameter, especially because it's a limited set. The Accept header will use mimetypes though, obviously. > - Use Schema rather than typing by bespoke attributes? > > It's a useful short-cut (as a consumer) to be able to apply a schema to > validate the content including all of the values via basic schema > types/regexp. > Similarly with extensions, if you use namespacing then clients will > transparently ignore anything that isn't in their recognised namespace(s). I'm personally a fan of schema-by-fiat, which is what JSON does. I've also always hated writing XML schemas. If, however, someone wants to write a schema for the core components, I'd be fine with that. However, I do want it to remain general enough to be able to encode more complex extensions, and apart from saying all extensions are in some namespace, I'm not sure how to handle that with a Schema. Speaking of namespaces... > For simplicity I would require the default namespace (xmlns=) to be oauth. > Then values can easily be extracted using string-matching in lightweight > clients: > $xml =~ /<access_token>([^<]+)<\/access_token>/; I avoided using a namespace specifically to cut down on verbosity, since even a default namespace requires attributes in the root tag. While I think string-matching like that in XML is a Very Bad Thing, I do want to keep the serialization simple. That said, if there's enough of a call I can put in a default namespace. What would the URI of that be? http://oauth.net/2/xml? urn:oauth2:xml? > (Schema would also address your 3.7 Information Loss because the Schema > would explicitly define values as numeric or text and singular or multiple) For core attributes, but not for encoding extensions. I wanted this to be a ruleset that one could apply to a blob of JSON to translate it to parseable XML. > Lastly a general RFC point - should you reference RFC 3023, especially the > content-type and security sections? Good catch, thanks. > > The point of this is similar to your contention: if I'm already speaking > > one wire format (XML), why would I want to deal with JSON just to do my > > auth step? > > > > If you'd like to try defining a key-value encoding, we can publish an > > extension draft for that as well. > > I think the simple case is simple: > Content-type: application/x-www-form-urlencoded > > access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8 > > I would re-use the OpenID scheme for providing extension data: > > openid.ns.ax=http://openid.net/srv/ax/1.0&; > openid.ax.type.email=http://schema.openid.net/contact/email&; > openid.ax.value.email=t...@ecs.soton.ac.uk& > oauth.ns.ext=http://example.com/api#limits&; > oauth.ext.soft=10000& > oauth.ext.hard=15000& > oauth.ns.rr=http://example.com/api#roles&; > oauth.rr.role=owner& > oauth.rr.role=editor& > oauth.rr.role=creator& > ... > > I suggest a constraint that the form/urlencoded is always utf-8 (c.f. > OpenURL KEV format NISO Z39.88-2004): > Ë => %C3%8B > And never: > Ë => %CB Not all OAuth extensions that return more stuff have a namespace, though, so it's not an exact map. However, the general method of encoding objects and lists could work. > I'm happy to write this up but all I'd do is drop replacement text into > your RFC. > Do you have a source doc I can work on? What do I do with it when finished? I'd be happy to incorporate your encoding if you want to write them up. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
