Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Jul 2015 12:29:03 -0600

Using individual claims for the different confirmation types would convey
the same information with a reduced message size, likely simpler
implementation, and avoid the need to establish a new registry.

Seems like a no-brainer to me but maybe I'm overlooking something?

There hasn't been much discussion that I'm aware of. Nat seemed in favor of
it (the +1 below). Mike was dismissive of it at the Dallas meeting but
didn't provide any reasoning (that I understood anyway).

On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <[email-masked]> wrote:

> +1
>
> =nat via iPhone
>
> 2015/03/23 11:07、Brian Campbell <[email-masked]> のメッセージ:
>
> This is mostly about section 3.4
> <https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3.4>
> but also the whole draft.
>
> If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation
> element, it should probably contain an array value rather than an object
> value. SAML allows not just for multiple methods of confirming but for
> multiple instances of the same method. IIRC, only one confirmation needs to
> be confirmable.
>
> I'm not sure the extra complexity is worth it though. I've rarely, if
> ever, seen SAML assertions that make use of it.
>
> If the intent is just to allow for different kinds of confirmation,
> couldn't the structure be pared down and simplified and just have
> individual claims for the different confirmation types? Like "cjwk" and
> "ckid" or similar that have the jwk or kid value respectively as the member
> value.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 Jul 2015 20:17:32 +0000

Part of the reasoning for using a structured confirmation claim, rather than flattening the confirmation claim into the top-level JWT claims set, is that a JWT may carry more than one conformation key or key descriptor, as was mentioned in Prague.  For instance, imagine that an application is conveying an application-level confirmation key using the “cnf” claim and for instance a token binding key using a second instance of the confirmation structure, say using the “tokbnd” claim.  With the current structured approach, you’d have:

{…
“cnf”:{“jwk”: …},
“tokbnd”:{“jwk”: …}
}

If one were to flatten the structure, however, unique claim names would have to be produced for the cross-product of each conformation element and each confirmation claim.  So you’d end up defining and registering these claims in the top-level JWT Claims registry:
                cnf_jwk
                cnf_jwe
                cnf_kid
                tokbnd_jwk
                tokbnd_jwe
                tokbnd_kid
If you add other kind of confirmation keys, things would continue to get even sillier.

The code will be simpler if you can have a single shared routine for handling confirmation structures rather a separate for handling cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, tokbnd_kid, etc.

Another reason the structure makes things conceptually simpler is that then you can always use the name “kid” to hold a key ID, no matter the context, rather than having to use name-your-prefix_kid.  The same holds true for other elements.

I’m sorry this wasn’t clear in Prague.  I know it was mentioned in the context of carrying multiple confirmation keys in a JWT, but it went by pretty fast.

Based on the discussion in Prague, I believe that we should add language to the spec saying that applications can define new claim names other than “cnf” to use to represent application-specific confirmation structures that have the same syntax as those using the “cnf” name.  Would that do the trick for you?

By the way, I’m as much in favor of compactness as anyone.  Heck – I was one of the folks who foisted the short claim names like “iss” on the world!  But I really do believe that in this case, having structure makes things more readable and more flexible, especially since there will be cases where there are multiple confirmation structures in the same JWT.  And once you prefix the names, you lose most of the space savings anyway.

                                                                Best wishes,
                                                                -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, July 30, 2015 11:29 AM
To: Nat Sakimura <[email-masked]>
Cc: oauth <[email-masked]>
Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)

Using individual claims for the different confirmation types would convey the same information with a reduced message size, likely simpler  implementation, and avoid the need to establish a new registry.

Seems like a no-brainer to me but maybe I'm overlooking something?
There hasn't been much discussion that I'm aware of. Nat seemed in favor of it (the +1 below). Mike was dismissive of it at the Dallas meeting but didn't provide any reasoning (that I understood anyway).

On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
+1

=nat via iPhone

2015/03/23 11:07、Brian Campbell <[email-masked]<mailto:[email-masked]>> のメッセージ:
This is mostly about section 3.4<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.4&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2dHZxIhDc2jtu1krNFIccKamceZvM4%2b7Yw0hJGA6WcY%3d> but also the whole draft.

If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation element, it should probably contain an array value rather than an object value. SAML allows not just for multiple methods of confirming but for multiple instances of the same method. IIRC, only one confirmation needs to be confirmable.
I'm not sure the extra complexity is worth it though. I've rarely, if ever, seen SAML assertions that make use of it.
If the intent is just to allow for different kinds of confirmation, couldn't the structure be pared down and simplified and just have individual claims for the different confirmation types? Like "cjwk" and "ckid" or similar that have the jwk or kid value respectively as the member value.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jwMvoc50hKttPr1u5gwWLmmCI9k3zumK8RtzWR2F7w0%3d>

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Jul 2015 18:14:17 -0300

