[OAUTH-WG] Comparing the JSON Token drafts

Mike Jones <Michael.Jones@microsoft.com> Tue, 28 September 2010 00:45 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 433B53A6BE0 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 17:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.825
X-Spam-Status: No, score=-9.825 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id wbHl9YRcoZ3e for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 17:45:46 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com []) by core3.amsl.com (Postfix) with ESMTP id 3BCAD3A6BF8 for <oauth@ietf.org>; Mon, 27 Sep 2010 17:45:46 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com ( by TK5-EXGWY-E802.partners.extranet.microsoft.com ( with Microsoft SMTP Server (TLS) id; Mon, 27 Sep 2010 17:46:26 -0700
Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([]) with mapi id 14.01.0218.012; Mon, 27 Sep 2010 17:46:25 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Comparing the JSON Token drafts
Thread-Index: Actepo9jOHYKrp9WTw+gSIlGeIAPVg==
Date: Tue, 28 Sep 2010 00:46:25 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394314AA9AF0TK5EX14MBXC207r_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Comparing the JSON Token drafts
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Sep 2010 00:45:54 -0000

Dirk and I both posted JSON Token drafts on Thursday.  They are at http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'll refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-json-web-token-00.html (which I'll refer to as JWT).  This note points out some of the differences (and commonalities) in the interest of building consensus towards a unified approach.


*         Both have ways of expressing the signature algorithm, token issuer, token expiration time, and intended audience.

*         Both use a form of base64url encoding of the JSON claim data.

*         Both require support for the HMAC SHA-256 signature algorithm, and describe how to sign with RSA SHA-256 as well.


*         Dirk's draft uses a base64url encoding that may include one or two '=' pad characters.  The JWT draft uses base64url encoding without padding.

*         JWT uses shorter claim names in the interest of brevity ("iss", "exp", and "aud", versus "issuer", "not_after", and "audience").

*         JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, and ECDSA with longer key lengths.

*         Dirk's tokens must be signed, whereas signing JWTs is optional.

*         Dirk's draft provides for a key_id parameter and a means of serializing keys.

*         Dirk's draft utilizes a Magic Signatures envelope, whereas the only "envelope" component of a JWT is the encoded signature.

*         Dirk's draft proposes that a particular discovery mechanism be used with JSON tokens.

Let me tackle the differences one at a time, in hopes of driving towards a consensus position.

*         To pad or not to pad:  The '=' pad characters add length, are not URL-safe (and therefore must be escaped when used in URLs, adding more length), and add no information.  Therefore, I would propose that we agree not to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf.org/html/rfc4648#section-5>)5>), especially since a no-padding implementation is trivial, as shown in JWT Section 13<http://self-issued.info/docs/draft-goland-json-web-token-00.html#base64urlnotes>.

*         Claim name length: Given that a core goal of both specs is short tokens, I would propose that we use the shorter reserved claim names.  Having short tokens is especially important when used with mobile browsers, where URL length restrictions may be severe.  (People are always free to use longer ones in any particular application context if they have a reason to do so.)

*         Elliptic curve crypto and longer key lengths:  The JWT spec defines how to use ECC as well as HMAC and RSA.  Given ECC's inclusion in NSA Suite B<http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> and that it has engineering advantages over RSA (shorter key lengths and more efficient computations), it makes sense that any modern spec incorporating cryptography allow its use as an option.  Likewise, it makes sense for the spec to define how to use longer key lengths on an optional basis.

*         Unsigned tokens:  In some application contexts, it may make sense to send unsigned tokens if carried in a signed and/or encrypted container or channel.  Allowing for unsigned tokens means that double signing need not occur.

*         Key identification:  I agree that having means of identifying and distributing keys are critical for to end-to-end security of signed tokens.  That's a separate point from whether the key identification and distribution mechanisms should be part of the token format specification, or treated separately.  I would advocate that it be treated separately (as was done with SWTs as well), but am open to discussion on this point.

*         Envelope structure:  Dirk's draft proposes that the signed content be wrapped in a particular kind of envelope.  Among other things, this envelope can help prevent a token from being repurposed from one context to another, by having a clear (and cryptographically verified) declaration that "This is a JSON token".  I understand this motivation and am open to discussions on how to best achieve it, while still providing as little mechanism as possible (but no less :)).

*         Discovery:  Like key distribution, I believe that an agreement on discovery mechanisms is critical to many use cases.  But like key distribution, I'd like us to take that up in a separate specification, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.

Dirk, and others, please jump in!

                                                                -- Mike