Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 15 Apr 2020 14:59:00 -0400

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".

Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,

 Rifaat & Hannes

---

From: Dominick Baier <[email-masked]>
Date: Thu, 16 Apr 2020 00:10:05 -0700

Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.

*client_id vs sub*
I am still not entirely happy with the “re-purposing” of the claim types
based on flow.
If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and
client.

Furthermore it says

"Authorization servers should prevent scenarios where clients can
   affect the value of the sub claim in ways that could confuse resource
   servers.”

If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.

Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.

*audience claim*
I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don’t exist, you'd need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What’s the
value of that?

If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn’t make it required.

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the .NET one) looking for nbf by default?

*General*
This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn’t work
one way or the other for them.

I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the
“at+jwt” typ. For the rest I’d rather like to see just some standard claims
and IF they are used, which semantics they have.

cheers
———
Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef ([email-masked])
wrote:

Hi all,

Here is the document:

Regards,

 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 16 Apr 2020 12:08:43 -0700

Section 2.1 says:

> Although JWT access tokens can use any signing algorithm, use of
> asymmetric algorithms is RECOMMENDED

Can this be strengthened to disallow the `none` algorithm? Something like
adding "... and MUST NOT use the "none" algorithm".

Given that the JWT BCP doesn't disallow the "none" algorithm, technically
someone could follow both this JWT Access Token spec and the JWT BCP spec
and end up with an implementation that allows an AS to accept JWTs with the
"none" algorithm.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Apr 2020 14:11:46 -0600

sec 4 does have "The resource server MUST reject any JWT in which the value
of "alg" is "none".'

On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki <[email-masked]> wrote:

> @aaronpk <http://twitter..com/aaronpk>
>
>
>
>> This is a second working group last call for "JSON Web Token (JWT)
>> Profile for OAuth 2.0 Access Tokens".
>>
>>
>>
>> Here is the document:
>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 16 Apr 2020 13:13:51 -0700

My mistake! In that case, my request is editorial, to mention that in
section 2.1 where it first talks about signing algorithms.

----
Aaron Parecki
aaronparecki.com

On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell <[email-masked]>
wrote:

> sec 4 does have "The resource server MUST reject any JWT in which the
> value of "alg" is "none".'
>
>> On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <
>> [email-masked]> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Apr 2020 14:15:31 -0600

I'll +1 that

On Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki <[email-masked]> wrote:

>>> Can this be strengthened to disallow the `none` algorithm? Something
>>> like adding "... and MUST NOT use the "none" algorithm".
>>>
>>> Given that the JWT BCP doesn't disallow the "none" algorithm,
>>> technically someone could follow both this JWT Access Token spec and the
>>> JWT BCP spec and end up with an implementation that allows an AS to accept
>>> JWTs with the "none" algorithm.
>>>
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sun, 19 Apr 2020 11:50:30 +0300

> libraries (including e.g. the .NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir

---

From: David Waite <[email-masked]>
Date: Sun, 19 Apr 2020 22:59:31 -0600

There are a number of ambiguities and statements around using JWTs in various contexts:

1. Some implementations interpret “iat" to also have the meaning of “nbf” in the absence of “nbf”, although this is AFAIK not prescribed by any spec
2. The DPoP draft’s client-generated tokens have the resource servers use their own nbf/exp heuristics around “iat”, since the tokens are meant for immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may reject tokens based on an “iat” too far in the past or “exp” too far in the future, but not that “nbf” was too far in the past or that the interval between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock skew. Presumably this meant validators and not JWT creators, although there is history of messages setting similar values to account for clock skew (e.g. SAML IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 minutes after issuance). 

-DW

> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
>> iat vs nbf
>> What’s the rationale for using iat instead of nbf. Aren’t most JWT libraries (including e.g. the .NET one) looking for nbf by default?
> Developers often tend to intuitively pick up "iat" over "nbf" because it sounds more meaningful (my private observation). So given the empirical approach of Vittorio to the spec, I suspect that's how "iat" got here.
> 
> If we bother to carefully look at the JWT spec we'll see that "iat" is meant to be "informational" whereas it's "nbf" that is intended to serve (together with "exp") in determining the actual validity window of the JWT.
> 
> https://tools.ietf.org/html/rfc7519#section-4.1.5 <https://tools.ietf.org/html/rfc7519#section-4.1.5>
> My suggestion is to require either "iat" or "nbf". That shouldn't break anything, and deployments that rely on one or the other to determine the validity window of the access token can continue using their preferred claim for that.
> 
> Vladimir
>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 20 Apr 2020 02:50:27 -0400

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what’s the difference between the two
practically speaking - and shouldn’t be the more common (aka supported by
most libraries) be used?

———
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=[email-masked]) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret “iat" to also have the meaning of “nbf”
in the absence of “nbf”, although this is AFAIK not prescribed by any spec
2. The DPoP draft’s client-generated tokens have the resource servers use
their own nbf/exp heuristics around “iat”, since the tokens are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an “iat” too far in the past or “exp” too far in the
future, but not that “nbf” was too far in the past or that the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <[email-masked]>
wrote:

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the ..NET one) looking for nbf by default?

Vladimir

---

From: Philippe De Ryck <[email-masked]>
Date: Mon, 20 Apr 2020 09:05:48 +0200

In theory, you can issue a token that only becomes valid in the future. That would have a different iat and nbf timestamp. I have not seen this in practice though. 

Given that RFC 7519 lists “iat” as informative, I would not change that behavior in a specific use case if there is no significant need to do so.

Philippe

> On 20 Apr 2020, at 08:50, Dominick Baier <[email-masked]> wrote:
> 
> I guess my real question is - what’s the difference between the two practically speaking - and shouldn’t be the more common (aka supported by most libraries) be used?
> 
> ———
> Dominick Baier
> 
> On 20. April 2020 at 06:59:47, David Waite (david=[email-masked] <mailto:david=[email-masked]>) wrote:
> 
>>> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> What’s the rationale for using iat instead of nbf. Aren’t most JWT libraries (including e.g. the ..NET one) looking for nbf by default?
>>> OAuth@ietf..org <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 20 Apr 2020 03:43:14 -0400

Hence my question

What should be the recommended semantics - “informative” - “or don’t accept
before a certain time stamp” ?

———
Dominick Baier

On 20. April 2020 at 09:05:53, Philippe De Ryck (
[email-masked]) wrote:

In theory, you can issue a token that only becomes valid in the future.
That would have a different iat and nbf timestamp. I have not seen this in
practice though.

Given that RFC 7519 lists “iat” as informative, I would not change that
behavior in a specific use case if there is no significant need to do so.

Philippe

———
Dominick Baier

-DW

*iat vs nbf*

