Hi Jeff Thanks for the feedback. A healthy debate is how we optimize a spec!
Will a slightly shorter token be significant for you? Is the rest of the message so short that a smaller token will have a significant impact? The hope is that if we standardize JWT, that libraries will be developed so that the average developer does not need to deal with the details. We are having to balance between a generalized solution and a simple, specific solution. Too specific and the spec does not solve a broad enough set of people's needs, libraries don't get developed, or if they do, the code coverage is nominal and they are not well maintained. This leads to more security risks and higher barrier to deployment. Too generic and the complexity in the library adds more security risks, less likely someone will implement a library and deploy. The header makes it easy for a generic library to quickly see what the rest of the token is, enables support for encrypted payloads (can't do that if the crypto info is in the payload), and provides a simple path for extensions / expansion. While I can appreciate doing less encodings operations, the encoding is already being used, so this is a slight additional computational overhead. Your suggestion for checking the number of periods may actually add back the computational overhead, and a separate code path to be tested leading to less secure code. Happy to elaborate more if that was not clear and compelling! -- Dick On 2011-01-06, at 7:29 PM, Jeff Lindsay wrote: > 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 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. 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
