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

Mike Jones <> Tue, 28 September 2010 00:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0698A3A6BBA for <>; Mon, 27 Sep 2010 17:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.32
X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sw0yGYfaSHDn for <>; Mon, 27 Sep 2010 17:43:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C08023A6BE0 for <>; Mon, 27 Sep 2010 17:43:58 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 27 Sep 2010 17:44:32 -0700
Received: from ([]) by ([]) with mapi id 14.01.0218.012; Mon, 27 Sep 2010 17:44:32 -0700
From: Mike Jones <>
To: "Manger, James H" <>, "" <>
Thread-Topic: JSON Web Token (JWT) Specification Draft
Thread-Index: Actbfov76Bkh7l/GQKOvG+24lxItYgCZRvoQAC5MLTA=
Date: Tue, 28 Sep 2010 00:44:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394314AA9A2BTK5EX14MBXC207r_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Sep 2010 00:44:07 -0000

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 []
Sent: Sunday, September 26, 2010 8:58 PM
To: Mike Jones;
Subject: RE: JSON Web Token (JWT) Specification Draft


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

                                                            -- Mike