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 B8B773A6E0F for ; Fri, 1 Oct 2010 17:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.41 X-Spam-Level: X-Spam-Status: No, score=-105.41 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] 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 vyub5Jtq6VFl for ; Fri, 1 Oct 2010 17:11:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D51BE3A6DF4 for ; Fri, 1 Oct 2010 17:11:47 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o920CZGm024636 for ; Fri, 1 Oct 2010 17:12:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285978356; bh=zErNSj+3O3PefQqc5PQWFs82zMY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HPCJA/2TK5dK+ZCJJszbZ8FuIKnsVMHNmQHtUKUIUM1++Uo6p6KhdtQALGzJf2Vvi KhabsHTJrSEARGuTbAAOA== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq12.eem.corp.google.com with ESMTP id o920CXjY009465 for ; Fri, 1 Oct 2010 17:12:34 -0700 Received: by pzk28 with SMTP id 28so2602000pzk.25 for ; Fri, 01 Oct 2010 17:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=2f/yeM6TlZTM/MG4YHMbem4PamsKT7hAOGckC9rcWEI=; b=vVYopbLazNuiSN5XFIyryKlY7KrTx+USeONNK29cb54tQrZHDyEtFuKJm2pofXFBTm YzUJxTHWDrgQSY5cs3oQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sGxs8JhLyqFdcXiUbQaf7s4mmZI9aANmWTwP9TKw6fHlpWcz8+oGFN0x6xHsXWcvw2 t0bLTJY44koBqFMgoXZw== Received: by 10.142.249.16 with SMTP id w16mr5425392wfh.251.1285978352786; Fri, 01 Oct 2010 17:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.7 with HTTP; Fri, 1 Oct 2010 17:12:12 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> From: John Panzer Date: Fri, 1 Oct 2010 17:12:12 -0700 Message-ID: To: Dirk Balfanz Content-Type: multipart/alternative; boundary=00504502ca54e81cd10491972ac2 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [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: Sat, 02 Oct 2010 00:11:51 -0000 --00504502ca54e81cd10491972ac2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Quick note: On Tue, Sep 28, 2010 at 10:23 AM, Dirk Balfanz wrote: > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones = wrote: > >> 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=92ll refer to as Dirk=92s draft) and >> http://self-issued.info/docs/draft-goland-json-web-token-00.html (which >> I=92ll refer to as JWT). This note points out some of the differences (= and >> commonalities) in the interest of building consensus towards a unified >> approach. >> >> >> >> Commonalities: >> >> =B7 Both have ways of expressing the signature algorithm, token >> issuer, token expiration time, and intended audience. >> >> =B7 Both use a form of base64url encoding of the JSON claim data= . >> >> =B7 Both require support for the HMAC SHA-256 signature algorith= m, >> and describe how to sign with RSA SHA-256 as well. >> >> >> >> Differences: >> >> =B7 Dirk=92s draft uses a base64url encoding that may include on= e or >> two =91=3D=92 pad characters. The JWT draft uses base64url encoding wit= hout >> padding. >> >> =B7 JWT uses shorter claim names in the interest of brevity (=93= iss=94, >> =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93a= udience=94). >> >> =B7 JWT also describes how to sign with ECDSA SHA-256, plus HMAC= , >> RSA, and ECDSA with longer key lengths. >> >> =B7 Dirk=92s tokens must be signed, whereas signing JWTs is opti= onal. >> >> =B7 Dirk=92s draft provides for a key_id parameter and a means o= f >> serializing keys. >> >> =B7 Dirk=92s draft utilizes a Magic Signatures envelope, whereas= the >> only =93envelope=94 component of a JWT is the encoded signature. >> >> =B7 Dirk=92s draft proposes that a particular discovery mechanis= m be >> used with JSON tokens. >> >> >> >> Let me tackle the differences one at a time, in hopes of driving towards= a >> consensus position. >> > > Hi there - thanks for writhing this up. Comments below: > >> =B7 *To pad or not to pad:* The =91=3D=92 pad characters add le= ngth, are >> not URL-safe (and therefore must be escaped when used in URLs, adding mo= re >> length), and add no information. Therefore, I would propose that we agr= ee >> not to use padding (as permitted by RFC 4648, Section 5), >> especially since a no-padding implementation is trivial, as shown in JWT >> Section 13 >> . >> > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, padding-less encoding is not well-supported in so= me > frameworks, which can lead to confusion. > Note: If this were the one remaining blocking issue keeping a shared core signature spec from happening, I and the other implementors I've talked to on Magic Signatures would be okay with switching if you feel really strongly. It will be an interop pain point but not a deal breaker. So I suggest putting this on hold, and seeing if everything else can be worked out first, and if so, then we're done. > > >> =B7 *Claim name length:* Given that a core goal of both specs is >> short tokens, I would propose that we use the shorter reserved claim nam= es. >> Having short tokens is especially important when used with mobile browse= rs, >> 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.) >> > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > >> =B7 *Elliptic curve crypto and longer key lengths:* The JWT spe= c >> defines how to use ECC as well as HMAC and RSA. Given ECC=92s inclusion= in NSA >> Suite B = 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 mak= es >> sense for the spec to define how to use longer key lengths on an optiona= l >> basis. >> > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > As just one datapoint, Google would have a hard time supporting ECC, sinc= e > it's not in the Java core library. We don't use bouncycastle. > > >> =B7 *Unsigned tokens:* In some application contexts, it may ma= ke >> 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. >> > That one just confuses me :-) What's the difference between OAuth without > signatures and unsigned tokens? Is the latter not just a more complicated > way of doing the former? > > =B7 *Key identification:* I agree that having means of identify= ing >> and distributing keys are critical for to end-to-end security of signed >> tokens. That=92s a separate point from whether the key identification a= nd >> 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. >> >> =B7 *Discovery:* Like key distribution, I believe that an >> agreement on discovery mechanisms is critical to many use cases. But li= ke >> key distribution, I=92d like us to take that up in a separate specificat= ion, >> rather than tightly binding the use of JSON tokens to a particular disco= very >> mechanism. >> >> > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, k= ey > rotation, etc. To actually reap the benefits of key rotation, though, we > need to say how to find out what the currently-used key is. If we don't, > then a lot of the potential advantage of using public keys evaporates. I'= m > concerned that, lacking the discovery spec, developers will start > hard-coding keys into their servers, and we'll end up in a situation wher= e > we can't rotate keys when Something Bad happens. > > =B7 *Envelope structure:* Dirk=92s draft proposes that the signe= d >> 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 =93This is a JSON token=94. I understand this motivati= on and >> am open to discussions on how to best achieve it, while still providing = as >> little mechanism as possible (but no less J). >> > Well, you've seen my proposal on how to achieve it :-), but I'm also open > to better ways, if someone comes up with one... > > Dirk. > > >> >> >> Dirk, and others, please jump in! >> >> >> >> -- Mike >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00504502ca54e81cd10491972ac2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Quick note:

