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

From: Eve Maler <[email-masked]>
Date: Fri, 1 Oct 2010 06:38:37 -0700

Glad to see this being worked on here.  I wanted to add a few requirements (and maybe, just maybe, a bit of a solution) into the mix.

As you may recall, in the UMA group we've been working on what we called a "Claims 2.0" spec (all UMA specs -- and some OAuth-related specs too -- are linked off of http://kantarainitiative.org/confluence/display/uma/Working+Drafts ).

UMA inserts claims into a slightly different place in the proceedings than core OAuth; the authz server can demand claims from a client before issuing an access token, so that the resource server doesn't have to implement sophisticated policy decision-making logic when it interprets claims (classic PEP/PDP separation). But I think the "claims" we're talking about are essentially the same.

The Claims 2.0 spec contains both a simple JSON-based sub-protocol for requesting and supplying claims, and an (unfinished) claims format.  I think we'd be happy to simply point to an existing claims format if it met our needs, and then define our very thin protocol around that.  (If you look at our short spec called Simple Access Authorization Claims, you'll see some use cases for the protocol piece.)

As long as the claims format spec is JSON-based, and allows each claim to be individually signed for third-party issuer authentication, and allows the claim type to be a URL, that's a big chunk of our requirements. Meeting our claims communication protocol needs is another, but I think it *should* be easy to do. We'll do an analysis on our end to highlight other requirements/use cases and bring them here.

Regarding discovery, the core UMA spec specifies how an authz server/manager can declare its supported claim formats in XRD for a resource server/host (and presumably other parties) to discover, and we might require a short list of such formats for UMA compliance. Our core spec assumes that the OAuth Dynamic Client Registration I-D we contributed (linked off our Working Drafts page), or similar, would be used for discovery of such information. If specific XRD (or JRD) discovery info were "sedimented" into such a spec at the OAuth table, particularly if it specified a suitable OAuth core compliance set, we'd happily point to it.

	Eve

On 28 Sep 2010, at 10:23 AM, Dirk Balfanz wrote:

> On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <[email-masked]> 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), 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.
>  
> ·         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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Yaron Goland <[email-masked]>
Date: Fri, 1 Oct 2010 22:41:13 +0000

No matter what algorithm or key size we pick the choice will prove unsupportable for any number of implementers due to everything from security issues (no matter what key size we pick, someone will have a real need for something larger) to legal issues (various countries have their own opinions about what to use where, a la the NSA suite list).

So we are going to have to support multiple algorithms and we are going to have to deal with algorithm negotiation. I literally can see no way around that.

                                Yaron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Wednesday, September 29, 2010 8:34 AM
To: Dirk Balfanz; Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

> 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.

I agree that there can be license issues that one could encounter with ECC (as we all did with RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that you don't have to support. We already have the issue of "do you support" with claims and token types, etc

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Tuesday, September 28, 2010 10:23 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

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

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

*         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.)

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

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

*         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 :)).
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.

                                                                -- Mike

---

From: John Panzer <[email-masked]>
Date: Fri, 1 Oct 2010 17:12:12 -0700

Quick note:

On Tue, Sep 28, 2010 at 10:23 AM, Dirk Balfanz <[email-masked]> wrote:

> On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <[email-masked]>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 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”).
>>
>> ·         Dirk’s draft utilizes a Magic Signatures envelope, whereas the
>> only “envelope” component of a JWT is the encoded signature.
>>
>> ·         *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.)
>>
>
>> ·         *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.
>
>
>>
>>

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 1 Oct 2010 20:44:54 -0700

On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <[email-masked]> wrote:

>  No matter what algorithm or key size we pick the choice will prove
> unsupportable for any number of implementers due to everything from security
> issues (no matter what key size we pick, someone will have a real need for
> something larger) to legal issues (various countries have their own opinions
> about what to use where, a la the NSA suite list).
>
>
>
> So we are going to have to support multiple algorithms and we are going to
> have to deal with algorithm negotiation. I literally can see no way around
> that.
>

I agree that over time, what will be considered secure will change. I also
agree that usually this means that there is some sort of negotiation
happening on what the two parties support. How would that happen here?
Remember that - as one datapoint - Google won't be able to support the ECC
algorithm. What happens when you can't support one of the proposed
algorithms, and there is no provision in the protocol to signal this to
other parties?

Dirk.

>
>
>                                 Yaron
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Anthony Nadalin
> *Sent:* Wednesday, September 29, 2010 8:34 AM
> *To:* Dirk Balfanz; Mike Jones
>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts
>
>
>
> don't, > please use ABC". Let's not do that.
>
>
>
> I agree that there can be license issues that one could encounter with ECC
> (as we all did with RSA), there are already customers that require ECC, and
> so there is a need to have alternative algorithms that you don’t have to
> support. We already have the issue of “do you support” with claims and token
> types, etc
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Dirk Balfanz
> *Sent:* Tuesday, September 28, 2010 10:23 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts
>
>
>
> ·         *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,

---

From: Mike Jones <[email-masked]>
Date: Sat, 2 Oct 2010 04:04:02 +0000

The situation you site is exactly analogous to the situation where sites need to determine what claims they need to exchange in order to be able to work together.

There is no provision in the protocol for signaling what claims you understand and require.  It's not that this isn't essential or that it won't happen.  It's just that it happens via mechanisms not specified in the protocol.
.
The same is true of the cryptographic algorithms employed to secure those claims.  If you're going to interact with a particular site, you need to understand what crypto algorithms both of you support (and that meet the security requirements of your particular application).  That needn't be in the core protocol any more than application-specific sets of claims do.

                                             -- Mike