Vladimir
_______________________________________________
OAuth mailing list
OAuth@ietf..org <[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: <[email-masked]>
Date: Mon, 20 Apr 2020 00:48:49 -0700

Thanks Dominick for your comments!

Inline

> All other OAuth specs make a very clear distinction between users and client.

There’s a nuance worth highlighting here: sub != user. In previous discussions on this topic it has been brought up that the JWT spec defines sub as identifying the principal that is the subject of the JWT, and that’s not necessarily limited to users. 

However I get the potential confusion, and I am happy to add clarifying language if you have specific passages in the space you are particularly worried about: however I feel the matter is addressed upfront by the language in Section 2.2. in the sub entry, “In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application.“ and Section 5 has an entire paragraph discussing things to watch out in assigning sub values in the app identity case. Feel free to suggest additional language if you want to clarify further. 

> sub has a different semantic here as in OIDC

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC, to preempt that concern and keep the original sub semantic available.

> I am not fully clear why aud is required.

Aud is there mostly because of three reasons:

*	Many existing specs postulate its existence in the token. No one declares it as a proper MUST (apart from the BCP, but that’s partial) however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mechanism to prevent token redirect (and adds scope restriction as also important, however here we make it optional to acocut for non-delegations scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one of the assumptions that must hold to prevent bearer tokens misuse 
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one app
*	Apart from Ping, for which some of its examples are without aud (but also without identifying scopes, given that the one I retrieved had only “openid”), all of the sample JWT ATs I received from vendors all featured an aud. I know one shoulnd’t overindex on those examples, but together with the above it seemed to point to something universally useful. One possible reason is that use of a format for the AT is correlated with topologies where AS and RS are separated by some boundary (network, logical, business, code factoring, etc) hence identifying the resource seems like a natural need. Again, not an iron clad law, but an indication.
*	A lot of people repurpose existing libraries for the JWT AT case, and some people even sends id_tokens in lieu of ATs. That doesn’t mean that we should condone any bad practices, but in tis particular case it suggests that lots of developers already expect/can handle an audience in the JWT used to call their API

None of those are a slam dunk argument for mandatory, but I find them compelling enough to simplify validation and just require an aud to be there, as opposed to introduce complications that make it conditional to the presence of scopes or other disambiguation. One reason I feel pretty good about that is that adding a default audience isn’t very hard if any of the above assumptions end up not being true for a particular case

> What’s the rationale for using iat instead of nbf. 

That’s just straight from OIDC ID_tokens, and the considerations about repurposing existing logic. I see there’s a thread on this specifically, let me answer further on that branch.

> This spec feels somehow in between a profile and a BCP

You are right that this spec attempts to go beyond just declaring a layout, and I agree this means that this profile will not apply to absolutely everyone. The reason I tried that route (at the cost of working way harder in the last year for reaching consensus than if we would have just listed the possible content), is that I often observe implementers make questionable choices because of the large leeway specifications allow. My hope was that the scope of this profile was small enough to make that extra level of guidance achievable, whereas trying to do the same with a larger spec would have been prohibitively expensive. 

I believe things worked out well so far: we had lots of constructive discussions, and I ended up relaxing A LOT of the constraints I was originally envisioning. Nonetheless, my hope is that we identified the right set of guidelines that will help people actually interoperate out of the box for the most basic/common scenarios, as opposed to complying with the letter of the spec but still having a lot to figure out out of band. 

From: OAuth <[email-masked]> On Behalf Of Dominick Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: Rifaat Shekh-Yusef <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Since this is the last call, I thought I bring up some of thoughts / concerns. Some of them have been discussed before.

client_id vs sub

I am still not entirely happy with the “re-purposing” of the claim types based on flow.

If the intention is, that sub expresses the entity against which the resource will do authorisation (and that might be a client or a user) - I get it (and maybe it should be stated like that) - but

this thinking reminds me of the old AD days where there was no distinction between user and service accounts (something that has been fixed IIRC in Windows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and client.

Furthermore it says

   servers.”

If we keep that dual semantics of the sub claim - it must be clearly stated, that subject ID and client ID are now in the same collision domain. So when an AS / OP creates them, they need to be unique across user ids and client ids.

Maybe it should be also explicitly mentioned that sub has a different semantic here as in OIDC - even though a majority of the software built today will use them together.

audience claim

I am not fully clear why aud is required. OAuth itself does not have a notion of an audience (in the JWT sense) - they have scopes (which is very similar). But in simple scenarios where resources don’t exist, you'd need to make up an audience just to fulfil this requirement. And in many case this will be either static or just repeat the scope values. What’s the value of that?

If the concept of resources are used, I absolutely agree that aud should be used too. But I wouldn’t make it required.

iat vs nbf

General

This spec feels somehow in between a profile and a BCP. On one hand you define some claims and their semantics (good) - on the other hand there is some prescriptive guidance and maybe over-specification. My concern is, that in the end no-one will fully comply with it, because it doesn’t work one way or the other for them.

I know we just went though the discussion to make certain claims required as opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the “at+jwt” typ. For the rest I’d rather like to see just some standard claims and IF they are used, which semantics they have.

cheers 

———

Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef ([email-masked] <mailto:[email-masked]> ) wrote:

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".

Here is the document:

Regards,

 Rifaat & Hannes

---

From: <[email-masked]>
Date: Mon, 20 Apr 2020 00:49:44 -0700

Thanks for the catch! Will add a mention of that in section 2.1 as well.

From: OAuth <[email-masked]> On Behalf Of Brian Campbell
Sent: Thursday, April 16, 2020 1:16 PM
To: Aaron Parecki <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I'll +1 that 

On Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki <[email-masked] <mailto:[email-masked]> > wrote:

My mistake! In that case, my request is editorial, to mention that in section 2.1 where it first talks about signing algorithms.

----

Aaron Parecki

aaronparecki.com <http://aaronparecki.com> 

 

On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell <[email-masked] <mailto:[email-masked]> > wrote:

sec 4 does have "The resource server MUST reject any JWT in which the value of "alg" is "none".'

On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki <[email-masked] <mailto:[email-masked]> > wrote:

> asymmetric algorithms is RECOMMENDED

Can this be strengthened to disallow the `none` algorithm? Something like adding "... and MUST NOT use the "none" algorithm".

Given that the JWT BCP doesn't disallow the "none" algorithm, technically someone could follow both this JWT Access Token spec and the JWT BCP spec and end up with an implementation that allows an AS to accept JWTs with the "none" algorithm.

----

Aaron Parecki

aaronparecki.com <http://aaronparecki.com> 

 

On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

Here is the document:

Regards,

 Rifaat & Hannes

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: <[email-masked]>
Date: Mon, 20 Apr 2020 01:10:58 -0700

Thanks guys for the commentary here.

I wasn’t too partial on the “time claim” type. I just went for “Iat” very much in line with Vladimir’s guess, it was quite empirical: 

*	it comes from OIDC, and for the usual consideration that existing logic used for processing ID_tokens will be partially repurposed to implement some of the validation steps
*	“nbf” appeared as the “time claim” only in AzureAD and IS, while “iat” appears in AWS, OKTA, Auth0 and again Azure AD, hence it seemed the common choice

The slightly more philosophical, but still empirical reason is that I haven’t observed scenarios in which the RS defers to the AS the decision about the starting time for the validity of the AT, the semantic of “nbf”, whereas “iat” simply states a fact about the token and it’s up to the RS to decide what to do with it, including applying nbf sematic. That’s a decision that can be easily enshrined as a default in an SDK without loss of expressive power.

I am not married to “iat” and if there’s strong momentum for “nbf” I am open to change it, however we are in a second last call and we just discussed “iat” in the interim meeting last week, hence I thought we had pretty strong consensus on “iat” already. You folks tell me 😊

From: OAuth <[email-masked]> On Behalf Of David Waite
Sent: Sunday, April 19, 2020 10:00 PM
To: Vladimir Dzhuvinov <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]> > wrote:

iat vs nbf

Vladimir

---

From: Dominick Baier <[email-masked]>
Date: Tue, 21 Apr 2020 01:54:26 -0400

In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.

Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?

There’s some language that seems to imply that, e.g.:

as this would allow malicious
   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -

In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.

If this spec is about interop, I think this should be at least a
recommendation...

———
Dominick Baier

On 20. April 2020 at 09:48:51, [email-masked] (
[email-masked]) wrote:

Inline

*>** All other OAuth specs make a very clear distinction between users and
client.*

There’s a nuance worth highlighting here: sub != user. In previous
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that’s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, “In case of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.“ and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.

*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.

*>** I am not fully clear why aud is required.*

   - Many existing specs postulate its existence in the token. No one
   declares it as a proper MUST (apart from the BCP, but that’s partial)
   however I think its importance comes across..
   -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
   mechanism to prevent token redirect (and adds scope restriction as also
   important, however here we make it optional to acocut for non-delegations
   scenario).
   -Resource indicators RFC8707 refers to the same section of RFC7519 as
   one of the assumptions that must hold to prevent bearer tokens misuse
   -BCP225 makes aud mandatory for AS which can issue JWTs for more than
   one app
   - Apart from Ping, for which some of its examples are without aud (but
   also without identifying scopes, given that the one I retrieved had only
   “openid”), all of the sample JWT ATs I received from vendors all featured
   an aud. I know one shoulnd’t overindex on those examples, but together with
   the above it seemed to point to something universally useful. One possible
   reason is that use of a format for the AT is correlated with topologies
   where AS and RS are separated by some boundary (network, logical, business,
   code factoring, etc) hence identifying the resource seems like a natural
   need. Again, not an iron clad law, but an indication.
   - A lot of people repurpose existing libraries for the JWT AT case, and
   some people even sends id_tokens in lieu of ATs. That doesn’t mean that we
   should condone any bad practices, but in tis particular case it suggests
   that lots of developers already expect/can handle an audience in the JWT
   used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
the presence of scopes or other disambiguation. One reason I feel pretty
good about that is that adding a default audience isn’t very hard if any of
the above assumptions end up not being true for a particular case

*> What’s the rationale for using iat instead of nbf. *

That’s just straight from OIDC ID_tokens, and the considerations about
repurposing existing logic. I see there’s a thread on this specifically,
let me answer further on that branch.

*> This spec feels somehow in between a profile and a BCP*

You are right that this spec attempts to go beyond just declaring a layout,
and I agree this means that this profile will not apply to absolutely
everyone. The reason I tried that route (at the cost of working way harder
in the last year for reaching consensus than if we would have just listed
the possible content), is that I often observe implementers make
questionable choices because of the large leeway specifications allow. My
hope was that the scope of this profile was small enough to make that extra
level of guidance achievable, whereas trying to do the same with a larger
spec would have been prohibitively expensive.

I believe things worked out well so far: we had lots of constructive
discussions, and I ended up relaxing A LOT of the constraints I was
originally envisioning. Nonetheless, my hope is that we identified the
right set of guidelines that will help people actually interoperate out of
the box for the most basic/common scenarios, as opposed to complying with
the letter of the spec but still having a lot to figure out out of band.

*From:* OAuth <[email-masked]> *On Behalf Of *Dominick Baier
*Sent:* Thursday, April 16, 2020 12:10 AM
*To:* Rifaat Shekh-Yusef <[email-masked]>; oauth <[email-masked]>
*Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"

*client_id vs sub*

Furthermore it says

   servers.”

*audience claim*

*iat vs nbf*

*General*

cheers

———

Dominick Baier

Hi all,

Here is the document:

Regards,

 Rifaat & Hannes

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 21 Apr 2020 07:43:47 +0000

This is a great point. In my head I just considered the OIDC semantic and thought only of highlighting the app identity case, but you are absolutely right that not mentioning the user case at all is confusing. I added the language you suggested at the beginning of the sub definition.
Thanks!

From: Dominick Baier <[email-masked]>
Date: Monday, April 20, 2020 at 22:54
To: oauth <[email-masked]>, Rifaat Shekh-Yusef <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application.

Maybe I am missing something, but does it say anywhere what to explicitly do in the case of an access token where a resource owner is involved?

In case of access tokens obtained through grants where a resource owner is involved, such as the authorisation code grant, the value of sub SHOULD correspond to the subject identifier of the resource owner.

If this spec is about interop, I think this should be at least a recommendation...

———
Dominick Baier

On 20. April 2020 at 09:48:51, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:
Thanks Dominick for your comments!
Inline

·         Many existing specs postulate its existence in the token. No one declares it as a proper MUST (apart from the BCP, but that’s partial) however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mechanism to prevent token redirect (and adds scope restriction as also important, however here we make it optional to acocut for non-delegations scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one app

·         Apart from Ping, for which some of its examples are without aud (but also without identifying scopes, given that the one I retrieved had only “openid”), all of the sample JWT ATs I received from vendors all featured an aud. I know one shoulnd’t overindex on those examples, but together with the above it seemed to point to something universally useful. One possible reason is that use of a format for the AT is correlated with topologies where AS and RS are separated by some boundary (network, logical, business, code factoring, etc) hence identifying the resource seems like a natural need. Again, not an iron clad law, but an indication.

·         A lot of people repurpose existing libraries for the JWT AT case, and some people even sends id_tokens in lieu of ATs. That doesn’t mean that we should condone any bad practices, but in tis particular case it suggests that lots of developers already expect/can handle an audience in the JWT used to call their API
None of those are a slam dunk argument for mandatory, but I find them compelling enough to simplify validation and just require an aud to be there, as opposed to introduce complications that make it conditional to the presence of scopes or other disambiguation. One reason I feel pretty good about that is that adding a default audience isn’t very hard if any of the above assumptions end up not being true for a particular case

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Dominick Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>; oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

client_id vs sub

Furthermore it says

audience claim

iat vs nbf

General

cheers
———
Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef ([email-masked]<mailto:[email-masked]>) wrote:
Hi all,

Here is the document:

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dominick Baier <[email-masked]>
Date: Tue, 21 Apr 2020 13:23:55 -0400

Oh and while we are at it - could you also fix the typo in my name? Thanks
;)

———
Dominick Baier

On 21. April 2020 at 09:43:49, Vittorio Bertocci (
[email-masked]) wrote:

This is a great point. In my head I just considered the OIDC semantic and
thought only of highlighting the app identity case, but you are absolutely
right that not mentioning the user case at all is confusing. I added the
language you suggested at the beginning of the sub definition.

Thanks!

*From: *Dominick Baier <[email-masked]>
*Date: *Monday, April 20, 2020 at 22:54
*To: *oauth <[email-masked]>, Rifaat Shekh-Yusef <[email-masked]>, "
[email-masked]" <[email-masked]>
*Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"

———

Dominick Baier

Inline

·         Many existing specs postulate its existence in the token. No one
declares it as a proper MUST (apart from the BCP, but that’s partial)
however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the
mechanism to prevent token redirect (and adds scope restriction as also
important, however here we make it optional to acocut for non-delegations
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one
of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one
app

·         Apart from Ping, for which some of its examples are without aud
(but also without identifying scopes, given that the one I retrieved had
only “openid”), all of the sample JWT ATs I received from vendors all
featured an aud. I know one shoulnd’t overindex on those examples, but
together with the above it seemed to point to something universally useful.
One possible reason is that use of a format for the AT is correlated with
topologies where AS and RS are separated by some boundary (network,
logical, business, code factoring, etc) hence identifying the resource
seems like a natural need. Again, not an iron clad law, but an indication.

·         A lot of people repurpose existing libraries for the JWT AT case,
and some people even sends id_tokens in lieu of ATs. That doesn’t mean that
we should condone any bad practices, but in tis particular case it suggests
that lots of developers already expect/can handle an audience in the JWT
used to call their API

*client_id vs sub*

Furthermore it says

   servers.”

*audience claim*

*iat vs nbf*

*General*

cheers

———

Dominick Baier

Hi all,

Here is the document:

Regards,

 Rifaat & Hannes

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 21 Apr 2020 19:19:01 +0000

Ouch! Sorry 😊 fixed

From: Dominick Baier <[email-masked]>
Date: Tuesday, April 21, 2020 at 10:23
To: oauth <[email-masked]>, Rifaat Shekh-Yusef <[email-masked]>, Vittorio Bertocci <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Oh and while we are at it - could you also fix the typo in my name? Thanks ;)

———
Dominick Baier

On 21. April 2020 at 09:43:49, Vittorio Bertocci ([email-masked]<mailto:[email-masked]>) wrote:
This is a great point. In my head I just considered the OIDC semantic and thought only of highlighting the app identity case, but you are absolutely right that not mentioning the user case at all is confusing. I added the language you suggested at the beginning of the sub definition.
Thanks!

From: Dominick Baier <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 20, 2020 at 22:54
To: oauth <[email-masked]<mailto:[email-masked]>>, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

———
Dominick Baier

•         Many existing specs postulate its existence in the token. No one declares it as a proper MUST (apart from the BCP, but that’s partial) however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mechanism to prevent token redirect (and adds scope restriction as also important, however here we make it optional to acocut for non-delegations scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one app

•         Apart from Ping, for which some of its examples are without aud (but also without identifying scopes, given that the one I retrieved had only “openid”), all of the sample JWT ATs I received from vendors all featured an aud. I know one shoulnd’t overindex on those examples, but together with the above it seemed to point to something universally useful. One possible reason is that use of a format for the AT is correlated with topologies where AS and RS are separated by some boundary (network, logical, business, code factoring, etc) hence identifying the resource seems like a natural need. Again, not an iron clad law, but an indication.

•         A lot of people repurpose existing libraries for the JWT AT case, and some people even sends id_tokens in lieu of ATs. That doesn’t mean that we should condone any bad practices, but in tis particular case it suggests that lots of developers already expect/can handle an audience in the JWT used to call their API
None of those are a slam dunk argument for mandatory, but I find them compelling enough to simplify validation and just require an aud to be there, as opposed to introduce complications that make it conditional to the presence of scopes or other disambiguation. One reason I feel pretty good about that is that adding a default audience isn’t very hard if any of the above assumptions end up not being true for a particular case

client_id vs sub

Furthermore it says

audience claim

iat vs nbf

General

cheers
———
Dominick Baier

Here is the document:

Regards,
 Rifaat & Hannes

---

From: Takahiko Kawasaki <[email-masked]>
Date: Fri, 24 Apr 2020 02:15:06 +0900

First, to make the discussion fair, I think I should share what I observed
today. Auth0's client_credentials flow requires an "audience" parameter,
which is equivalent to the "resource" parameter defined in RFC 8707, and
embeds the client ID in the generated JWT access token as the value of the
"sub" claim.

My opinion as a software engineer is as follows.

[aud]
The "aud" claim should be null or absent when the "resource" parameters are
not given in an authorization request. It is not good to introduce
inflexible rules to determine the default value for the "aud" claim based
on the "scope" parameter.

[sub]
The "sub" claim should be null or absent when a resource owner is not
involved in an authorization request. To be concrete, the "sub" claim
should be null or absent in the client credentials flow. The spec draft
says in "5. Security Considerations" as follows.

- - - - - - - - - -
Authorization servers should prevent scenarios where clients can affect the
value of the sub claim in ways that could confuse resource servers.  For
example: if the authorization server elects to use the client_id as the sub
value for access tokens issued client credentials grant, the authorization
server should prevent clients to register an arbitrary client_id value, as
this would allow malicious clients to select the sub of a high privilege
resource owner and confuse any authorization logic on the resource server
relying on the sub value.  For more details please refer to section 4.13 of
[OAuth2.Security.BestPractices].

To preventing cross-JWT confusion, authorization servers MUST use a
distinct identifier as "aud" claim value to uniquely identify access tokens
issued by the same issuer for distinct resources.
- - - - - - - - - -

However, the attack vector is brought about merely by introducing the
following rule defined in "2.2. Data Structure".

- - - - - - - - - -
In case of access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub SHOULD
correspond to an identifier the authorization server uses to indicate the
client application.
- - - - - - - - - -

If the rule is not introduced, the attack vector disappears and the "aud"
claim doesn't have to be mandatory.

Finally, to make the discussion fair, I should also mention that I myself
is a co-founder of Authlete, Inc. that provides an implementation of OAuth
and OpenID Connect. My thoughts about implementations of access tokens are
publicly described here:

OAuth Access Token Implementation
https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci <vittorio.bertocci=
[email-masked]> wrote:

> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth <[email-masked]>, Rifaat Shekh-Yusef <[email-masked]>,
> Vittorio Bertocci <[email-masked]>
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> *To: *oauth <[email-masked]>, Rifaat Shekh-Yusef <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> *>** All other OAuth specs make a very clear distinction between users
> and client.*
>
> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
> OIDC, to preempt that concern and keep the original sub semantic available.
>
>
>
> ·         Many existing specs postulate its existence in the token. No
> one declares it as a proper MUST (apart from the BCP, but that’s partial)
> ·         A lot of people repurpose existing libraries for the JWT AT
> case, and some people even sends id_tokens in lieu of ATs. That doesn’t
> mean that we should condone any bad practices, but in tis particular case
> it suggests that lots of developers already expect/can handle an audience
> in the JWT used to call their API
>
> You are right that this spec attempts to go beyond just declaring a
> layout, and I agree this means that this profile will not apply to
> absolutely everyone. The reason I tried that route (at the cost of working
> way harder in the last year for reaching consensus than if we would have
> just listed the possible content), is that I often observe implementers
> make questionable choices because of the large leeway specifications allow.
> My hope was that the scope of this profile was small enough to make that
> extra level of guidance achievable, whereas trying to do the same with a
> larger spec would have been prohibitively expensive.
>
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> If the concept of resources are used, I absolutely agree that aud should
> be used too. But I wouldn’t make it required.
>
>
>
> *iat vs nbf*
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Fri, 24 Apr 2020 10:01:18 +0900

I apologize if my previous post has made you all here feel unpleasant,
especially I'm sorry for the author, the chairs, and people who directly
joined the discussion about the spec. I could have expressed my
disagreement on the requirements for "aud" and "sub" in another different
way. For software specifications and architectures, I'm liable to get
excited and aggressive. Please forgive me.

Regarding the relationship between "aud" and "scope", the assumption in the
draft is not necessarily applicable to all possible use cases. For example,
multiple resources may share the same scopes. What if both "/resource1" and
"/resource2" recognize "get" scope and "update" scope? In this case, it is
not appropriate to determine the default resource indicator for "aud" from
the scopes. It is also impossible to map scopes to resources and vice
versa. The assumption in the current draft is too narrow to be included in
a standard. If the current description continues to exist, it will impose
big restrictions on the design of scopes and resources.

If you still think the "aud" claim should always exist, then the
authorization endpoint and/or the token endpoint (and/or the backchannel
authentication endpoint and/or the device authorization endpoint) of your
system can require the "resource" request parameter as mandatory. We don't
have to put rules to determine the default "aud" value into the spec about
JWT access tokens. The "resource" parameter defined in RFC 8707 can work
regardless of whether the format of access tokens is JWT or not. Therefore,
it is not appropriate to discuss the necessity of the "aud" claim only in
the context of "JWT" access tokens.

Regarding the "sub" claim, setting the client ID there, rather, will
confuse resource servers. If the "sub" claim is set even in the case of the
client credentials flow, resource servers cannot judge whether the "sub"
claim represents either the subject of the resource owner or the client ID.
On the other hand, if the "sub" claim is null or absent in the case of the
client credentials flow, resource servers can always handle the value of
the "sub" claim as the subject of the resource owner. For resource servers,
this logic is easier. Setting the "sub" claim in every case to make
resource server implementations simpler is not convincing.

Best Regards,
Taka

On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki <[email-masked]> wrote:

> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> Authorization servers should prevent scenarios where clients can affect
> the value of the sub claim in ways that could confuse resource servers.
> For example: if the authorization server elects to use the client_id as the
> sub value for access tokens issued client credentials grant, the
> authorization server should prevent clients to register an arbitrary
> client_id value, as this would allow malicious clients to select the sub of
> a high privilege resource owner and confuse any authorization logic on the
> resource server relying on the sub value.  For more details please refer to
> section 4.13 of [OAuth2.Security.BestPractices].
>
> In case of access tokens obtained through grants where no resource owner
> is involved, such as the client credentials grant, the value of sub SHOULD
>> ·         Apart from Ping, for which some of its examples are without
>> aud (but also without identifying scopes, given that the one I retrieved
>> had only “openid”), all of the sample JWT ATs I received from vendors all
>> this thinking reminds me of the old AD days where there was no
>> distinction between user and service accounts (something that has been
>> fixed IIRC in Windows Server 2012 R2).
>>
>>
>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 24 Apr 2020 20:24:04 +0000

Takahiro,
Before I acknowledge your comments, I would like to clarify some important points.
Your first email, and various tweets you published contextually (https://twitter.com/darutk/status/1253375039681884160), suggest that with my work on the spec I am driving some hidden agenda for my company, and you are exposing this thanks to some findings you uncovered- and that the WG somehow missed.
This is of course nonsense, insulting to my own professional integrity and to the intelligence of the chairs, working group and everyone who participated in the discussion. I include the tweets in the discussion because you included in them a link to the mailing list archives, hence involving the WG in the process.

Some basic facts:

  *   The profile as it exists today does NOT work out of the box with Auth0, there are several things that would need to change in the product for that to happen- including adding support for resource indicators which is currently missing
  *   The layout of the Auth0 token is certainly not a secret, given that it was presented alongside all the other tokens obtained from other vendors at the OSW2019 in March, in the initial draft pitch at IETF104 as recorded in https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00, in the first discussion at IETF105 as shown in https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02-00. The use of resource indicators for client cred flows is certainly not a dark ploy to smuggle the Auth0 way, in fact it’s informed more by my work on Azure AD- where I found the transition from pseudo resource indicators to scopes to be riddled by challenges. Once again, all discussions were made in full transparency.
  *   The concerns about symmetric algorithms being allowed, which you are oddly bringing up in a tweet rather than on the list, are disconnected from the discussion: people in the working group explicitly asked for symmetric to be an option and even to relax the current language to be more permissive, which I gently pushed back against. Again, not an obscure ploy.

I am saddened that you chose to make those statements on twitter. There was nothing for you to discover, everything was already out in the open.
You might want to consider retracting your accusations. I am not worried about myself, my conscience is perfectly clean and the IETF process records back me up, but by suggesting lack of transparency you are unfairly portraying the IETF, standardization process and the people who do their best to check at the door their affiliations and contribute their time and expertise for the benefit of the industry as a whole.

I am adding the tweets here for reference, together with the translation Twitter provided.

Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect
@darutk
もしやと思って調べてみたら、Auth0（スペックリードの所属企業）の client_credentials フローの実装は audience（RFC 8707 の resource 相当）が必須で、生成する JWT アクセストークンの sub にクライアント ID を埋め込む。JWT アクセストークン仕様ドラフトが歪んでいるのはこれが理由だろう。
Suddenly, I searched and thought, implementation of client_credentials flow of Auth0 (company of Spec Lead) requires audience (equivalent to resource of RFC 8707), and embed client ID in sub of generated JWT access token. This is probably the reason why the JWT access token specification draft is distorted.

元々 Auth0 の現実装を業界に認めさせるために JWT アクセストークン標準仕様策定作業が開始されたと噂では聞いていたが、実際にそうだったか。技術的に不自然な点が多いし裏事情がはっきりした今となっては黙っている訳にもいかないので、メーリングリストで意見を述べた。

https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/
I've heard rumors that the JWT Access Token standard specification work was started to get the industry to accept the current implementation of Auth0, but was that really the case? Since there are many technical unnatural points and it is impossible to keep silent now that the circumstances are clear, I made an opinion on the mailing list.

ついでに言っておくと、Auth0 が生成する JWT アクセストークンの署名アルゴリズムとして選択できるのは、HS256 と RS256 のみのようだ。HS256 は対称鍵系アルゴリズム。一方の RS256 は非対称鍵系アルゴリズムだが、セキュリティー上の理由で Financial-grade API Part 2 では使用禁止とされている。
Incidentally, it seems that only HS256 and RS256 can be selected as the signature algorithm for the JWT access token generated by Auth0. HS256 is a symmetric key algorithm. On the other hand, RS256 is an asymmetric key algorithm, but for security reasons, it is prohibited in Financial-grade API Part 2.

From: OAuth <[email-masked]> on behalf of Takahiko Kawasaki <[email-masked]>
Date: Thursday, April 23, 2020 at 18:01
To: oauth <[email-masked]>
Cc: Vittorio Bertocci <vittorio.bertocci=[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I apologize if my previous post has made you all here feel unpleasant, especially I'm sorry for the author, the chairs, and people who directly joined the discussion about the spec. I could have expressed my disagreement on the requirements for "aud" and "sub" in another different way. For software specifications and architectures, I'm liable to get excited and aggressive. Please forgive me.

Regarding the relationship between "aud" and "scope", the assumption in the draft is not necessarily applicable to all possible use cases. For example, multiple resources may share the same scopes. What if both "/resource1" and "/resource2" recognize "get" scope and "update" scope? In this case, it is not appropriate to determine the default resource indicator for "aud" from the scopes. It is also impossible to map scopes to resources and vice versa. The assumption in the current draft is too narrow to be included in a standard.. If the current description continues to exist, it will impose big restrictions on the design of scopes and resources.

If you still think the "aud" claim should always exist, then the authorization endpoint and/or the token endpoint (and/or the backchannel authentication endpoint and/or the device authorization endpoint) of your system can require the "resource" request parameter as mandatory. We don't have to put rules to determine the default "aud" value into the spec about JWT access tokens. The "resource" parameter defined in RFC 8707 can work regardless of whether the format of access tokens is JWT or not. Therefore, it is not appropriate to discuss the necessity of the "aud" claim only in the context of "JWT" access tokens.

Regarding the "sub" claim, setting the client ID there, rather, will confuse resource servers. If the "sub" claim is set even in the case of the client credentials flow, resource servers cannot judge whether the "sub" claim represents either the subject of the resource owner or the client ID. On the other hand, if the "sub" claim is null or absent in the case of the client credentials flow, resource servers can always handle the value of the "sub" claim as the subject of the resource owner. For resource servers, this logic is easier. Setting the "sub" claim in every case to make resource server implementations simpler is not convincing.

Best Regards,
Taka

On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>> wrote:
First, to make the discussion fair, I think I should share what I observed today. Auth0's client_credentials flow requires an "audience" parameter, which is equivalent to the "resource" parameter defined in RFC 8707, and embeds the client ID in the generated JWT access token as the value of the "sub" claim.

[aud]
The "aud" claim should be null or absent when the "resource" parameters are not given in an authorization request. It is not good to introduce inflexible rules to determine the default value for the "aud" claim based on the "scope" parameter.

[sub]
The "sub" claim should be null or absent when a resource owner is not involved in an authorization request. To be concrete, the "sub" claim should be null or absent in the client credentials flow. The spec draft says in "5. Security Considerations" as follows.

- - - - - - - - - -
Authorization servers should prevent scenarios where clients can affect the value of the sub claim in ways that could confuse resource servers.  For example: if the authorization server elects to use the client_id as the sub value for access tokens issued client credentials grant, the authorization server should prevent clients to register an arbitrary client_id value, as this would allow malicious clients to select the sub of a high privilege resource owner and confuse any authorization logic on the resource server relying on the sub value.  For more details please refer to section 4.13 of [OAuth2.Security.BestPractices].

To preventing cross-JWT confusion, authorization servers MUST use a distinct identifier as "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources.
- - - - - - - - - -

However, the attack vector is brought about merely by introducing the following rule defined in "2.2. Data Structure".

- - - - - - - - - -

If the rule is not introduced, the attack vector disappears and the "aud" claim doesn't have to be mandatory.

Finally, to make the discussion fair, I should also mention that I myself is a co-founder of Authlete, Inc. that provides an implementation of OAuth and OpenID Connect. My thoughts about implementations of access tokens are publicly described here:

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci <vittorio.bertocci=[email-masked]<mailto:[email-masked]>> wrote:
Ouch! Sorry 😊 fixed

From: Dominick Baier <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 21, 2020 at 10:23
To: oauth <[email-masked]<mailto:[email-masked]>>, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>, Vittorio Bertocci <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

———
Dominick Baier

———
Dominick Baier

On 20. April 2020 at 09:48:51, [email-masked]<mailto:vittorio.bertocci@auth0..com> ([email-masked]<mailto:[email-masked]>) wrote:
Thanks Dominick for your comments!
Inline

•         A lot of people repurpose existing libraries for the JWT AT case, and some people even sends id_tokens in lieu of ATs. That doesn’t mean that we should condone any bad practices, but in tis particular case it suggests that lots of developers already expect/can handle an audience in the JWT used to call their API
None of those are a slam dunk argument for mandatory, but I find them compelling enough to simplify validation and just require an aud to be there, as opposed to introduce complications that make it conditional to the presence of scopes or other disambiguation.. One reason I feel pretty good about that is that adding a default audience isn’t very hard if any of the above assumptions end up not being true for a particular case

client_id vs sub

Furthermore it says

audience claim

iat vs nbf

General

cheers
———
Dominick Baier

Here is the document:

Regards,
 Rifaat & Hannes

---

From: Takahiko Kawasaki <[email-masked]>
Date: Sat, 25 Apr 2020 07:49:09 +0900

Dear Vittorio,

I apologize. To me, the requirements on "aud" and "sub" sounded too strange
and the logic to deny counter proposals sounded unnaturally unconvincing,
too. They made me suspicious, and unfortunately and accidentally, my
subsequent observation matched my doubt, and it made me feel I should bring
it here with a kind of sense of justice, but I was a way too stupid. I
wanted to discuss the requirements purely technically by removing politics,
which I thought existed but did not exist actually. The ironic result was
that my previous post itself was politics. I stop making comments to the
spec.

I'm sorry for my tweets. Because they have been copied to here in an
unremovable way, allow me to remove them from Twitter to reflect my conduct.

I'm sorry for having cast doubt although I've actually respected you since
long before without your knowing. Hopefully, I want mercy from you and the
community in spite of my conduct.

Takahiko

On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci <
[email-masked]> wrote:

> Your first email, and various tweets you published contextually (
> https://twitter.com/darutk/status/1253375039681884160), suggest that with
> my work on the spec I am driving some hidden agenda for my company, and you
> are exposing this thanks to some findings you uncovered- and that the WG
> somehow missed.
> This is of course nonsense, insulting to my own professional integrity and
> to the intelligence of the chairs, working group and everyone who
> participated in the discussion. I include the tweets in the discussion
> because you included in them a link to the mailing list archives, hence
> involving the WG in the process.
>
>
>
> Some basic facts:
>
>    - The profile as it exists today does NOT work out of the box with
>    Auth0, there are several things that would need to change in the product
>    for that to happen- including adding support for resource indicators which
>    is currently missing
>    - The layout of the Auth0 token is certainly not a secret, given that
>    it was presented alongside all the other tokens obtained from other vendors
>    at the OSW2019 in March, in the initial draft pitch at IETF104 as recorded
>    in
>    https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00,
>    in the first discussion at IETF105 as shown in
>    https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02-00.
>    The use of resource indicators for client cred flows is certainly not a
>    dark ploy to smuggle the Auth0 way, in fact it’s informed more by my work
>    on Azure AD- where I found the transition from pseudo resource indicators
>    to scopes to be riddled by challenges. Once again, all discussions were
>    made in full transparency.
>    - The concerns about symmetric algorithms being allowed, which you are
>    oddly bringing up in a tweet rather than on the list, are disconnected from
>    the discussion: people in the working group explicitly asked for symmetric
>    to be an option and even to relax the current language to be more
>    permissive, which I gently pushed back against. Again, not an obscure ploy.
>
>
>
> I am saddened that you chose to make those statements on twitter. There
> was nothing for you to discover, everything was already out in the open.
>
> You might want to consider retracting your accusations. I am not worried
> about myself, my conscience is perfectly clean and the IETF process records
> back me up, but by suggesting lack of transparency you are unfairly
> portraying the IETF, standardization process and the people who do their
> best to check at the door their affiliations and contribute their time and
> expertise for the benefit of the industry as a whole.
>
>
>
> もしやと思って調べてみたら、Auth0（スペックリードの所属企業）の client_credentials フローの実装は audience（RFC
> 8707 の resource 相当）が必須で、生成する JWT アクセストークンの sub にクライアント ID を埋め込む。JWT
> アクセストークン仕様ドラフトが歪んでいるのはこれが理由だろう。
>
> Suddenly, I searched and thought, implementation of client_credentials
> flow of Auth0 (company of Spec Lead) requires audience (equivalent to
> resource of RFC 8707), and embed client ID in sub of generated JWT access
> token. This is probably the reason why the JWT access token specification
> draft is distorted.
>
>
>
> 元々 Auth0 の現実装を業界に認めさせるために JWT
> アクセストークン標準仕様策定作業が開始されたと噂では聞いていたが、実際にそうだったか。技術的に不自然な点が多いし裏事情がはっきりした今となっては黙っている訳にもいかないので、メーリングリストで意見を述べた。
>
>
>
> I've heard rumors that the JWT Access Token standard specification work
> was started to get the industry to accept the current implementation of
> Auth0, but was that really the case? Since there are many technical
> unnatural points and it is impossible to keep silent now that the
> circumstances are clear, I made an opinion on the mailing list.
>
>
>
> ついでに言っておくと、Auth0 が生成する JWT アクセストークンの署名アルゴリズムとして選択できるのは、HS256 と RS256
> のみのようだ。HS256 は対称鍵系アルゴリズム。一方の RS256 は非対称鍵系アルゴリズムだが、セキュリティー上の理由で
> Financial-grade API Part 2 では使用禁止とされている。
>
> Incidentally, it seems that only HS256 and RS256 can be selected as the
> signature algorithm for the JWT access token generated by Auth0. HS256 is a
> symmetric key algorithm. On the other hand, RS256 is an asymmetric key
> algorithm, but for security reasons, it is prohibited in Financial-grade
> API Part 2.
>
>
>
>
>
> *From: *OAuth <[email-masked]> on behalf of Takahiko Kawasaki <
> [email-masked]>
> *Date: *Thursday, April 23, 2020 at 18:01
> *To: *oauth <[email-masked]>
> *Cc: *Vittorio Bertocci <vittorio.bertocci=[email-masked]>
> Regarding the relationship between "aud" and "scope", the assumption in
> the draft is not necessarily applicable to all possible use cases. For
> example, multiple resources may share the same scopes. What if both
> "/resource1" and "/resource2" recognize "get" scope and "update" scope? In
> this case, it is not appropriate to determine the default resource
> indicator for "aud" from the scopes. It is also impossible to map scopes to
> resources and vice versa. The assumption in the current draft is too narrow
> to be included in a standard.. If the current description continues to
> exist, it will impose big restrictions on the design of scopes and
> resources.
>
> On 20. April 2020 at 09:48:51, [email-masked]
> <vittorio.bertocci@auth0..com> ([email-masked]) wrote:
>
> the presence of scopes or other disambiguation.. One reason I feel pretty

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 24 Apr 2020 23:14:27 +0000

Dear Takahiko,
Thank you so much for your kind and prompt response, and for having deleted the tweets. We all care a lot about doing the right thing, and I fully understand how passion can sometimes carry us away. For me this resolves the matter 100%.
Thanks again,
V.

From: Takahiko Kawasaki <[email-masked]>
Date: Friday, April 24, 2020 at 15:49
To: Vittorio Bertocci <[email-masked]>
Cc: oauth <[email-masked]>, Vittorio Bertocci <vittorio.bertocci=[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Dear Vittorio,

I apologize. To me, the requirements on "aud" and "sub" sounded too strange and the logic to deny counter proposals sounded unnaturally unconvincing, too. They made me suspicious, and unfortunately and accidentally, my subsequent observation matched my doubt, and it made me feel I should bring it here with a kind of sense of justice, but I was a way too stupid. I wanted to discuss the requirements purely technically by removing politics, which I thought existed but did not exist actually. The ironic result was that my previous post itself was politics. I stop making comments to the spec.

I'm sorry for my tweets. Because they have been copied to here in an unremovable way, allow me to remove them from Twitter to reflect my conduct.

I'm sorry for having cast doubt although I've actually respected you since long before without your knowing. Hopefully, I want mercy from you and the community in spite of my conduct.

Takahiko

On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> wrote:
Takahiro,
Before I acknowledge your comments, I would like to clarify some important points.
Your first email, and various tweets you published contextually (https://twitter.com/darutk/status/1253375039681884160), suggest that with my work on the spec I am driving some hidden agenda for my company, and you are exposing this thanks to some findings you uncovered- and that the WG somehow missed.
This is of course nonsense, insulting to my own professional integrity and to the intelligence of the chairs, working group and everyone who participated in the discussion. I include the tweets in the discussion because you included in them a link to the mailing list archives, hence involving the WG in the process.

Some basic facts:

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 23, 2020 at 18:01
To: oauth <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <vittorio.bertocci=[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Best Regards,
Taka

[aud]

[sub]

- - - - - - - - - -

- - - - - - - - - -

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

———
Dominick Baier

———
Dominick Baier

client_id vs sub

Furthermore it says

audience claim

iat vs nbf

General

cheers
———
Dominick Baier

Here is the document:

Regards,
 Rifaat & Hannes

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 24 Apr 2020 19:34:39 -0400

Vittorio, Takahiko,

Thank you both for your handling of the situation and the quick resolution
of this issue.

Have a great weekend and stay safe!

Regards,
 Rifaat

On Friday, April 24, 2020, Vittorio Bertocci <vittorio.bertocci=
[email-masked]> wrote:

> Dear Takahiko,
>
> Thank you so much for your kind and prompt response, and for having
> deleted the tweets. We all care a lot about doing the right thing, and I
> fully understand how passion can sometimes carry us away. For me this
> resolves the matter 100%.
>
> Thanks again,
>
> V.
>
>
>
> *From: *Takahiko Kawasaki <[email-masked]>
> *Date: *Friday, April 24, 2020 at 15:49
> *To: *Vittorio Bertocci <[email-masked]>
> *Cc: *oauth <[email-masked]>, Vittorio Bertocci <vittorio.bertocci=
> [email-masked]>
> I apologize. To me, the requirements on "aud" and "sub" sounded too
> strange and the logic to deny counter proposals sounded unnaturally
> unconvincing, too. They made me suspicious, and unfortunately and
> accidentally, my subsequent observation matched my doubt, and it made me
> feel I should bring it here with a kind of sense of justice, but I was a
> way too stupid. I wanted to discuss the requirements purely technically by
> removing politics, which I thought existed but did not exist actually. The
> ironic result was that my previous post itself was politics. I stop making
> comments to the spec.
>
>    in https://datatracker.ietf.org/meeting/104/materials/slides-
>    104-oauth-sessa-jwt-profile-for-access-token-00
>    <https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00>,
>    https://datatracker.ietf.org/meeting/105/materials/slides-
>    105-oauth-sessa-json-web-token-jwt-profile-for-oauth-
>    20-access-tokens-02-00
>    <https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02-00>.
> 元々 Auth0 の現実装を業界に認めさせるために JWT アクセストークン標準仕様策定作業が開始されたと噂では聞いていたが、実際にそうだったか。
> 技術的に不自然な点が多いし裏事情がはっきりした今となっては黙っている訳にもいかないので、メーリングリストで意見を述べた。
>
>
>

---

From: Denis <[email-masked]>
Date: Wed, 29 Apr 2020 18:10:25 +0200

You will find four comments numbered 1) to 4).

*1) *The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. *However, the 
header at the top of the page omits to mention it.

Currently, it is :

Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft       OAuth *2.0* Access Token JWT Profile           
April 2020

*2)* The following text is within section 6.

The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens) hence any logic in the
client relying on the ability to read the access token content would
break without recourse.
Nonetheless, authorization servers should
not assume that clients will comply with the above.

It is of a primary importance that clients MAY be able to inspect tokens 
before transmitting them.
The "MUST NOT" is not acceptable.

The above text should be replaced with:

Reading the access token content may be useful for the user to verify that
the access token content matches with its expectations.However,
the authorization server and the resource server might decide to change the
token format at any time.Thus, the client should not expect to always be
in a position to read the access token content.

The remaining of the text about this topic is fine.

*3) *The next topic is about the sub claim.

The text states:

Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

 1. How can authorization servers choose how to assign sub values
    according to the level of privacy required "by each situation" ?
 2. How can authorization servers know the level of privacy required "by
    each situation" ?
 3. How can the users be informed of the level of privacy required "by
    each situation" ?
 4. How can the users *consent* with the level of privacy required "by
    each situation" ?

Currently, the request MUST include either a resource parameter or an 
aud claim parameter, while it MAY include a scope parameter.

The syntax of the scope parameter is a list of space-delimited, 
case-sensitive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being 
returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub 
claim to contain :

  * a global unique identifier for all ASs ("globally unique"),
  * a unique identifier for each AS ("locally unique in the context of
    the issuer"),
  * a different pseudonym for each RS, or
  * a different pseudonym for each authorization token request.

The only variable parameter that it can use for this purpose in the 
token request is the scope parameter.

RFC 7519 states is section 4.1.2:

The subject value MUST either be scoped to be locally unique in the 
context of the issuer
or be globally unique.

It is quite hard to recognize that the sub claim is able to carry a 
different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for 
case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

For instance: if a solution requires preventing tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens meant for
different resource servers have distinct sub values that cannot be
correlated in the event of resource servers collusion.

Since it addresses case (c).

and also about the following text:

4.b) Similarly: if a solution requires preventing a resource server from
correlating the principal’s activity within the resource itself, the
authorization server should assign different sub values for every JWT
access token issued.

Since it addresses case (d).

This means that the current text placed in the privacy considerations 
section was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows to 
correlate principal activities across multiple resource servers, while 
in addition,
this globally unique identifier may also allow to correlate the 
principal activities on servers where no access has been performed by 
the principals
to these servers but where the same globally unique identifiers are 
being used by these servers.

When the sub claim contains a locally unique identifier in the context 
of the issuer, this also allows the tracking of principal activities 
across multiple resource servers.

The scope request parameter is the only way to influence on the content 
of the sub claim parameter. Its meaning is subject to a private agreement
between the client and the AS, which means that the use of the scope 
parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary importance 
that the returned scope matches with the expectations of the client 
before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able to 
choose whether it wishes the sub claim to contain :
- a different pseudonym for each RS so that different resource servers 
will be unable to correlate its activities, or
- a different pseudonym for each authorization token request, so that 
the same resource server cannot correlate its activities performed at 
different instant of time.

Considering the semantics of the sub claim, these two cases cannot be 
currently supported.

*4) *The next topic is about the targeting of access tokens

Text had been proposed before the last conference call. Then, the topic 
has been presented at the very end of the last conference call, but no 
text has been included
in the next draft.

Here is a revised text be included in the privacy considerations section:

For security reasons, some clients may be willing to target their access 
tokens but, for privacy reasons, may be unwilling to disclose to 
Authorization Servers
an identification of the Resource Servers they are going to access, so 
that Authorization Servers will be unable to know which resources 
servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization 
Servers to list all the Resource Servers being access by all its users 
and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users 
accesses to Resource Servers performed through a given Authorization 
Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 29 Apr 2020 17:57:26 +0000

Thanks Denis for the thorough commentary.

> The title of this spec.
Fixed, thanks!

> The client MUST NOT inspect the content of the access token
This is really a sticky point. I really want to acknowledge your PoV on this, but at the same time I found this to be one of the biggest sources of issues in the use of JWT for access tokens hence I feel we really need to give solid guidance here. Let me expand further on the reasoning behind it, and perhaps we can get to language that satisfies both PoVs.
To me the key point is that clients should not write code that inspects access tokens. Taking a dependency on the ability to do so is ignoring fundamental information about the architecture and relationships between OAuth roles, and suggests an ability of the client to understand the semantic of the content that cannot be assumed in the general case. I expanded on the details in my former reply to you on this topic, I would recommend referring to it. Clients violating this simple principle has been one of the most common sources of production issues I had to deal with in the past few years, and one of the hardest to remediate given that clients are hard to update and sometimes the things they relied on were irremediably lost. This is why I am inclined to put in here strong language.
That said: I have nothing against client developers examining a network trace and drawing conclusions based on the content of what they see. That doesn’t create any hard dependencies and has no implications in respect to changes in the solution behavior. However I am not sure how to phrase that in the specification, given that referring to the client inevitably refers to its code. I am open to suggestions.

>  3)…
I have a pretty hard time following the chain of reasoning in this section. Let me attempt to tackle it to the best of my understanding.
I think the key might be
> a client should be able to choose whether it wishes the sub claim to contain [..]
I don’t think that should be a choice left to the client. In business systems, my experience is that the type of identifiers to be used (when the IdP gives any choice at all)  is established at resource provisioning time. I am not aware of mechanisms thru which a client signals the nature of the identifier to be used, nor that would be fully feasible (the resource knows what it needs to perform its function).
Furthermore:
> which has nothing to do with uniqueness since the value changes for every generated token.
Again, this is something that was touched on in my former reply to your message. As long as an identifier identifies one resource only, it satisfies uniqueness. It doesn’t have to be a singleton.
Finally, the scope is optional (for good reasons: 1st party and non delegation scenarios don’t require it) hence it cannot be relied upon for properties that should hold in every scenario.
In summary: per the preceding thread on this topic, the consensus was that varying the sub content was a satisfactory way of protecting against correlation. I don’t a gree that clients should have a mechanism to request different sub flavors, as that decision should be done out of band by the AS and RS; and the scope isn’t always available anyway.
> targeting of access tokens
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the effect of letting the AS track when the client accesses a particular resource, but at the same time that’s completely mainstream and very much by design in a very large number of cases. As such, I find the language you are suggesting to be potentially confusing, as it positions this as an exception vs a privacy protecting mainstream that is in fact not common, and ascribes to the client more latitude than I believe is legitimate to expect or grant.
I’ll try to come up with concise language that clarifies to the reader that the current mechanism does allow AS tracking.

From: OAuth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Wednesday, April 29, 2020 at 09:12
To: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

You will find four comments numbered 1) to 4).
1) The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

