[OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2)
In -03 the link is still back to the same doc and now to an anchor that doesn't exist, https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section-7 rather than to the section in JWK/RFC7517 where I assume it's intended, http://tools.ietf.org/html/rfc7517#section-7 On Sun, Mar 22, 2015 at 8:13 PM, Brian Campbell bcampb...@pingidentity.com wrote: In §3.2. Proof-of-Possession of a Symmetric Key https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3.2 it has The rules for encrypting a JWK are found in Section 6 of the JSON Web Key [JWK] specification., which has two issues. 1) the Section 6 link is to the same document at https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-6 which kinda works because it's the References. But is probably not what was intended. I think http://www.ietf.org/mail-archive/web/jose/current/msg04571.html has some info on how to fix that kind of thing. 2) It should actually refer to section 7 https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-7 of JWK rather than 6 as section 6 is about String Comparison Rules and 7 is Encrypted JWK and Encrypted JWK Set Formats. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
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 sakim...@gmail.com
Cc: oauth oauth@ietf.org
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
sakim...@gmail.commailto:sakim...@gmail.com wrote:
+1
=nat via iPhone
2015/03/23 11:07、Brian Campbell
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com のメッセージ:
This is mostly about section
3.4https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.4data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=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
OAuth@ietf.orgmailto:OAuth@ietf.org
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
I'm fine updating the draft to say that the symmetric key can be carried in the jwk element in an unencrypted form if the JWT is itself encrypted. That's what you're looking for, right? -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 30, 2015 11:29 AM To: Brian Campbell bcampb...@pingidentity.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) Yes encrypting the claim should only be required when the entire JWT is not encrypted. I will have a look. John B. On Jul 30, 2015, at 3:12 PM, Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote: I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
Yep, that's what I'm looking for. Thanks. On Thu, Jul 30, 2015 at 1:57 PM, Mike Jones michael.jo...@microsoft.com wrote: I’m fine updating the draft to say that the symmetric key can be carried in the “jwk” element in an unencrypted form if the JWT is itself encrypted. That’s what you’re looking for, right? -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley *Sent:* Thursday, July 30, 2015 11:29 AM *To:* Brian Campbell bcampb...@pingidentity.com *Cc:* oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) Yes encrypting the claim should only be required when the entire JWT is not encrypted. I will have a look. John B. On Jul 30, 2015, at 3:12 PM, Brian Campbell bcampb...@pingidentity.com wrote: I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
Yes, I think that is reasonable. There is no point to double encrypting the key. On Jul 30, 2015, at 4:57 PM, Mike Jones michael.jo...@microsoft.com wrote: I’m fine updating the draft to say that the symmetric key can be carried in the “jwk” element in an unencrypted form if the JWT is itself encrypted. That’s what you’re looking for, right? -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 30, 2015 11:29 AM To: Brian Campbell bcampb...@pingidentity.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) Yes encrypting the claim should only be required when the entire JWT is not encrypted. I will have a look. John B. On Jul 30, 2015, at 3:12 PM, Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com wrote: I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
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 michael.jo...@microsoft.com 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 sakim...@gmail.com
Cc: oauth oauth@ietf.org
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 sakim...@gmail.com
mailto:sakim...@gmail.com wrote:
+1
=nat via iPhone
2015/03/23 11:07、Brian Campbell bcampb...@pingidentity.com
mailto:bcampb...@pingidentity.com のメッセージ:
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)
Some replies inline but the gist is that I disagree.
On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones michael.jo...@microsoft.com
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 sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*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
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
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 bcampb...@pingidentity.com
wrote:
Some replies inline but the gist is that I disagree.
On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones michael.jo...@microsoft.com
mailto:michael.jo...@microsoft.com 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
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
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 ve7...@ve7jtb.com 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 michael.jo...@microsoft.com
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 oauth-boun...@ietf.org] *On
Behalf Of *Brian Campbell
*Sent:* Thursday, July 30, 2015 11:29 AM
*To:* Nat Sakimura sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*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 sakim...@gmail.com
Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02
I cannot find any disposition of comment (DoC) to this review that the WG Chairs asked. Nor I see much of them reflected in -03. The process I would imagine to be the editors to 1) Provide the DoC [accept, discuss, reject (with reasons)], 2) Open up series of discussions on discuss items and drive towards the (rough) consensus. Since the diff between -02 and -03 is small, much of the above comments still applies. Looking forward to see the DoC. Nat 2015-03-25 22:37 GMT+09:00 Nat Sakimura sakim...@gmail.com: Dear OAuthers: Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02 Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 Abstract It is probably better to spell out that this document is describing the JWT format that can be used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier for the reader to understand what this document aims at. Accordingly, we should consider the title change to something like: JWT Sender Confirmation Token Syntax OR borrowing from the financial concept which I believe is the origin of the concept of bearer token, JWT Registered Token Syntax -- here, Registered mean that either the sender constraint or key confirmation is registered within or in conjunction with the token. 1. Introduction == Consider referencing draft-ietf-oauth-pop-architecture. It will be clearer for the reader then, and the text will be shorter. 2. Terminology - Presenter Sentence 1 --- Not sure if the first sentence is accurately reflecting the intent. It excludes rogue party presenting the token (and fails) from presenter. If so, it is fine but using more qualified term like authorized presenter may make it easier for the reader to parse. Otherwise revise the definition. Sentence 2 --- issuer or a party different from the issuer is not constraining anything and meaningless. There are more easier to parse and accurate text coming in the main text, too. Drop. 3. Proof-Of-Posession Representation == Title - Perhaps Sender Representation in JWT is more reflective of the content. Para 2 - The paragraph describes two ways of sender confirmation: (1) Sender Constraint (2) Key Confirmation It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the terminology. Then, it goes on to describe (1) very briefly, in which it is just spelling out iss and sub. I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. The JWT may well be about the sub but presented by some software component that should be independently identified. So my proposal is to create a new subsection on (1) for the completeness, which is going to be a new 3.1, and to use a claim like azp instead of sub to identify the presenter. Less overload would cause less confusion later, IMHO. 3.1 == Title Perhaps Confirmation Key Representation for an Asymmetric Key is more reflective of the content. 3.2 Title --- Perhaps Confirmation Key Representation for a Symmetric Key is more reflective of the content. Last Para - I feel a bit like needing to sniff into the content of jwk to find out what type may not be optimal, though I do not have a concrete proposal a this time. 3.3 == Title - Perhaps Confirmation Key Representation by Key ID is more reflective of the content. Para 1 --- There has been some discussion of using thumbprint instead of a blob kid. This is a valid option. If we are to overload the kid member for this purpose, we need to find a way to signal that it is a thumbprint. It may very well be better to define a separate member name then for the thumbprint. The title then changes to -- by Key ID to -- by reference. Also, it is conceivable to use the combination of kid and jku. This aspect is not spelled out here but appears that some magic happens for the key distribution. 3.4 Since cnf appears before 3.4, it may be better to bring 3.4 at the front. 5.2.2 = Add azp and jkt. o Confirmation Method Value: azp o Confirmation Method Description: Client ID of the Authorized Presenter o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] o Confirmation Method Value: jkt o Confirmation Method Description: JWK Thumbprint of the Confirmation Key o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] o
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
Yes encrypting the claim should only be required when the entire JWT is not encrypted. I will have a look. John B. On Jul 30, 2015, at 3:12 PM, Brian Campbell bcampb...@pingidentity.com wrote: I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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 sakim...@gmail.com wrote: +1 =nat via iPhone 2015/03/23 11:07、Brian Campbell bcampb...@pingidentity.com のメッセージ: 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2)
The text is now correct and you’re right where the link should go, but this appears to be a bug in the rfcmarkuphttps://tools.ietf.org/tools/rfcmarkup/ tool that automatically creates the HTMLized version from the .txt version. I’ll try to experiment to see if I can work around the bug – for instance, changing “Section 7 of the JSON Web Key [JWK] specification” to Section 7 of [JWK]” and see if that helps the tool get it right. I’ll also look into filing a bug on the tool. Thanks for double-checking, Brian. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, July 30, 2015 5:43 AM To: oauth Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2) In -03 the link is still back to the same doc and now to an anchor that doesn't exist, https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section-7https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-03%23section-7data=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=4mazqodL3i6qJrGKlUdVAA66%2bifTwrFxSNBQhxMwRao%3d rather than to the section in JWK/RFC7517 where I assume it's intended, http://tools.ietf.org/html/rfc7517#section-7https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7517%23section-7data=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=HR7d5qNE%2b61B8ti0h19cWHwpRS0p6%2fBaUQerQSHfAc0%3d On Sun, Mar 22, 2015 at 8:13 PM, Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote: In §3.2. Proof-of-Possession of a Symmetric Keyhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.2data=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=O8koxIiKG4KgbzGKrfAOy7kQ9YkRmGu4SlKTvLnfvoI%3d it has The rules for encrypting a JWK are found in Section 6 of the JSON Web Key [JWK] specification., which has two issues. 1) the Section 6 link is to the same document at https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-6https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-6data=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=Syxt3ZCKVio98eb3YVon7zSUZLJITiJiMfpI%2bhvwo1A%3d which kinda works because it's the References. But is probably not what was intended. I think http://www.ietf.org/mail-archive/web/jose/current/msg04571.htmlhttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg04571.htmldata=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=jsG7h0tpLLziNVWERyga2k624XO3qF6rvm3ylM3azIc%3d has some info on how to fix that kind of thing. 2) It should actually refer to section 7https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-json-web-key-41%23section-7data=01%7c01%7cMichael.Jones%40microsoft.com%7c5c412cf1fc9748899edf08d298dc724c%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=H4Er20uPM2HQwgpvg6koLJibn7JBRsrgGisfGmDU7Qg%3d of JWK rather than 6 as section 6 is about String Comparison Rules and 7 is Encrypted JWK and Encrypted JWK Set Formats. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
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 bcampb...@pingidentity.com
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 ve7...@ve7jtb.com
mailto:ve7...@ve7jtb.com 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 michael.jo...@microsoft.com
mailto:michael.jo...@microsoft.com 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 mailto:oauth-boun...@ietf.org]
On Behalf Of Brian Campbell
Sent: Thursday, July 30, 2015 11:29 AM
To: Nat Sakimura sakim...@gmail.com mailto:sakim...@gmail.com
Cc: oauth oauth@ietf.org mailto:oauth@ietf.org
Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
confirmation model in
[OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02
I typically do respond to review comments line-by-line but ran out of time to do this before Prague. (I was doing things like working with Brian on the Token Exchange deck, preparing my remarks to the COSE WG, etc.) I’ll plan to do this sometime early next week, which is the soonest I’ll be able to get to it, given other things currently on my plate. FYI, I did read through all of your and other’s comments and applied most of them – for instance, off the top of my head, clarifying how “azp” could be used in identifying the presenter, eliminating the need to sniff the “jwk” value, and updating the title to be more evocative of what the specification actually achieves. Cheers, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, July 30, 2015 6:36 PM To: oauth Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 I cannot find any disposition of comment (DoC) to this review that the WG Chairs asked. Nor I see much of them reflected in -03. The process I would imagine to be the editors to 1) Provide the DoC [accept, discuss, reject (with reasons)], 2) Open up series of discussions on discuss items and drive towards the (rough) consensus. Since the diff between -02 and -03 is small, much of the above comments still applies. Looking forward to see the DoC. Nat 2015-03-25 22:37 GMT+09:00 Nat Sakimura sakim...@gmail.commailto:sakim...@gmail.com: Dear OAuthers: Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02 Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=aAlUfVrPuS6gZpFdW89pHCw2DWrRcftagluPdgF3XzQ%3d Abstract It is probably better to spell out that this document is describing the JWT format that can be used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier for the reader to understand what this document aims at. Accordingly, we should consider the title change to something like: JWT Sender Confirmation Token Syntax OR borrowing from the financial concept which I believe is the origin of the concept of bearer token, JWT Registered Token Syntax -- here, Registered mean that either the sender constraint or key confirmation is registered within or in conjunction with the token. 1. Introduction == Consider referencing draft-ietf-oauth-pop-architecture. It will be clearer for the reader then, and the text will be shorter. 2. Terminology - Presenter Sentence 1 --- Not sure if the first sentence is accurately reflecting the intent. It excludes rogue party presenting the token (and fails) from presenter. If so, it is fine but using more qualified term like authorized presenter may make it easier for the reader to parse. Otherwise revise the definition. Sentence 2 --- issuer or a party different from the issuer is not constraining anything and meaningless. There are more easier to parse and accurate text coming in the main text, too. Drop. 3. Proof-Of-Posession Representation == Title - Perhaps Sender Representation in JWT is more reflective of the content. Para 2 - The paragraph describes two ways of sender confirmation: (1) Sender Constraint (2) Key Confirmation It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the terminology. Then, it goes on to describe (1) very briefly, in which it is just spelling out iss and sub. I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. The JWT may well be about the sub but presented by some software component that should be independently identified. So my proposal is to create a new subsection on (1) for the completeness, which is going to be a new 3.1, and to use a claim like azp instead of sub to identify the presenter. Less overload would cause less confusion later, IMHO. 3.1 == Title Perhaps Confirmation Key Representation for an Asymmetric Key is more reflective of the content. 3.2 Title --- Perhaps Confirmation Key Representation for a Symmetric Key is more reflective of the content. Last Para - I feel a bit like needing to sniff into the content of jwk to find out what type may
