Mike,
A couple of comments on JWT: (I had to send something after accidentally sending an empty message to the list ;-) Section 4.1 "Reserved claim names" There isn't a JSON "integer" type, just a "number" type. The examples use a string value for "exp", while I expected a number (I expected "exp":1300752001 instead of "exp":"1300752001"). StringAndURI might be better named StringOrURI. Section 5 "General rules for creating and validating a JWT" "5. When used in a security-related context, the JWT Claim Segment MUST be validated to only include claims whose syntax and semantics are both understood and supported." Validation step 5 is very nasty towards future enhancements. It basically says a JWT with unrecognized claims must be rejected. A future-friendly alternative would be to ignore unrecognized claims. I like Ben Laurie's note that the IETF's golden rule to "be liberal in what you accept" has "proved to be a less-than-great idea, particularly in protocols where you care about security, which is to say, all of them" [http://www.ietf.org/mail-archive/web/tls/current/msg04688.html]. Is this the sentiment behind step 5? I would agree with this sentiment for rejecting malformed JSON, but not for rejecting well-formed but unrecognized claims. Perhaps the concern is that an unrecognized claim might change the meaning of another claim (eg qualify it to a limited context). That would be bad design of the claims, however. A JWT used to access 2 apps may need some claims that only 1 app needs that the other has no need to recognize. Section 7 "Signing JWTs with cryptographic algorithms" It is a pity yet another set of names are required for algorithms that have been around for a while, eg "HS256", instead of "HmacSHA256" (Java's name) or "hmac-sha256" (fragment from XML digital signatures) or "HMAC-SHA256" (mimicking OAuth1). If we really want to save bytes, we could use "alg":"H" and use the length of the signature to distinguish between SHA-256/384/512. Section 7.1 "Signing a JWT with HMAC SHA-256" Drop "SHA-256" from the section name as it specifies signing with HMAC SHA-384 and HMAC SHA-512 as well. Similarly rename sections 7.2 to "Signing a JWT with RSA" and section 7.3 to "Signing a JWT with ECDSA". Section 3.1 "Example unsigned JWT" The base64url encoding of the example doesn't include a '-' or '_' character, which would be helpful as these are the important differences from normal base64. Changing ".../is_root" to ".../~is_root" adds a "-" to the encoding. -- James Manger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, 24 September 2010 10:22 AM To: oauth@ietf.org Subject: [OAUTH-WG] JSON Web Token (JWT) Specification Draft Recognizing that there is substantial interest in representing sets of claims in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token (JWT) spec for that purpose. To answer the obvious question, while this was produced independently of Dirk's JSON token proposal<http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html>, both of us agree that we should come up with a unified spec. Consider this an additional point in the possible design space from which to start discussions and drive consensus. (If you read the two proposals, I think you'll find that there's already a lot in common, which is great.) Thanks to those of you who have already given us feedback to improve the draft prior to this point. Cheers, -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
