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

[John Bradley]

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  
> 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  > wrote:
> 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 > > wrote:
>> 
>> Some replies inline but the gist is that I disagree. 
>> 
>> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones > > 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
>> 
>> If you add other kind of confirmation keys, things would continue to get 
>> even sillier.
>> 
>> 
>> 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 tru

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

[Brian Campbell]

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  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.
>
> 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 
> 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  wrote:
>
>> 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 
>> 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”: …}
>> }
>>
>> 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 savi

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

[Brian Campbell]

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  wrote:

> 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 
> wrote:
>
> Some replies inline but the gist is that I disagree.
>
> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones 
> 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
>>
>> If you add other kind of confirmation keys, things would continue to get
>> even sillier.
>>
>
> 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

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

[John Bradley]

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  
> 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  > wrote:
> 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 > > 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”: …}
>> }
>>  
>> 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:oauth-boun...@ietf.org ] 
>> On Behalf Of Brian Campbell
>> Sent: Thursday, July 30, 2015 11:29 AM
>> To: Nat Sakimura mailto:sakim...@gmail.com>>
>> Cc: oauth mailto:oauth@ietf.org>>
>> Subject: [OAUTH-WG] JWT PoP Key Sema

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

[John Bradley]

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  
> wrote:
> 
> Some replies inline but the gist is that I disagree. 
> 
> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones  > 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
> 
> If you add other kind of confirmation keys, things would continue to get even 
> sillier.
> 
> 
> 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

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

[Brian Campbell]

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  wrote:

> 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 
> 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”: …}
> }
>
> 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:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Thursday, July 30, 2015 11:29 AM
> *To:* Nat Sakimura 
> *Cc:* oauth 
> *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  wrote:
>
> +1
>
> =

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

[Brian Campbell]

Some replies inline but the gist is that I disagree.

On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones 
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
>
> If you add other kind of confirmation keys, things would continue to get
> even sillier.
>

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:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 30, 2015 11:29 AM
> *To:* Nat Sakimura 
> *Cc:* oauth 
> *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.
>
> Seem

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

[John Bradley]

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  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”: …}
> }
>  
> 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:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, July 30, 2015 11:29 AM
> To: Nat Sakimura 
> Cc: oauth 
> 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  > wrote:
> +1
> 
> =nat via iPhone
> 
> 2015/03/23 11:07、Brian Campbell  > のメッセージ:
> 
> This is mostly about section 3.4 
> 

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

[Mike Jones]

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:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 30, 2015 11:29 AM
To: Nat Sakimura 
Cc: oauth 
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 
mailto:sakim...@gmail.com>> wrote:
+1

=nat via iPhone

2015/03/23 11:07、Brian Campbell 
mailto:bcampb...@pingidentity.com>> のメッセージ:
This is mostly about 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth