Hi everyone! I'm really excited about this spec (and OAuth2), as are others here at Twilio. I've been watching it since Paul implemented an early version at Facebook. We also implemented it in an early iteration of a product we're working on, but now we're coming back to it as a means of authentication that would be key to the entire Twilio API... and since our API *is* our product, we're very touchy about the details.
I've only been glancing at its progress since the early drafts as various versions were integrated and issues sorted out. I was afraid that it was going to have gotten a lot more complicated, but looking at this I'm pretty happy to see most of the additions are optional. Like Paul, I'm not a fan of the short names. However, I've sort of accepted it, especially since as reserved keys they are less likely to conflict with keys we want to put in. The big problem we have, though, is that the header is required. We're debating going with JWT or our own method that is loosely based on JWT, but doesn't use JSON and results in smaller tokens and a simpler process (for example, you only do one base64url encoding of the final string). We think we'd gain better room for additions to our payload, and better readability (therefore learnability/usability) by using JSON, that it might be worth the tradeoff in token size and several encoding steps. At that point, we'd basically be JWT except for the fact we really don't need the header. Facebook's implementation and one of the original proposals let the algorithm key live in the payload. Since this is the only thing required in the header, allowing it as an optional key in the payload would allow the entire header to be optional. This would really help us out since we need a process that is as simple as humanly possible. If you need to detect if a JWT has a header, you can just check for the number of periods in the JWT. But I really think the header should be optional if you specify the alg in the payload. There may have been some issues reserving the key "algorithm", but I think if we go with short names, "alg" is much less likely to cause conflicts. -- Jeff Lindsay On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones <michael.jo...@microsoft.com>wrote: > Draft -01 of the JSON Web Token (JWT) > specification<http://self-issued.info/docs/draft-jones-json-web-token.html>is > now available. This version incorporates the consensus decisions reached > at the Internet Identity Workshop. The remaining open issues and to-do > items are documented in Section > 12<http://self-issued.info/docs/draft-jones-json-web-token-01.html#TBD>. > As a reminder, the suggested pronunciation of JWT is the same as the English > word "jot". > > > > The draft is available at these locations: > > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt > > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml > > - http://self-issued.info/docs/draft-jones-json-web-token-01.html > > - http://self-issued.info/docs/draft-jones-json-web-token-01.txt > > - http://self-issued.info/docs/draft-jones-json-web-token-01.xml > > - http://self-issued.info/docs/draft-jones-json-web-token.html (will > point to new versions as they are posted) > > - http://self-issued.info/docs/draft-jones-json-web-token.txt (will > point to new versions as they are posted) > > - http://self-issued.info/docs/draft-jones-json-web-token.xml (will > point to new versions as they are posted) > > - http://svn.openid.net/repos/specifications/json_web_token/1.0/(Subversion > repository, with html, txt, and html versions available) > > > > The decisions reached at IIW are documented here: > > - JSON Token Spec Results at IIW: http://self-issued.info/?p=361 > > - JSON Token Encryption Spec Results at IIW: > http://self-issued.info/?p=378 > > - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=386 > > - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=390 > > > > This announcement is also posted here: > > - http://self-issued.info/?p=446 > > > > Thanks to all who provided the input that led to this draft! Feedback is > highly welcome. > > > > -- Mike > > > _______________________________________________ > 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