So, this spec. is supposed to be targeted to OAuth 2.0.  However, the header at the top of the page omits to mention it.

Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           April 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           April 2020

2) The following text is within section 6.

It is of a primary importance that clients MAY be able to inspect tokens before transmitting them.

Reading the access token content may be useful for the user to verify that
the access token content matches with its expectations.  However,
the authorization server and the resource server might decide to change the
token format at any time.  Thus, the client should not expect to always be
in a position to read the access token content.

3) The next topic is about the sub claim.

The text states:

  1.  How can authorization servers choose how to assign sub values according to the level of privacy required "by each situation" ?
  2.  How can authorization servers know the level of privacy required "by each situation" ?
  3.  How can the users be informed of the level of privacy required "by each situation" ?
  4.  How can the users consent with the level of privacy required "by each situation" ?
Currently, the request MUST include either a resource parameter or an aud claim parameter, while it MAY include a scope parameter.
The syntax of the scope parameter is a list of space-delimited, case-sensitive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub claim to contain :

  *   a global unique identifier for all ASs ("globally unique"),
  *   a unique identifier for each AS ("locally unique in the context of the issuer"),
  *   a different pseudonym for each RS, or
  *   a different pseudonym for each authorization token request.
The only variable parameter that it can use for this purpose in the token request is the scope parameter.