From: Dirk Balfanz [mailto:[email-masked]]
Sent: Friday, October 01, 2010 8:45 PM
To: Yaron Goland
Cc: Anthony Nadalin; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <[email-masked]<mailto:[email-masked]>> wrote:
No matter what algorithm or key size we pick the choice will prove unsupportable for any number of implementers due to everything from security issues (no matter what key size we pick, someone will have a real need for something larger) to legal issues (various countries have their own opinions about what to use where, a la the NSA suite list).

I agree that over time, what will be considered secure will change. I also agree that usually this means that there is some sort of negotiation happening on what the two parties support. How would that happen here? Remember that - as one datapoint - Google won't be able to support the ECC algorithm. What happens when you can't support one of the proposed algorithms, and there is no provision in the protocol to signal this to other parties?

Dirk.

                                Yaron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anthony Nadalin
Sent: Wednesday, September 29, 2010 8:34 AM
To: Dirk Balfanz; Mike Jones

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dirk Balfanz
Sent: Tuesday, September 28, 2010 10:23 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

Commonalities:

Differences:

Dirk.

                                                                -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Oct 2010 07:37:22 +0000

I don't believe that negotiation (policy) has to be part of this proposal, so in the spec if one of the claims is not supported then the token MUST not be processed. We have this today in the web services security stack and there are really no issues.

Dirk.

                                Yaron

Commonalities:

Differences:

Dirk.

                                                                -- Mike

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 6 Oct 2010 14:26:02 -0700

So what's the proposal, then? That OAuth service providers document what
crypto mechanisms they support? And developers will just have to know which
alg to use with which service provider? I guess I could live with that...

Dirk.

On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <[email-masked]>wrote:

>  I don’t believe that negotiation (policy) has to be part of this
> proposal, so in the spec if one of the claims is not supported then the
> token MUST not be processed. We have this today in the web services security
> stack and there are really no issues.
>
>
>
> *From:* Dirk Balfanz [mailto:[email-masked]]
> *Sent:* Friday, October 01, 2010 8:45 PM
> *To:* Yaron Goland
> *Cc:* Anthony Nadalin; Mike Jones; [email-masked]
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 7 Oct 2010 07:18:26 +0000

I think that this would be the baseline and if there is interest in some sort of negotiation protocol then could take that up at  a later time, I know its not the best but we need to be able to support the government endorsed algorithms

From: Dirk Balfanz [mailto:[email-masked]]
Sent: Wednesday, October 06, 2010 2:26 PM
To: Anthony Nadalin
Cc: Yaron Goland; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

So what's the proposal, then? That OAuth service providers document what crypto mechanisms they support? And developers will just have to know which alg to use with which service provider? I guess I could live with that...

Dirk.
On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
I don't believe that negotiation (policy) has to be part of this proposal, so in the spec if one of the claims is not supported then the token MUST not be processed. We have this today in the web services security stack and there are really no issues.

From: Dirk Balfanz [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, October 01, 2010 8:45 PM
To: Yaron Goland
Cc: Anthony Nadalin; Mike Jones; [email-masked]<mailto:[email-masked]>

Dirk.

                                Yaron

Commonalities:

Differences:

Dirk.

                                                                -- Mike

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 7 Oct 2010 09:34:38 -0700

Ok, so in the spirit of convergence, I give you (optional) ECC - do you give
me Magic Signature Compact Serialization? :-)

Dirk.

On Thu, Oct 7, 2010 at 12:18 AM, Anthony Nadalin <[email-masked]>wrote:

>  I think that this would be the baseline and if there is interest in some
> sort of negotiation protocol then could take that up at  a later time, I
> know its not the best but we need to be able to support the government
> endorsed algorithms
>
>
>
> *Sent:* Wednesday, October 06, 2010 2:26 PM
> *To:* Anthony Nadalin
> *Cc:* Yaron Goland; Mike Jones; [email-masked]
>
> I don’t believe that negotiation (policy) has to be part of this proposal,
> so in the spec if one of the claims is not supported then the token MUST not
> be processed. We have this today in the web services security stack and
> there are really no issues.
>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 12 Oct 2010 18:21:52 +0900

JWT does not state anything about how keys are expressed while JT
(JSON Tokens)  has the
discovery in it as stated by the initial mail of this thread.

In my use case, I really need X.509 certs in the conventional sense to
establish trust.
So if key discovery is to be included, finding the X.509 certs through
given URI would be good.

Please see http://jsonenc.info/jss/1.0/ for what we are doing at
Artifact Binding WG.
(Hereafter, I refer it as JSS, JSON Simple Sign).

The envelope structure used in JSS is a bit different as well.
It is closer to JWT so that we only need to base64url encode the envelope
and then apply signature, so that we do not need concatenating
operation like Dirk's proposal.
The main difference is that JSS have "name spaced" the signature
parameters and payload
so that it is easy to process, as well as to avoid name space collision.
We are currently debating if we really need to have "payload" name
space though.
We could just stick in the "sig_params" to the original JSON structure.
(Pros about having "payload" is that then it will be able to sign
practically anything, BTW.)
If we make them completely flat, without any name spacing, it will be
same as the JWT
envelope. Down side for that is it is going to be hard to have
multiple signatures, which
we have in our use cases.

=nat

On Fri, Oct 8, 2010 at 1:34 AM, Dirk Balfanz <[email-masked]> wrote:
>> >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.
>>
>>
>>
>> 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
>> ·         To pad or not to pad:  The ‘=’ pad characters add length, are
>> 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.
>>
>>
>>
>> ·         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.
>> ·         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.
>>
>> ·         Unsigned tokens:  In some application contexts, it may make
>> ·         Key identification:  I agree that having means of identifying
>> ·         Discovery:  Like key distribution, I believe that an agreement
>> ·         Envelope structure:  Dirk’s draft proposes that the signed

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en