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:james.h.man...@team.telstra.com]
Sent: Sunday, September 26, 2010 8:58 PM
To: Mike Jones; oauth@ietf.org
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: 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