The subject value MUST either be scoped to be locally unique in the context of the issuer
or be globally unique.

It is quite hard to recognize that the sub claim is able to carry a different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This means that the current text placed in the privacy considerations section was a good attempt to address the case,
but that the text needs to be revised.

According to RFC 7519 (4.1.2): The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows to correlate principal activities across multiple resource servers, while in addition,
this globally unique identifier may also allow to correlate the principal activities on servers where no access has been performed by the principals
to these servers but where the same globally unique identifiers are being used by these servers.

When the sub claim contains a locally unique identifier in the context of the issuer, this also allows the tracking of principal activities across multiple resource servers.

The scope request parameter is the only way to influence on the content of the sub claim parameter. Its meaning is subject to a private agreement
between the client and the AS, which means that the use of the scope parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary importance that the returned scope matches with the expectations of the client before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able to choose whether it wishes the sub claim to contain :
    - a different pseudonym for each RS so that different resource servers will be unable to correlate its activities, or
    - a different pseudonym for each authorization token request, so that the same resource server cannot correlate its activities performed at different instant of time.

Considering the semantics of the sub claim, these two cases cannot be currently supported.

4) The next topic is about the targeting of access tokens
Text had been proposed before the last conference call. Then, the topic has been presented at the very end of the last conference call, but no text has been included
in the next draft.
Here is a revised text be included in the privacy considerations section:
For security reasons, some clients may be willing to target their access tokens but, for privacy reasons, may be unwilling to disclose to Authorization Servers
an identification of the Resource Servers they are going to access, so that Authorization Servers will be unable to know which resources servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization Servers to list all the Resource Servers being access by all its users and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users accesses to Resource Servers performed through a given Authorization Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis
Hi all,

