Re: [OAUTH-WG] Comparing the JSON Token drafts
John Panzer <jpanzer@google.com> Sat, 02 October 2010 00:11 UTC
Return-Path: <jpanzer@google.com>
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 <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; 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 <oauth@ietf.org>; 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 <oauth@ietf.org>; Fri, 1 Oct 2010 17:12:34 -0700
Received: by pzk28 with SMTP id 28so2602000pzk.25 for <oauth@ietf.org>; 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: <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com>
References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com>
From: John Panzer <jpanzer@google.com>
Date: Fri, 01 Oct 2010 17:12:12 -0700
Message-ID: <AANLkTi=Z0-7NAXGzhx45b1jQY=nq7Ttv8KRsxueSgPLr@mail.gmail.com>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: multipart/alternative; boundary="00504502ca54e81cd10491972ac2"
X-System-Of-Record: true
Cc: "oauth@ietf.org" <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 <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: Sat, 02 Oct 2010 00:11:51 -0000
Quick note: On Tue, Sep 28, 2010 at 10:23 AM, Dirk Balfanz <balfanz@google.com> wrote: > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com>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’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. >> >> >> >> Commonalities: >> >> · 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. >> >> >> >> Differences: >> >> · 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. >> > > Hi there - thanks for writhing this up. Comments below: > >> · *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>), >> 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> >> . >> > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, 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. 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. > > >> · *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.) >> > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > >> · *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. >> > 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 some > 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, since > it's not in the Java core library. We don't use bouncycastle. > > >> · *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. >> > 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? > > · *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. >> >> · *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. >> >> > 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, 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 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 where > we can't rotate keys when Something Bad happens. > > · *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 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 > >
- [OAUTH-WG] Comparing the JSON Token drafts Mike Jones
- Re: [OAUTH-WG] Comparing the JSON Token drafts Dirk Balfanz
- Re: [OAUTH-WG] Comparing the JSON Token drafts Anthony Nadalin
- Re: [OAUTH-WG] Comparing the JSON Token drafts Eve Maler
- Re: [OAUTH-WG] Comparing the JSON Token drafts Yaron Goland
- Re: [OAUTH-WG] Comparing the JSON Token drafts John Panzer
- Re: [OAUTH-WG] Comparing the JSON Token drafts Dirk Balfanz
- Re: [OAUTH-WG] Comparing the JSON Token drafts Mike Jones
- Re: [OAUTH-WG] Comparing the JSON Token drafts Anthony Nadalin
- Re: [OAUTH-WG] Comparing the JSON Token drafts Dirk Balfanz
- Re: [OAUTH-WG] Comparing the JSON Token drafts Anthony Nadalin
- Re: [OAUTH-WG] Comparing the JSON Token drafts Dirk Balfanz
- Re: [OAUTH-WG] Comparing the JSON Token drafts Nat Sakimura