I agree, flattening would be a bad direction.

In Prague I was indicating that there may be more than one presenter for an assertion.  The first presenter may be the OAuth client who presents it to a RS.

That RS itself may also present that token as a client in token exchange to get a new access token for another resource.

The initial AS may want to bind that token to two presenters.   The second AS doing the token exchange also probably only wants to know about the proof key for the RS so that it doesn’t mistakenly give the first client a token to directly access a backend API.

Trying to find a generic pattern for that is a bit of a trick though.

I think that a single cnf element is enough for most use cases, however having cnf and cnf_rs or some other element using the cnf structure is probably the best we can do at this point.

John B.
> On Jul 30, 2015, at 5:17 PM, Mike Jones <[email-masked]> wrote:
> 
> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> =nat via iPhone
> 
> 2015/03/23 11:07、Brian Campbell <[email-masked] <mailto:[email-masked]>> のメッセージ:
> 
> This is mostly about section 3.4 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.4&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2dHZxIhDc2jtu1krNFIccKamceZvM4%2b7Yw0hJGA6WcY%3d> but also the whole draft.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jwMvoc50hKttPr1u5gwWLmmCI9k3zumK8RtzWR2F7w0%3d>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Jul 2015 16:40:34 -0600

Some replies inline but the gist is that I disagree.

On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones <[email-masked]>
wrote:

> Part of the reasoning for using a structured confirmation claim, rather
> than flattening the confirmation claim into the top-level JWT claims set,
> is that a JWT may carry more than one conformation key or key descriptor,
> as was mentioned in Prague.  For instance, imagine that an application is
> conveying an application-level confirmation key using the “cnf” claim and
> for instance a token binding key using a second instance of the
> confirmation structure, say using the “tokbnd” claim.  With the current
> structured approach, you’d have:
>
>
>
> {…
>
> “cnf”:{“jwk”: …},
>
> “tokbnd”:{“jwk”: …}
>
> }
>
>
>

That presumes token binding will use the same confirmation methods. But I'd
imagine that the Token Binding ID would somehow be used to signal
confirmation. So I'd be surprised if it ends up looking like that. The jwe
member of the cnf claim defiantly wouldn't apply.

It also presumes that you'd want cnf and tokbnd in the same JWT, which
doesn't really make sense to me. This draft wants to establish a registry
for JWT Confirmation Methods but a token binding confirmation would be a
different claim?

> If one were to flatten the structure, however, unique claim names would
> have to be produced for the cross-product of each conformation element and
> each confirmation claim.  So you’d end up defining and registering these
> claims in the top-level JWT Claims registry:
>
>                 cnf_jwk
>
>                 cnf_jwe
>
>                 cnf_kid
>
>                 tokbnd_jwk
>
>                 tokbnd_jwe
>
>                 tokbnd_kid
>

Again that presumes token binding will use the same confirmation methods,
which I think it unlikely.

I suspect it'd be more like cjwk, cjwe, ckid, and ctbd.

And a cnf with nested structure would need a tbd or tokbnd member defined
and registered.

>
>
> The code will be simpler if you can have a single shared routine for
> handling confirmation structures rather a separate for handling cnf_jwk,
> cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe,
> tokbnd_kid, etc.
>

You can still have a shared routine for handling things that are the same.
But with a nested structure you have to dig into the nesting.

>
>
> Another reason the structure makes things conceptually simpler is that
> then you can always use the name “kid” to hold a key ID, no matter the
> context, rather than having to use *name-your-prefix*_kid.  The same
> holds true for other elements.
>

I personally don't find that convincing. It depends on how someone thinks
about it.

>
>
> I’m sorry this wasn’t clear in Prague.  I know it was mentioned in the
> context of carrying multiple confirmation keys in a JWT, but it went by
> pretty fast.
>

It was an informal discussion that was largely about something else.

>
>
> Based on the discussion in Prague, I believe that we should add language
> to the spec saying that applications can define new claim names other than
> “cnf” to use to represent application-specific confirmation structures that
> have the same syntax as those using the “cnf” name.  Would that do the
> trick for you?
>

That's not at all what I'm driving at.

If you believe that there's need for multiple confirmation structures with
the exact same syntax and meaning, I suppose that would be a useful
addition. But if you really believe that, the structure itself should
probably be adjusted to allow for multiples. I'm skeptical that it'll ever
be needed.