Here is the document:

Regards,
 Rifaat & Hannes

OAuth mailing list

---

From: Denis <[email-masked]>
Date: Thu, 30 Apr 2020 11:50:04 +0200

Hello Vittorio,

Your reply was amazingly fast. Responses are between the lines.

> /> The title of this spec./
>
> Fixed, thanks!
>

> /> The client MUST NOT inspect the content of the access token/
>
>
> This is really a sticky point. I really want to acknowledge your PoV 
> on this, but at the same time I found this to be one of the biggest 
> sources of issues
> in the use of JWT for access tokens hence I feel we really need to 
> give solid guidance here. Let me expand further on the reasoning 
> behind it,
> and perhaps we can get to language that satisfies both PoVs.
>
>
> To me the key point is that clients should not write /code/ that 
> inspects access tokens. Taking a dependency on the ability to do so is 
> ignoring fundamental information
> about the architecture and relationships between OAuth roles, and 
> suggests an ability of the client to understand the semantic of the 
> content that cannot be assumed
> in the general case. I expanded on the details in my former reply to 
> you on this topic, I would recommend referring to it.
>
> Clients violating this simple principle has been one of the most 
> common sources of production issues I had to deal with in the past few 
> years, and one of the hardest
> to remediate given that clients are hard to update and sometimes the 
> things they relied on were irremediably lost. This is why I am 
> inclined to put in here strong language.
>
> That said: I have nothing against client developers examining a 
> network trace and drawing conclusions based on the content of what 
> they see. That doesn’t create any hard
> dependencies and has no implications in respect to changes in the 
> solution behavior. However I am not sure how to phrase that in the 
> specification, given that referring
> to the client inevitably refers to its code. I am open to suggestions.
>
First of all, a "*MUST NOT* "should not be placed in a privacy 
considerations section, but in the main body of the document.
The goal of a privacy considerations section is to provide explanations, 
but not to introduce additional requirements.

