Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433B53A6BE0 for ; 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-Level: 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbHl9YRcoZ3e for ; Mon, 27 Sep 2010 17:45:46 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3BCAD3A6BF8 for ; Mon, 27 Sep 2010 17:45:46 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 27 Sep 2010 17:46:26 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.160]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0218.012; Mon, 27 Sep 2010 17:46:25 -0700 From: Mike Jones To: "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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 00:45:54 -0000 --_000_4E1F6AAD24975D4BA5B168042967394314AA9AF0TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dirk and I both posted JSON Token drafts on Thursday. They are at http://b= alfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'l= l refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-j= son-web-token-00.html (which I'll refer to as JWT). This note points out s= ome of the differences (and commonalities) in the interest of building cons= ensus towards a unified approach. Commonalities: * Both have ways of expressing the signature algorithm, token issue= r, 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, an= d describe how to sign with RSA SHA-256 as well. Differences: * Dirk's draft uses a base64url encoding that may include one or tw= o '=3D' pad characters. The JWT draft uses base64url encoding without padd= ing. * 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 seria= lizing keys. * Dirk's draft utilizes a Magic Signatures envelope, whereas the on= ly "envelope" component of a JWT is the encoded signature. * Dirk's draft proposes that a particular discovery mechanism be us= ed 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 '=3D' pad characters add length, are n= ot URL-safe (and therefore must be escaped when used in URLs, adding more l= ength), and add no information. Therefore, I would propose that we agree n= ot to use padding (as permitted by RFC 4648, Section 5), especially since a no-padding implementation is= trivial, as shown in JWT Section 13. * 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. Havi= ng short tokens is especially important when used with mobile browsers, whe= re URL length restrictions may be severe. (People are always free to use l= onger ones in any particular application context if they have a reason to d= o so.) * Elliptic curve crypto and longer key lengths: The JWT spec defin= es how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Su= ite B and t= hat it has engineering advantages over RSA (shorter key lengths and more ef= ficient computations), it makes sense that any modern spec incorporating cr= yptography allow its use as an option. Likewise, it makes sense for the sp= ec 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 no= t 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 distribu= tion mechanisms should be part of the token format specification, or treate= d 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 conten= t be wrapped in a particular kind of envelope. Among other things, this en= velope can help prevent a token from being repurposed from one context to a= nother, by having a clear (and cryptographically verified) declaration that= "This is a JSON token". I understand this motivation and am open to discu= ssions 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 distribu= tion, 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 --_000_4E1F6AAD24975D4BA5B168042967394314AA9AF0TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 (whi= ch I’ll refer to as JWT).  This note points out some of the diff= erences (and commonalities) in the interest of building consensus towards a unified approach.

 

Commonalities:

·         Both have ways of expressing the signature a= lgorithm, token issuer, token expiration time, and intended audience.<= /o:p>

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

·         Both require support for the HMAC SHA-256 si= gnature algorithm, and describe how to sign with RSA SHA-256 as well.<= /o:p>

 

Differences:

·         Dirk’s draft uses a base64url encoding= that may include one or two ‘=3D’ pad characters.  The JW= T draft uses base64url encoding without padding.

·         JWT uses shorter claim names in the interest= of brevity (“iss”, “exp”, and “aud”, v= ersus “issuer”, “not_after”, and “audience= 221;).

·         JWT also describes how to sign with ECDSA SH= A-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 par= ameter and a means of serializing keys.

·         Dirk’s draft utilizes a Magic Signatur= es envelope, whereas the only “envelope” component of a JWT is = the encoded signature.

·         Dirk’s draft proposes that a particula= r discovery mechanism be used with JSON tokens.

 

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

·         To pad or not to pad:  The ̵= 6;=3D’ pad characters add length, are not URL-safe (and therefore mus= t 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), especially since a no-padding implementation is t= rivial, as shown in JWT Section 13.

·         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 wh= en used with mobile browsers, where URL length restrictions may be severe.  (People are always free to use lo= nger ones in any particular application context if they have a reason to do= so.)

·         Elliptic curve crypto and longer key leng= ths:  The JWT spec defines how to use ECC as well as HMAC and RSA.=   Given ECC’s inclusion in = NSA Suite B and that it has engineering advantages over RSA (shorter ke= y 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 defin= e how to use longer key lengths on an optional basis.

·         Unsigned tokens:  In some applic= ation contexts, it may make sense to send unsigned tokens if carried in a s= igned and/or encrypted container or channel.  Allowing for unsigned to= kens means that double signing need not occur.

·         Key identification:  I agree tha= t 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 se= parately.  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 ope= n to discussions on how to best achieve it, while still providing as little= mechanism as possible (but no less J).

·         Discovery:  Like key distributio= n, 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!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394314AA9AF0TK5EX14MBXC207r_--