Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft

["Manger, James H" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Friday, 24 September 2010 10:22 AM
To: [e-mail]
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