>
>
> By the way, I’m as much in favor of compactness as anyone.  Heck – I was
> one of the folks who foisted the short claim names like “iss” on the
> world!  But I really do believe that in this case, having structure makes
> things more readable and more flexible, especially since there will be
> cases where there are multiple confirmation structures in the same JWT.
>

I can see both sides of readability. I don't see the flexibility.

> And once you prefix the names, you lose most of the space savings anyway.
>

Depends on how you prefix them or otherwise name things. You've chosen long
prefixes to make your point but it wouldn't have to be that way.

>
>
>                                                                 Best
> wishes,
>
>                                                                 -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 30, 2015 11:29 AM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
> confirmation model in proof-of-possession-02)
>
>
>
> There hasn't been much discussion that I'm aware of. Nat seemed in favor
> of it (the +1 below). Mike was dismissive of it at the Dallas meeting but
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.4&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2dHZxIhDc2jtu1krNFIccKamceZvM4%2b7Yw0hJGA6WcY%3d>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jwMvoc50hKttPr1u5gwWLmmCI9k3zumK8RtzWR2F7w0%3d>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Jul 2015 16:48:03 -0600

To really support that case where an initial AS/issuer wants to bind to two
presenters, shouldn't the confirmation structure itself allow for multiple
confirmation methods (i.e. be or allow for an array)?  I don't actually
think that is needed but the flexibility that's being argued for here would
suggest that rather than renaming a nested structure that only allows for a
single occurrence of each kind of confirmation method.

On Thu, Jul 30, 2015 at 3:14 PM, John Bradley <[email-masked]> wrote:

> In Prague I was indicating that there may be more than one presenter for
> an assertion.  The first presenter may be the OAuth client who presents it
> to a RS.
>

> That RS itself may also present that token as a client in token exchange
> to get a new access token for another resource.
>
> The initial AS may want to bind that token to two presenters.   The second
> AS doing the token exchange also probably only wants to know about the
> proof key for the RS so that it doesn’t mistakenly give the first client a
> token to directly access a backend API.
>

> I think that a single cnf element is enough for most use cases, however
> having cnf and cnf_rs or some other element using the cnf structure is
> probably the best we can do at this point.
>
> John B.
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Brian Campbell

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Jul 2015 19:52:33 -0300

Token binding might be a bad example.

I can’t see why you would need something separate unless you are trying to do something like message signing and token binding.  
I guess that is theoretically posable.

Typically I think token binding would use the normal cnf containing a JWK with the public key.

The difference between token binding and mutual TLS is in the presentment one is TLS client auth and the other is a signature over the tls unique in a header.

I think multiple cnf methods for the same presenter like SAML is overkill.