Then after, since this section is about privacy considerations, it is 
important to refer to an ISO standard that has been published 9 years ago.

It is ISO 29100 (Information technology — Security techniques — Privacy 
framework). Most of the ISO standards need to be bought.
However, there are a few exceptions and this standard can be freely 
downloaded from the ISO web site, if you accept some conditions,
using this URL:

    https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ISO 29100, even if it is outdated on some aspects (it only deals with 
two entities), identifies ten principles (See Table 3).

    1. Consent and choice

    2. Purpose legitimacy and specification

    3. Collection limitation

    4. Data minimization

    5. Use, retention and disclosure limitation

    6. Accuracy and quality

    7. Openness, transparency and notice

    8. Individual participation and access

    9. Accountability

    10. Information security

    11. Privacy compliance

If the client is unable to inspect the token, then openness and 
transparency do not exist any more.

Since there is no formal protocol in OAuth 2.0  for "consent and 
choice", the only way for a client for denying its consent is to inspect 
the token
and to stop its transmission if the content of the token is not 
considered to be adequate for it.

Since you are open to suggestions, would you please reconsider the text 
I proposed: it simply states that if the client wants to inspect the token,
it will not necessarily be in a position to do it. It is simply a 
warning, but this warning does not prevent the client to attempt to 
inspect the token .

