Hi Jeff FWIW: 1.5 yrs ago when I was at Microsoft working on OAuth WRAP, I hacked up some Perl code to generate and crack JWTs using HMAC as the signing mechanism. It was only about 10-15 lines of code.
From my experience in building XML-DSIG libraries for Perl/Python/PHP/Ruby -- normalization and canonicalization were the pain points. From an implementation point of view, key management is a pain point. JWT solves the serialization / normalization / canonicalization problem. Having one standard way to assemble and disassemble a token using standard serialization is a HUGE plus. -- Dick On 2011-01-10, at 12:09 PM, Jeff Lindsay wrote: > Dick, thanks for the response. > > I think I'm behind everything you've said. Perhaps the crux is in library vs > user/developer implementation. I'm interested in less steps not for > computational overhead, but for mental overhead and usability. I would love > to have (and even contribute) standard libraries in various languages (we'll > have to anyway if we do adopt this), but for now because we're an API (like > Facebook) and our docs are about using our API. They assume all you need are > the standard libraries in most programming environments. > > Right now, that means users implementing JWTs by hand. While we have > libraries for our APIs, we have to design the API so that you don't *have* to > use these libraries... otherwise, we might as well be a SOAP web service. > > So I'm wondering what people's idea are on how to start using/implementing > this now without standard libraries, assuming we don't want to make the > process any easier. My hypothesis is the response from you all will be, "just > have the JWT process in your docs, it's easy enough. We're not worried about > this odd phase of early adoption with no standard library." > > -jeff > > On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt <[email protected]> wrote: > 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 <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