However the ability to re-use the cnf structure for people who want something custom seems reasonable (we couldn't stop them anyway)

John B.
> On Jul 30, 2015, at 7:40 PM, Brian Campbell <[email-masked]> wrote:
> 
> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> That presumes token binding will use the same confirmation methods. But I'd imagine that the Token Binding ID would somehow be used to signal confirmation. So I'd be surprised if it ends up looking like that. The jwe member of the cnf claim defiantly wouldn't apply. 
> 
> It also presumes that you'd want cnf and tokbnd in the same JWT, which doesn't really make sense to me. This draft wants to establish a registry for JWT Confirmation Methods but a token binding confirmation would be a different claim?
> 
>  
> 
> Again that presumes token binding will use the same confirmation methods, which I think it unlikely.
> 
> And a cnf with nested structure would need a tbd or tokbnd member defined and registered. 
>  
> 
>  
> 
> You can still have a shared routine for handling things that are the same. But with a nested structure you have to dig into the nesting.
>  
> 
>  
> 
> I personally don't find that convincing. It depends on how someone thinks about it. 
>  
> 
>  
> 
> If you believe that there's need for multiple confirmation structures with the exact same syntax and meaning, I suppose that would be a useful addition. But if you really believe that, the structure itself should probably be adjusted to allow for multiples. I'm skeptical that it'll ever be needed.
>  
> 
>  
> 
> By the way, I’m as much in favor of compactness as anyone.  Heck – I was one of the folks who foisted the short claim names like “iss” on the world!  But I really do believe that in this case, having structure makes things more readable and more flexible, especially since there will be cases where there are multiple confirmation structures in the same JWT. 
> 
> 
> Depends on how you prefix them or otherwise name things. You've chosen long prefixes to make your point but it wouldn't have to be that way. 
>  
> 
>  
> 
>                                                                 Best wishes,
> 
>                                                                 -- Mike
> 
>  
> 
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Campbell
> To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>
> Cc: oauth <[email-masked] <mailto:[email-masked]>>

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Jul 2015 20:00:18 -0300

In my example you don’t really want to treat both the presenters as equivalent.  Endpoints receiving the token should be able to tell which presenter gave it to them and apply policy on that.

If you wanted them to be equivalent then an array would work, but that probably adds more confusion.

John B.
> On Jul 30, 2015, at 7:48 PM, Brian Campbell <[email-masked]> wrote:
> 
> To really support that case where an initial AS/issuer wants to bind to two presenters, shouldn't the confirmation structure itself allow for multiple confirmation methods (i.e. be or allow for an array)?  I don't actually think that is needed but the flexibility that's being argued for here would suggest that rather than renaming a nested structure that only allows for a single occurrence of each kind of confirmation method. 
> 
> On Thu, Jul 30, 2015 at 3:14 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 30, 2015, at 5:17 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Jul 2015 12:46:39 -0600

The Token Binding ID already has the public key in it. A normal cnf
containing a JWK with the public key would work. But the whole Token
Binding ID would probably be simpler. Or, if we're gonna make them parse
the Token Binding ID, then a cnf that uses a finger/thumbprint of the key
would be more space efficient as the whole key is already being sent
elsewhere. That's all stuff that can be worked out later though. What I'm
trying to express is that we don't really know what kind of flexibility
will be needed and it's not at all clear that a structured cnf claim gives
flexibility.

On Thu, Jul 30, 2015 at 4:52 PM, John Bradley <[email-masked]> wrote:

> I can’t see why you would need something separate unless you are trying to
> do something like message signing and token binding.
> The difference between token binding and mutual TLS is in the presentment
> one is TLS client auth and the other is a signature over the tls unique in
> a header.
>
> However the ability to re-use the cnf structure for people who want
> something custom seems reasonable (we couldn't stop them anyway)
>
> John B.
>
> That presumes token binding will use the same confirmation methods. But
> I'd imagine that the Token Binding ID would somehow be used to signal
> Depends on how you prefix them or otherwise name things. You've chosen
> long prefixes to make your point but it wouldn't have to be that way.
>
>
>>
>>
>>                                                                 Best
>> wishes,
>>
>>                                                                 -- Mike
>>
>>
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Jul 2015 12:54:34 -0600

Don't get me wrong, I don't think an array is needed at all (and I fear the
language in the draft that draws an analogy to SAML is maybe more likely to
confuse than help). I just don't buy the argument that the nested structure
is so much more flexible for these hypothetical cases.

I seem to be in the minority here though (at least of the few people
actually responding). And, while I thought there was room for a nice
simplification, it's not something I care to fight (much) about.

On Thu, Jul 30, 2015 at 5:00 PM, John Bradley <[email-masked]> wrote:

> In my example you don’t really want to treat both the presenters as
> equivalent.  Endpoints receiving the token should be able to tell which
> presenter gave it to them and apply policy on that.
>
> To really support that case where an initial AS/issuer wants to bind to
> two presenters, shouldn't the confirmation structure itself allow for
> multiple confirmation methods (i.e. be or allow for an array)?  I don't
> actually think that is needed but the flexibility that's being argued for
> here would suggest that rather than renaming a nested structure that only
> allows for a single occurrence of each kind of confirmation method.
>
>> The initial AS may want to bind that token to two presenters.   The
>> second AS doing the token exchange also probably only wants to know about
>> the proof key for the RS so that it doesn’t mistakenly give the first
>> client a token to directly access a backend API.
>>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 31 Jul 2015 16:11:09 -0300

Yes the token binding token has the public key so yes you could send the JWK thumbprint of the key in the cnf method vs sending the JWK again to save space.  That is something we can add later as a confirmation method.

I prefer the structured approach even if it takes another registry.  I think it is easer to understand.  I agree that we don’t want to oversell the relationship to SAML confirmation methods. 
This is POP confirmation not the more abstract subject confirmation (that has pop as one option).

John B.

> On Jul 31, 2015, at 3:46 PM, Brian Campbell <[email-masked]> wrote:
> 
> The Token Binding ID already has the public key in it. A normal cnf containing a JWK with the public key would work. But the whole Token Binding ID would probably be simpler. Or, if we're gonna make them parse the Token Binding ID, then a cnf that uses a finger/thumbprint of the key would be more space efficient as the whole key is already being sent elsewhere. That's all stuff that can be worked out later though. What I'm trying to express is that we don't really know what kind of flexibility will be needed and it's not at all clear that a structured cnf claim gives flexibility. 
> 
> 
> 
> On Thu, Jul 30, 2015 at 4:52 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 30, 2015, at 7:40 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>