On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer <[email protected]> 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'. - 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). 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>/; (Schema would also address your 3.7 Information Loss because the Schema would explicitly define values as numeric or text and singular or multiple) Lastly a general RFC point - should you reference RFC 3023, especially the content-type and security sections? > 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&; [email protected]& 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 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? -- All the best, Tim. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
