Re: [OAUTH-WG] Comparing the JSON Token drafts

John Panzer <> Sat, 02 October 2010 00:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8B773A6E0F for <>; Fri, 1 Oct 2010 17:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.41
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyub5Jtq6VFl for <>; Fri, 1 Oct 2010 17:11:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D51BE3A6DF4 for <>; Fri, 1 Oct 2010 17:11:47 -0700 (PDT)
Received: from ( []) by with ESMTP id o920CZGm024636 for <>; Fri, 1 Oct 2010 17:12:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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 ( []) by 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;; 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;; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sGxs8JhLyqFdcXiUbQaf7s4mmZI9aANmWTwP9TKw6fHlpWcz8+oGFN0x6xHsXWcvw2 t0bLTJY44koBqFMgoXZw==
Received: by with SMTP id w16mr5425392wfh.251.1285978352786; Fri, 01 Oct 2010 17:12:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 1 Oct 2010 17:12:12 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: John Panzer <>
Date: Fri, 01 Oct 2010 17:12:12 -0700
Message-ID: <>
To: Dirk Balfanz <>
Content-Type: multipart/alternative; boundary="00504502ca54e81cd10491972ac2"
X-System-Of-Record: true
Cc: "" <>
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
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

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
>> I’ll refer to as Dirk’s draft) and
>> (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<>),
>> 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 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 <>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