I will go one step further: if the client wants to inspect the token and 
if the format of the token is unknown to the client, then the client 
will simply
stop its further transmission. For some clients, preserving their 
privacy may be more important than performing an access to a RS.

> >  3)…
>
> I have a pretty hard time following the chain of reasoning in this 
> section. Let me attempt to tackle it to the best of my understanding.
>
> I think the key might be
>
> /> a client should be able to choose whether it wishes the sub claim 
> to contain [..]
>
> /
>
> I don’t think that should be a choice left to the client. In business 
> systems, my experience is that the type of identifiers to be used 
> (when the IdP gives any choice at all)
>  is established at resource provisioning time. I am not aware of 
> mechanisms thru which a client signals the nature of the identifier to 
> be used, nor that would be fully
> feasible (the resource knows what it needs to perform its function).
>
Consent and choice is the first of the ten privacy principles. Since 
OAuth has not been constructed taking into considerations this privacy 
principle,
it is quite "normal" that you don't observe protocols able to do it at 
the present time.

> Furthermore:
>
> /> which has nothing to do with uniqueness since the value changes for 
> every generated token.
>
> /
>
> Again, this is something that was touched on in my former reply to 
> your message. As long as an identifier identifies one resource only, 
> it satisfies uniqueness. It doesn’t have to be a singleton.
>
It is a matter of interpretation. I stick to the definition given in RFC 
7519 (section 4.1.2):