=
On Tue, Sep 28, 2010 at 10:23 AM, Dirk Bal= fanz <balfanz@go= ogle.com> wrote:
On Mon, Sep 27, 2010 at 5= :46 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

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

=A0

Commonalities:

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

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Both use a form of base64url encoding of the JSON clai= m data.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Both require support for the HMAC SHA-256 signature al= gorithm, and describe how to sign with RSA SHA-256 as well.

=A0

Differences:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft uses a base64url encoding that may incl= ude one or two =91=3D=92 pad characters.=A0 The JWT draft uses base64url en= coding without padding.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 JWT uses shorter claim names in the interest of brevit= y (=93iss=94, =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after= =94, and =93audience=94).

=B7=A0=A0=A0=A0=A0=A0=A0=A0 JWT also describes how to sign with ECDSA SHA-256, plu= s HMAC, RSA, and ECDSA with longer key lengths.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s tokens must be signed, whereas signing JWTs i= s optional.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft provides for a key_id parameter and a m= eans of serializing keys.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft utilizes a Magic Signatures envelope, w= hereas the only =93envelope=94 component of a JWT is the encoded signature.=

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft proposes that a particular discovery me= chanism be used with JSON tokens.

=A0

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


Hi there - thanks for writhing this up. Comments belo= w:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 To pad or not to pad:=A0 The =91=3D=92 pad char= acters add length, are not URL-safe (and therefore must be escaped when use= d in URLs, adding more length), and add no information.=A0 Therefore, I wou= ld 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.<= /p>


