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

[Dirk Balfanz <[e-mail]>]

On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <[e-mail]>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.


> ·         *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
>
>
>