*T**he subject value MUST either be scoped to be locally unique in the 
context of the issuer or be globally unique.*

However, the "context of the issuer" is left undefined.

> Finally, the scope is optional (for good reasons: 1^st party and non 
> delegation scenarios don’t require it) hence it cannot be relied upon 
> for properties that should hold in every scenario.
>
I would not say that the scope request parameter is a nice way to choose 
which attributes should be placed in a JWT. However, considering the 
limitations placed
in this document, it is the ONLY way to do. In my email sent before the 
virtual meeting, I wrote: "Allowing a client to only specify a scope and 
a resource is very restrictive".

Clause 2.2.2 (second paragraph) states:

***This profile does not introduce any mechanism for a client to**
******directly request the presence of specific claims in JWT access**
******tokens*, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Currently, the client has no control of the claims that will be placed 
in a JWT and further more the current wording of privacy consideration 
section
prevents the client to have any inspection of the attributes that have 
been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
fulfilled.

There are more implications. If, in the future, a mechanism is defined 
to allow the client to choose the type of the attributes that should be 
placed in a JWT,
then the "sub" claim is insufficient. Taking into consideration my 
previous email, four types of attributes types would need to be specified:

The client should be able to choose whether it wishes a claim that contains:

  *      a global unique identifier for all ASs ("globally unique"),
  *      a unique identifier for each AS ("locally unique in the context
    of the issuer"),
  *      a different pseudonym for each RS, or
  *      a different pseudonym for each authorization token request.

Clause 2.2.2 states:

*   the authorization server can determine what additional**
******claims are required by a particular resource server* by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

I don't believe this is true in general. Considering its privacy 
preferences, only the client may know what is appropriate: not the AS, 
neither the RS.

> In summary: per the preceding thread on this topic, the consensus was 
> that varying the sub content was a satisfactory way of protecting 
> against correlation.
>
"/if all you have is a hammer, everything looks like a nail/".

When the only parameter that can be used is the "sub" claim, then the 
only solution is to place everything into it.

> I don’t a gree that clients should have a mechanism to request 
> different sub flavors, as that decision should be done out of band by 
> the AS and RS; and the scope isn’t always available anyway.
>
While it would be nice to have such a mechanism, we are not going to 
define such a mechanism during a second WGLC.

The privacy considerations section should only inform the readers about 
the limitations of the protocol in terms of privacy.
I have proposed text to address the point. If you would prefer a 
different wording to address this point, please make another proposal.

> /> targeting of access tokens/
>
> I acknowledge that the decision of including an audience has the 
> effect of letting the AS track when the client accesses a particular 
> resource,
> but at the same time that’s completely mainstream and very much by 
> design in a very large number of cases. As such, I find the language
> you are suggesting to be potentially confusing, as it positions this 
> as an exception vs a privacy protecting mainstream that is in fact not 
> common,
> and ascribes to the client more latitude than I believe is legitimate 
> to expect or grant.
>
> I’ll try to come up with concise language that clarifies to the reader 
> that the current mechanism does allow AS tracking.
>
Please do so.

Denis

> *From: *OAuth <[email-masked]> on behalf of Denis 
> <[email-masked]>
> *Date: *Wednesday, April 29, 2020 at 09:12
> *To: *"[email-masked]" <[email-masked]>
> So, this spec. is supposed to be targeted to OAuth *2.0. * However, 
> the header at the top of the page omits to mention it.
>
> Currently, it is :
>
> Internet-Draft OAuth *2.0* Access Token JWT Profile           April 2020
>
> When the sub claim contains a globally unique identifier, this allows 
> to correlate principal activities across multiple resource servers, 
> while in addition,
> The scope request parameter is the only way to influence on the 
> content of the sub claim parameter. Its meaning is subject to a 
> private agreement
> Since the scope parameter is being returned, it is a primary 
> importance that the returned scope matches with the expectations of 
> the client before transmitting
> However, there are other cases where the client would like to be able 
> to choose whether it wishes the sub claim to contain :
>     - a different pseudonym for each RS so that different resource 
> servers will be unable to correlate its activities, or
>     - a different pseudonym for each authorization token request, so 
> that the same resource server cannot correlate its activities 
> performed at different instant of time.
>
> Text had been proposed before the last conference call. Then, the 
> topic has been presented at the very end of the last conference call, 
> but no text has been included
> in the next draft.
>
> For security reasons, some clients may be willing to target their 
> access tokens but, for privacy reasons, may be unwilling to disclose 
> to Authorization Servers