I don't feel strongl= y about this, but remember John Panzer's cautionary tales here: Apparen= tly, padding-less encoding is not well-supported in some frameworks, which = can lead to confusion.

Note: If this were the one remaining= blocking issue keeping a shared core signature spec from happening, I and = the other implementors I've talked to on Magic Signatures would be okay= with switching if you feel really strongly. =A0It will be an interop pain = point but not a deal breaker. =A0So I suggest putting this on hold, and see= ing if everything else can be worked out first, and if so, then we're d= one.
=A0
=A0

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


I don't feel s= trongly about this, but I think many people do want to have more descriptiv= e names here.=A0
=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Elliptic curve crypto and longer key lengths:= =A0 The JWT spec defines how to use ECC as well as HMAC and RSA.=A0 Given E= CC=92s inclusion in NSA Suite B and that it has engineering advantages ov= er RSA (shorter key lengths and more efficient computations), it makes sens= e that any modern spec incorporating cryptography allow its use as an option.=A0 Likewise, it makes sense for the spec to define h= ow to use longer key lengths on an optional basis.

So this one I do feel more strongly about: We should only in= clude crypto mechanisms that everybody MUST support. Otherwise, we'll h= ave to invent some sort of negotiation step in the protocol: "do you s= upport alg XYZ? No I don't, please use ABC". Let's not do that= .=A0

As just one datapoint, Google would have a hard time su= pporting ECC, since it's not in the Java core library. We don't use= bouncycastle.
=A0

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

That one just confuses me :-) What'= s the difference between OAuth without signatures and unsigned tokens? Is t= he latter not just a more complicated way of doing the former?=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Key identification:=A0 I agree that having mean= s of identifying and distributing keys are critical for to end-to-end secur= ity of signed tokens.=A0 That=92s a separate point from whether the key ide= ntification and distribution mechanisms should be part of the token format specification, or treated se= parately.=A0 I would advocate that it be treated separately (as was done wi= th SWTs as well), but am open to discussion on this point.

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

<= /blockquote>

Here is where I'm coming from: I find t= he public-key versions of the signatures much more intriguing - they allow = for easier key management, key rotation, etc. To actually reap the benefits= of key rotation, though, we need to say how to find out what the currently= -used key is. If we don't, then a lot of the potential advantage of usi= ng public keys evaporates. I'm concerned that, lacking the discovery sp= ec, developers will start hard-coding keys into their servers, and we'l= l end up in a situation where we can't rotate keys when Something Bad h= appens.

=B7<= span>=A0=A0=A0=A0=A0=A0=A0=A0=A0Envelope structure:= =A0 Dirk=92s draft proposes that the signed content be wrapped in a par= ticular kind of envelope. =A0Among other things, this envelope can help pre= vent a token from being repurposed from one context to another, by having a= clear (and cryptographically verified) declaration that =93This is a JSON = token=94.=A0 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=A0J).

Well, you've seen my proposal on ho= w to achieve it :-), but I'm also open to better ways, if someone comes= up with one...

Dirk.
=A0

=A0

Dirk, and others, please jump in!

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--00504502ca54e81cd10491972ac2--