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

[Mike Jones <[e-mail]>]

Thanks for the detailed comments, James.  I'll take them into account when producing the next draft.

Yes, the motivation behind Section 5, Rule 5 is exactly motivated by the sentiments that Ben so ably expressed and you elaborated upon.  Note that there *is* a caveat in place "When used in a security-related context".  If the token isn't being used in a security-related context, you are free to ignore not-understood claims (but not mal-formed tokens).  But if it's being used to make an access or authorization decision, it's a best practice that SOME layer of the software processing the token must fully understand what the token is intended to mean.

                                                                Thanks again,
                                                                -- Mike

From: Manger, James H [mailto:[e-mail]]
Sent: Sunday, September 26, 2010 8:58 PM
To: Mike Jones; [e-mail]
Subject: RE: JSON Web Token (JWT) Specification Draft

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