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

[Richard Backman, Annabelle]

ns that an identifier of the profile of the AT should be

able to be included into the AT. This allows for future extensions.///



Can you expand on the exact scenario you are thinking of that calls

for a version? If it’s a matter of extensions, those should always be

possible – it’s more breaking changes that require versioning, but I

don’t recall precedents in similar specs.



If this is aimed at mitigating the “AS changes format without telling

RS”, I don’t think that would work – besides of being unnecessary per

the above considerations, this wouldn’t protect the RS from changes

well within the current spec (which allows adding arbitrary claims as

long as it’s done according to JWT rules), from changes within the

claim content (eg private string formats) and from complete departures

from the use of JWT for ATs.



/>//Allowing a client to only specify a scope and a resource is very

restrictive./



Specifying scope or using resource indicators are all the mechanisms I

am aware of that OAuth2 offers for specifying what an access token

should be for- at least at the time in which the spec was incepted. In

fact, resource indicators was not even RFC and in market vendors used

proprietary functional equivalents. What other interoperable

mechanisms would you offer in addition to the ones listed here?



*From: *OAuth <mailto:oauth-boun...@ietf.org> on behalf 
of Denis

<mailto:denis.i...@free.fr>

*Date: *Thursday, April 9, 2020 at 09:26

*To: *oauth <mailto:oauth@ietf.org>

*Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for

OAuth 2.0 Access Tokens"



I have three concerns, two of them being related to privacy.



1) Privacy has not really been a concern in the WG since originally

the AT and the RS were co-located. However, this draft now recognizes

that there may exist cases where "the authorization server and

resource server are not co-located, are not ran by the same entity,

or are otherwise separated by some boundary".



*In such cases*, it is important to be able to make sure that an

authorization server will NOT be able to know where the authorizations

tokens that it issues will be used. Using another wording, an AS SHALL

NOT be able to know where an AT requested by a given client will be used:

*Authorization servers SHALL not have the capability to act as "Big

Brother"* and thus SHALL not be able to know which resources are going

to be accessed by clients.



This means that, in such cases, an authorization server SHALL not be

able to know for which resource server an AT has been targeted.



It is a fact that most solutions currently deployed support a built-in

*"Spy by design"* architecture instead of a *"Privacy by design"*

architecture.



However, for security reasons an AT still needs to be targeted.



The problem to be solved is the following:



  * for security reasons, the AT must be targeted.

  * for privacy reasons, the AS must be kept ignorant of the name of

the target.



One way to solve the problem is to consider that the AT is composed of

a sequence of two structures: a signed structure and an unsigned

structure.



The signed structure contains a "salted aud claim".

The unsigned structure contains a "aud salt claim".



In practice, the "salted aud claim" will be composed of both a one way

hash function algorithm identifier and a hash value.



Before requesting an AT to an AS, the client chooses a resource server

and select a resource indicator value corresponding to the identifier

the resource server.

It then chooses a random value which it uses as a "aud salt claim" and

then computes a hash value by using a one-way hash function which

combines

one of the resource indicators of the RS with the "aud salt claim".

Both the one way hash function algorithm identifier and the computed

hash value

are then included into the "salted aud claim".



The AT request then contains a "salted aud claim" instead of an"aud

claim". The AT blindly copies this value into the AT which is then

identified as

a "salted aud claim" instead of an "aud claim".



When the AT is received by the client, it adds to the AT the unsigned

part to the AT which contains the "aud salt claim" and sends both the

signed

and the unsigned part of the AT to the RS.



When the RS receives the AT, using the one way hash function algorithm

identifier contained in the "salted aud claim", it combines each of

its resource indicators

with the "aud salt claim" contained in the unsigned part of the AT and

verifies whether it matches with the hash value contained in the

"salted aud claim".

If none of these resource indicators is providing a match, then the RS

SHALL rejected the AT.



The implication is to allow an AT to contain both a signed part a

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

[Denis]

ifact meant to
enable the client to access a resource. Its format remains a private
matter between the RS and the AS, which retains the freedom to change
it as they see fit without worrying about client code that takes a
dependency on characteristics of the AT that might very well be
transient. As far the client is concerned, the RS and the AS might
switch their agreement from JWT AT to opaque tokens to be validated
via introspection at any time, which would break any client side logic
inspecting the AT and expecting it to be a JWT. The client has no
control whatsoever on the content that is transmitted via opaque
token, hence privacy-wise the fact that the content of the JWT is
visible is more of a concern about such content being accessible on
the client. One additional point: even if clients would be able to
safely peek inside an AT without risking breaking their code, there’s
no guarantee that the client would understand the semantic of the
claims in the AT, as those are meant for consumption by the RS which
can assign any semantic to them; nor the client can reliably trust the
content of the claims, given that the AS could and sometimes will
encrypt their content for the intended recipient (another reason for
which the AS in the general case needs to know the intended recipient).

/>. It is possible for an AS to change the format of the AT, but the
RS will not necessarily be in synch with the RS. /

I don’t understand this sentence. Is the last RS meant to be AS?

Assuming that’s the case: It doesn’t look very likely that an RS would
simply accept tokens from an AS without some out of band negotiation,
nor it seems very likely that an AS would issue tokens for resources
it doesn’t know- see above. Such scenarios might exist, but they don’t
seem to model common business solutions or the typical deployment,
where an API will be protected by middleware/gateway with precise
assumptions on how to validate incoming tokens. There might be changes
that are inconsequential (order of claims, additional claims) but
anything more substantive would likely simply break the solution.

/> This means that an identifier of the profile of the AT should be
able to be included into the AT. This allows for future extensions.///

Can you expand on the exact scenario you are thinking of that calls
for a version? If it’s a matter of extensions, those should always be
possible – it’s more breaking changes that require versioning, but I
don’t recall precedents in similar specs.

If this is aimed at mitigating the “AS changes format without telling
RS”, I don’t think that would work – besides of being unnecessary per
the above considerations, this wouldn’t protect the RS from changes
well within the current spec (which allows adding arbitrary claims as
long as it’s done according to JWT rules), from changes within the
claim content (eg private string formats) and from complete departures
from the use of JWT for ATs.

/>//Allowing a client to only specify a scope and a resource is very
restrictive./

Specifying scope or using resource indicators are all the mechanisms I
am aware of that OAuth2 offers for specifying what an access token
should be for- at least at the time in which the spec was incepted. In
fact, resource indicators was not even RFC and in market vendors used
proprietary functional equivalents. What other interoperable
mechanisms would you offer in addition to the ones listed here?

*From: *OAuth  on behalf of Denis

*Date: *Thursday, April 9, 2020 at 09:26
*To: *oauth 
*Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally
the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and
resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be
able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in
*"Spy by design"* architecture instead of a *"Privacy by design"*
architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

   * for security reasons, the AT must be targeted.
   * for privacy reasons, the AS must be kept ignoran

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

[Benjamin Kaduk]

s solutions or the typical deployment, 
> > where an API will be protected by middleware/gateway with precise 
> > assumptions on how to validate incoming tokens. There might be changes 
> > that are inconsequential (order of claims, additional claims) but 
> > anything more substantive would likely simply break the solution.
> >
> > /> This means that an identifier of the profile of the AT should be 
> > able to be included into the AT. This allows for future extensions.///
> >
> > Can you expand on the exact scenario you are thinking of that calls 
> > for a version? If it’s a matter of extensions, those should always be 
> > possible – it’s more breaking changes that require versioning, but I 
> > don’t recall precedents in similar specs.
> >
> > If this is aimed at mitigating the “AS changes format without telling 
> > RS”, I don’t think that would work – besides of being unnecessary per 
> > the above considerations, this wouldn’t protect the RS from changes 
> > well within the current spec (which allows adding arbitrary claims as 
> > long as it’s done according to JWT rules), from changes within the 
> > claim content (eg private string formats) and from complete departures 
> > from the use of JWT for ATs.
> >
> > />//Allowing a client to only specify a scope and a resource is very 
> > restrictive./
> >
> > Specifying scope or using resource indicators are all the mechanisms I 
> > am aware of that OAuth2 offers for specifying what an access token 
> > should be for- at least at the time in which the spec was incepted. In 
> > fact, resource indicators was not even RFC and in market vendors used 
> > proprietary functional equivalents. What other interoperable 
> > mechanisms would you offer in addition to the ones listed here?
> >
> > *From: *OAuth  on behalf of Denis 
> > 
> > *Date: *Thursday, April 9, 2020 at 09:26
> > *To: *oauth 
> > *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
> > OAuth 2.0 Access Tokens"
> >
> > I have three concerns, two of them being related to privacy.
> >
> > 1) Privacy has not really been a concern in the WG since originally 
> > the AT and the RS were co-located. However, this draft now recognizes
> > that there may exist cases where "the authorization server and 
> > resource server are not co-located, are not ran by the same entity,
> > or are otherwise separated by some boundary".
> >
> > *In such cases*, it is important to be able to make sure that an 
> > authorization server will NOT be able to know where the authorizations
> > tokens that it issues will be used. Using another wording, an AS SHALL 
> > NOT be able to know where an AT requested by a given client will be used:
> > *Authorization servers SHALL not have the capability to act as "Big 
> > Brother"* and thus SHALL not be able to know which resources are going
> > to be accessed by clients.
> >
> > This means that, in such cases, an authorization server SHALL not be 
> > able to know for which resource server an AT has been targeted.
> >
> > It is a fact that most solutions currently deployed support a built-in 
> > *"Spy by design"* architecture instead of a *"Privacy by design"* 
> > architecture.
> >
> > However, for security reasons an AT still needs to be targeted.
> >
> > The problem to be solved is the following:
> >
> >   * for security reasons, the AT must be targeted.
> >   * for privacy reasons, the AS must be kept ignorant of the name of
> > the target.
> >
> > One way to solve the problem is to consider that the AT is composed of 
> > a sequence of two structures: a signed structure and an unsigned 
> > structure.
> >
> > The signed structure contains a "salted aud claim".
> > The unsigned structure contains a "aud salt claim".
> >
> > In practice, the "salted aud claim" will be composed of both a one way 
> > hash function algorithm identifier and a hash value.
> >
> > Before requesting an AT to an AS, the client chooses a resource server 
> > and select a resource indicator value corresponding to the identifier 
> > the resource server.
> > It then chooses a random value which it uses as a "aud salt claim" and 
> > then computes a hash value by using a one-way hash function which 
> > combines
> > one of the resource indicators of the RS with the "aud salt claim". 
> > Both the one way hash function algorithm identifier and the computed  

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

[Denis]

token, hence privacy-wise the fact that the content of the JWT is 
visible is more of a concern about such content being accessible on 
the client. One additional point: even if clients would be able to 
safely peek inside an AT without risking breaking their code, there’s 
no guarantee that the client would understand the semantic of the 
claims in the AT, as those are meant for consumption by the RS which 
can assign any semantic to them; nor the client can reliably trust the 
content of the claims, given that the AS could and sometimes will 
encrypt their content for the intended recipient (another reason for 
which the AS in the general case needs to know the intended recipient).


/>. It is possible for an AS to change the format of the AT, but the 
RS will not necessarily be in synch with the RS. /


I don’t understand this sentence. Is the last RS meant to be AS?

Assuming that’s the case: It doesn’t look very likely that an RS would 
simply accept tokens from an AS without some out of band negotiation, 
nor it seems very likely that an AS would issue tokens for resources 
it doesn’t know- see above. Such scenarios might exist, but they don’t 
seem to model common business solutions or the typical deployment, 
where an API will be protected by middleware/gateway with precise 
assumptions on how to validate incoming tokens. There might be changes 
that are inconsequential (order of claims, additional claims) but 
anything more substantive would likely simply break the solution.


/> This means that an identifier of the profile of the AT should be 
able to be included into the AT. This allows for future extensions.///


Can you expand on the exact scenario you are thinking of that calls 
for a version? If it’s a matter of extensions, those should always be 
possible – it’s more breaking changes that require versioning, but I 
don’t recall precedents in similar specs.


If this is aimed at mitigating the “AS changes format without telling 
RS”, I don’t think that would work – besides of being unnecessary per 
the above considerations, this wouldn’t protect the RS from changes 
well within the current spec (which allows adding arbitrary claims as 
long as it’s done according to JWT rules), from changes within the 
claim content (eg private string formats) and from complete departures 
from the use of JWT for ATs.


/>//Allowing a client to only specify a scope and a resource is very 
restrictive./


Specifying scope or using resource indicators are all the mechanisms I 
am aware of that OAuth2 offers for specifying what an access token 
should be for- at least at the time in which the spec was incepted. In 
fact, resource indicators was not even RFC and in market vendors used 
proprietary functional equivalents. What other interoperable 
mechanisms would you offer in addition to the ones listed here?


*From: *OAuth  on behalf of Denis 


*Date: *Thursday, April 9, 2020 at 09:26
*To: *oauth 
*Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally 
the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and 
resource server are not co-located, are not ran by the same entity,

or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going

to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be 
able to know for which resource server an AT has been targeted.


It is a fact that most solutions currently deployed support a built-in 
*"Spy by design"* architecture instead of a *"Privacy by design"* 
architecture.


However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  * for security reasons, the AT must be targeted.
  * for privacy reasons, the AS must be kept ignorant of the name of
the target.

One way to solve the problem is to consider that the AT is composed of 
a sequence of two structures: a signed structure and an unsigned 
structure.


The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way 
hash function algorithm identifier and a hash value.


Before requesting an AT to an AS, the client chooses a resource server 
and select a resource indicator value corre

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

[Vittorio Bertocci]

ns on how to validate incoming tokens. 
There might be changes that are inconsequential (order of claims, additional 
claims) but anything more substantive would likely simply break the solution.

> This means that an identifier of the profile of the AT should be able to be 
> included into the AT. This allows for future extensions.
Can you expand on the exact scenario you are thinking of that calls for a 
version? If it’s a matter of extensions, those should always be possible – it’s 
more breaking changes that require versioning, but I don’t recall precedents in 
similar specs.
If this is aimed at mitigating the “AS changes format without telling RS”, I 
don’t think that would work – besides of being unnecessary per the above 
considerations, this wouldn’t protect the RS from changes well within the 
current spec (which allows adding arbitrary claims as long as it’s done 
according to JWT rules), from changes within the claim content (eg private 
string formats) and from complete departures from the use of JWT for ATs.

> Allowing a client to only specify a scope and a resource is very restrictive.
Specifying scope or using resource indicators are all the mechanisms I am aware 
of that OAuth2 offers for specifying what an access token should be for- at 
least at the time in which the spec was incepted. In fact, resource indicators 
was not even RFC and in market vendors used proprietary functional equivalents. 
What other interoperable mechanisms would you offer in addition to the ones 
listed here?


From: OAuth  on behalf of Denis 
Date: Thursday, April 9, 2020 at 09:26
To: oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the AT and 
the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource server 
are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an authorization 
server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be 
able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and 
thus SHALL not be able to know which resources are going
to be accessed by clients.
This means that, in such cases, an authorization server SHALL not be able to 
know for which resource server an AT has been targeted.
It is a fact that most solutions currently deployed support a built-in "Spy by 
design" architecture instead of a "Privacy by design" architecture.
However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  *   for security reasons, the AT must be targeted.
  *   for privacy reasons, the AS must be kept ignorant of the name of the 
target.
One way to solve the problem is to consider that the AT is composed of a 
sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way hash 
function algorithm identifier and a hash value.
Before requesting an AT to an AS, the client chooses a resource server and 
select a resource indicator value corresponding to the identifier the resource 
server.
It then chooses a random value which it uses as a "aud salt claim" and then 
computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both the 
one way hash function algorithm identifier and the computed  hash value
are then included into the "salted aud claim".
The AT request then contains a "salted aud claim" instead of an"aud claim". The 
AT blindly copies this value into the AT which is then identified as
a "salted aud claim" instead of an "aud claim".
When the AT is received by the client, it adds to the AT the unsigned part to 
the AT which contains the "aud salt claim" and sends both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm 
identifier contained in the "salted aud claim", it combines each of its 
resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and verifies 
whether it matches with the hash value contained in the "salted aud claim".
If none of these resource indicators is providing a match, then the RS SHALL 
rejected the AT.

The implication is to allow an AT to contai

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

[Denis]

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the 
AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity,

or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the **capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going

to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be 
able to know for which resource server an AT has been targeted.


It is a fact that most solutions currently deployed support a built-in 
*"Spy by desig**n"* architecture instead of a *"Privacy by design"* 
architecture.


However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

 * for security reasons, the AT must be targeted.
 * for privacy reasons, the AS must be kept ignorant of the name of the
   target.

One way to solve the problem is to consider that the AT is composed of a 
sequence of two structures: a signed structure and an unsigned structure.


The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way 
hash function algorithm identifier and a hash value.


Before requesting an AT to an AS, the client chooses a resource server 
and select a resource indicator value corresponding to the identifier 
the resource server.
It then chooses a random value which it uses as a "aud salt claim" and 
then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both 
the one way hash function algorithm identifier and the computed  hash value

are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud 
claim". The AT blindly copies this value into the AT which is then 
identified as

a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned 
part to the AT which contains the "aud salt claim" and sends both the 
signed

and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm 
identifier contained in the "salted aud claim", it combines each of its 
resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and 
verifies whether it matches with the hash value contained in the "salted 
aud claim".
If none of these resource indicators is providing a match, then the RS 
SHALL rejected the AT.


The implication is to allow an AT to contain both a signed part and an 
unsigned part.


In addition, the "aud claim" should be multi-valued where, as a 
consequence, both the "salted aud claim" with the "aud salt claim" would 
also be multi-valued.



2) Within clause 6, "Privacy Considerations", the text states:

As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers to directly peek inside the
token claims collection.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 (...).

On the contrary, a client SHALL be able to inspect the content of the 
access token to make sure that the AS has not included in the AT some 
private information
that should not be present, before forwarding the AT to the RS. It is 
possible for an AS to change the format of the AT, but the RS will not 
necessarily be in synch

with the RS.

Since there are now cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity, or are 
otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily 
need to know each other. The RS only needs to trust the AS. (full stop)


This means that an identifier of the profile of the AT should be able to 
be included into the AT. This allows for future extensions.


In any case, the "MUST NOT" in the quoted sentence should be removed or 
changed or the whole sentence should be removed..



3) Within clause 2.2.2 (second paragraph):

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

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

[George Fletcher]

Thanks Vittorio for the thorough response!

I agree that how scopes are handled is very different across 
deployments. Scopes used for an RP with a mobile app (e.g. something 
like OpenTable) are going to be very different than a multi-tenant 
enterprise system with fixed services and roles that all tenants much 
use. I'm not sure it is possible to clearly map this disparate set of 
deployments into a common set of spec language. It's possible to define 
a solution that is maybe "majority" but anyone wanting to conform with a 
different deployment strategy will just "munge" the 'aud' value to make 
their deployment work. I'm not sure that adds a lot of value. I think I 
would prefer a multi-valued 'aud' claim of "mail.example, 
contacts.example, news.example" over a generic "api.example". The former 
provides value to limit the scope of the token where the latter does not.


I agree that scopes were not well specified in 6749/6750 and now it's a 
bit of the wild west. Some treat scopes as capabilities, some treat them 
as roles, some as attributes, some as flags for specific token behavior 
and the list goes on:)


Personally, I'd prefer using RECOMMENDED for the current defined spec 
language without making that model required.


If we truly want interoperable access_tokens cross IDPs, then I think we 
have a lot more spec work to do than describing the token format. This 
is a important and necessary building block, but behaviors and how they 
map may be outside the scope of this work.


Thanks,
George

On 4/3/20 5:03 AM, Vittorio Bertocci wrote:

Thanks Annabelle and George!  I am consolidating replies to both your latest 
comments in this mail. This seems a hard rock to lift, but it also seems to be 
the last one .

The TL;DR is, I am not completely opposed to relaxing the constraints and 
turning them into security considerations, but I think we’d miss an opportunity 
to make things clearer for developers. At the same time I wouldn’t want to make 
this profile too patronizing, hence I appreciate the opportunity to discuss.



[Annabelle]

   >. There may be no "scope" parameter.  The "scope" parameter is OPTIONAL in 
authorization requests. So an AS/RS operator could decide they're going to omit "scope" entirely and 
use multiple resource parameters instead. Since there are no scopes, there is no opportunity for confusion.

I am a BIG fan of ATs with no scope- all the scenarios where there’s no 
delegation (1st parties etc) shouldn’t use scopes at all. The current language 
in the profile does allow for scope-less ATs, and given that the goal is to 
prevent confusion, I agree that there’s no need to restrict the audience to one 
single resource if there are no scopes at all to misinterpret.

I would be in favor to allow multiple resources in audience in that case.

Unfortunately it’s not as simple as just saying “If the incoming request 
incudes multiple resource indicators and no scope, accept it and use the 
incoming resource indicators list as aud value” – mostly because there is a 
very large number of production systems where the request includes no scopes 
and one resource indicator, but the resulting token includes a collection of 
scopes the user already consented to for that resource- but I am sure we can 
get to acceptable language that expresses the concept “if there are multiple 
resource indicators in the request and the rest of the rules in S.3 the 
resulting AT won’t contain a scope claim, the resulting AT must use that 
resource indicators list as aud value”.




An AS/RS operator may use "scope" to indicate a role or policy (or set of policies) that the client wants, 
and allow the client to narrow their permissions using "resource" parameters. This would allow the client to 
obtain narrowly scoped access tokens for specific use cases without needing to define separate roles/policies for each. 
In this case, a JWT AT with a multi-valued "aud" claim and a "scope" claim would seem appropriate, 
as the scope claim is intended to apply to all of the audience values.

I agree that deployments like the one you describe might exist, in fact I am 
sure they do. However it seems really a brittle approach, given that it makes a 
specific assumption (scopes are valid across all the resources) that isn’t 
enshrined anywhere and if future updates to that deployment violate that 
assumption, that would lead to the scope confusion the current language in the 
profile is trying to prevent. We offer very little guidance in that respect: 
the main place were multiple resources are even mentioned is resource 
indicators, and all the samples (I know, non-normative) use scopes 
unambiguously tied to a specific resource (more on that later) making the 
multi-resource scope even more of a special case.



Stepping back a bit - the intent behind those resource-scope restrictions is to 
provide a bit more guidance on scopes and resources than we did in the past, 
and narrowing the range of cases developers 

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

[Vittorio Bertocci]

Thanks Annabelle and George!  I am consolidating replies to both your latest 
comments in this mail. This seems a hard rock to lift, but it also seems to be 
the last one .

The TL;DR is, I am not completely opposed to relaxing the constraints and 
turning them into security considerations, but I think we’d miss an opportunity 
to make things clearer for developers. At the same time I wouldn’t want to make 
this profile too patronizing, hence I appreciate the opportunity to discuss.



[Annabelle]

  >. There may be no "scope" parameter.  The "scope" parameter is OPTIONAL in 
authorization requests. So an AS/RS operator could decide they're going to omit 
"scope" entirely and use multiple resource parameters instead. Since there are 
no scopes, there is no opportunity for confusion.

I am a BIG fan of ATs with no scope- all the scenarios where there’s no 
delegation (1st parties etc) shouldn’t use scopes at all. The current language 
in the profile does allow for scope-less ATs, and given that the goal is to 
prevent confusion, I agree that there’s no need to restrict the audience to one 
single resource if there are no scopes at all to misinterpret.

I would be in favor to allow multiple resources in audience in that case.

Unfortunately it’s not as simple as just saying “If the incoming request 
incudes multiple resource indicators and no scope, accept it and use the 
incoming resource indicators list as aud value” – mostly because there is a 
very large number of production systems where the request includes no scopes 
and one resource indicator, but the resulting token includes a collection of 
scopes the user already consented to for that resource- but I am sure we can 
get to acceptable language that expresses the concept “if there are multiple 
resource indicators in the request and the rest of the rules in S.3 the 
resulting AT won’t contain a scope claim, the resulting AT must use that 
resource indicators list as aud value”.



> An AS/RS operator may use "scope" to indicate a role or policy (or set of 
> policies) that the client wants, and allow the client to narrow their 
> permissions using "resource" parameters. This would allow the client to 
> obtain narrowly scoped access tokens for specific use cases without needing 
> to define separate roles/policies for each. In this case, a JWT AT with a 
> multi-valued "aud" claim and a "scope" claim would seem appropriate, as the 
> scope claim is intended to apply to all of the audience values.

I agree that deployments like the one you describe might exist, in fact I am 
sure they do. However it seems really a brittle approach, given that it makes a 
specific assumption (scopes are valid across all the resources) that isn’t 
enshrined anywhere and if future updates to that deployment violate that 
assumption, that would lead to the scope confusion the current language in the 
profile is trying to prevent. We offer very little guidance in that respect: 
the main place were multiple resources are even mentioned is resource 
indicators, and all the samples (I know, non-normative) use scopes 
unambiguously tied to a specific resource (more on that later) making the 
multi-resource scope even more of a special case.



Stepping back a bit - the intent behind those resource-scope restrictions is to 
provide a bit more guidance on scopes and resources than we did in the past, 
and narrowing the range of cases developers would need to take into account 
when implementing the profile.

In my experience the lack of more prescriptive guidance led to deployments and 
interpretations that, while remaining fully within the boundary of what the 
spec allows, are often questionable from the security and arch perspective.

(*)I acknowledge that I might be swinging too far in the opposite direction, 
and perhaps a similar effect could be achieved by adding an “Authorization 
Considerations” section where implementers are warned about the danger of scope 
confusion rather than downright forbidding multi resources audiences when 
including scopes as well. I still like the simplicity and clarity of the 
current restriction, but of course I am open to feedback.



> The mapping between audience and scope may be unambiguous. There are a lot of 
> deployments to which the blast radius risk you're trying to address by 
> requiring "aud" simply does not apply

There are certainly cases where scope strings unambiguously map to specific 
resources, but once again, that’s a strong assumption to make and one I feel 
cannot be made lightly. Resource indicators use very simple examples (contacts, 
calendar) that are hard to generalize to scenarios where the number and 
lifecycle of resources truly calls for the use of indicators identifying a 
resource in a large multitenant system usually entails large identifiers, and 
stuffing those in the scope to prevent ambiguity can be expensive from both 
provisioning and token, request size angles.



>It may seem innocuous to 

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

[Vittorio Bertocci]

Thank you! I updated the language accordingly, and added a warning in the 
security section aligned with Annabelle’s concerns.
Updating the draft shortly.

From: Brian Campbell 
Date: Thursday, March 26, 2020 at 09:47
To: Vittorio Bertocci 
Cc: George Fletcher , Brian Campbell 
, oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

Preventing token substitution/confusion was not at all the aim of my comment. I 
only brought that up in an attempt to bridge what looked like a communication 
gap in Annabelle's and your discussion. Sorry for any confusion that might have 
caused.

That discussion did lead me to think again about the more general issue of 
signalling/figuring out what key from jwks_uri (which has content that isn't 
static and likely changes over time for key rotation) used to sign. Then 
looking again at draft-ietf-oauth-access-token-jwt-04 to realize that it's 
pretty much silent about this bit that I think is an important aspect to 
interop.

The text you suggested definitely works better, yes. Thank you. I could say 
that there'd be value in saying more but, as previously promised, I won't argue 
it further.

On Wed, Mar 25, 2020 at 5:46 PM Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>> wrote:
I think I am missing something here. It’s not that I don’t want to give 
guidance, is that it seems that the guidance you are thinking of isn’t 
necessary unless we think that enforcing explicitkey-token type assignment 
declaration is necessary. I didn’t get the impression that it was the proposal 
so far, what I have read was “if the intent was to prevent token 
confusion/substitution, this is insufficient”, to which the answer was “that 
was not the intent”.
And if preventing token substitution/confusion is not the aim, then the only 
guidance required here to the RS is “expect that any key published in the doc 
pointed by jwks_uri could be used to sign the AT” which seems actionable enough.
I do agree that the language could be more explicitly aimed at that outcome.. 
Would something to the effect of “The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs” work better?

From: Brian Campbell 
mailto:bcampb...@pingidentity.com>>
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci 
mailto:vittorio.berto...@auth0.com>>
Cc: George Fletcher mailto:gffle...@aol.com>>, Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>,
 oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

It seems to me that leaving that out of scope is rather antithetical to the 
previously stated reason for the profile using only asymmetric signatures, 
namely that "this profile focuses on a solution that is as close to turnkey as 
possible for developers." And I'd suggest that, to borrow your words, looking 
at this from the useful guidance standpoint rather than the “lawyering up” 
perspective, some guidance on determining the correct key to use from the keys 
at the jwks_uri to verify the signature on the AT would be very useful in 
general and also prevent the kind of potential missteps you described. I mean, 
if nothing is said about it or even if it'd said to be out of scope, a working 
interoperable approach could probably be inferred by knowing and applying bits 
of JWS, JWA, JWK, etc.. But, to me anyway, it seems incongruent to expect folks 
to figure all that out but at the same time believe them capable of mistakes 
that would be prevented by only pointing out that ATs and ID tokens might be 
signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that 
kind of guidance in the Asymmetric bit of 
https://openid.net/specs/openid-connect-core-1_0.html#Signing and 
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's not 
perfect (this 
issue<https://bitbucket..org/openid/connect/issues/1161/key-rotation-should-require-a-delay>
 was raised just recently) but attempts to convey how verification key 
selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this one. 
And I've spent more time here than I'd like to admit so I won't argue it 
further.



On Wed, Mar 25, 2020 at 12:57 PM 
mailto:vittorio.berto...@auth0.com>> wrote:
That works for me!

From: George Fletcher mailto:gffle...@aol.com>>
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>; 'Brian 
Campbell' 
mailto:40pingidentity@dmarc.ietf.org>>
Cc: 'Brian Campbell' 
mailto:bcampb...@pingidentity.com>>; 'oauth' 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

If we don't want to give guidance on how t

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

[Brian Campbell]

Preventing token substitution/confusion was not at all the aim of my
comment. I only brought that up in an attempt to bridge what looked like a
communication gap in Annabelle's and your discussion. Sorry for any
confusion that might have caused.

That discussion did lead me to think again about the more general issue of
signalling/figuring out what key from jwks_uri (which has content that
isn't static and likely changes over time for key rotation) used to sign.
Then looking again at draft-ietf-oauth-access-token-jwt-04 to realize that
it's pretty much silent about this bit that I think is an important aspect
to interop.

The text you suggested definitely works better, yes. Thank you. I could say
that there'd be value in saying more but, as previously promised, I won't
argue it further.

On Wed, Mar 25, 2020 at 5:46 PM Vittorio Bertocci <
vittorio.berto...@auth0.com> wrote:

> I think I am missing something here. It’s not that I don’t want to give
> guidance, is that it seems that the guidance you are thinking of isn’t
> necessary unless we think that enforcing explicitkey-token type assignment
> declaration is necessary. I didn’t get the impression that it was the
> proposal so far, what I have read was “if the intent was to prevent token
> confusion/substitution, this is insufficient”, to which the answer was
> “that was not the intent”.
>
> And if preventing token substitution/confusion is not the aim, then the
> only guidance required here to the RS is “expect that any key published in
> the doc pointed by jwks_uri could be used to sign the AT” which seems
> actionable enough.
>
> I do agree that the language could be more explicitly aimed at that
> outcome. Would something to the effect of “The RS should expect the AS to
> use any of the keys published in the JWKS doc to sign JWT ATs” work better?
>
>
>
> *From: *Brian Campbell 
> *Date: *Wednesday, March 25, 2020 at 14:26
> *To: *Vittorio Bertocci 
> *Cc: *George Fletcher , Brian Campbell  40pingidentity@dmarc.ietf.org>, oauth 
> *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> It seems to me that leaving that out of scope is rather antithetical to
> the previously stated reason for the profile using only asymmetric
> signatures, namely that "this profile focuses on a solution that is as
> close to turnkey as possible for developers." And I'd suggest that, to
> borrow your words, looking at this from the useful guidance standpoint
> rather than the “lawyering up” perspective, some guidance on determining
> the correct key to use from the keys at the jwks_uri to verify the
> signature on the AT would be very useful in general and also prevent the
> kind of potential missteps you described. I mean, if nothing is said about
> it or even if it'd said to be out of scope, a working interoperable
> approach could probably be inferred by knowing and applying bits of JWS,
> JWA, JWK, etc.. But, to me anyway, it seems incongruent to expect folks to
> figure all that out but at the same time believe them capable of mistakes
> that would be prevented by only pointing out that ATs and ID tokens might
> be signed by different keys.
>
>
>
> FWIW there's some ~8 year old text in OIDC that kinda attempts to give
> that kind of guidance in the Asymmetric bit of
> https://openid.net/specs/openid-connect-core-1_0.html#Signing and
> https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys -
> it's not perfect (this issue
> <https://bitbucket.org/openid/connect/issues/1161/key-rotation-should-require-a-delay>
> was raised just recently) but attempts to convey how verification key
> selection is to be done and account for key rotation too.
>
>
>
> This seems rather cut and dry to me but maybe I'm "in the weeds" on this
> one. And I've spent more time here than I'd like to admit so I won't argue
> it further.
>
>
>
>
>
>
>
> On Wed, Mar 25, 2020 at 12:57 PM  wrote:
>
> That works for me!
>
>
>
> *From:* George Fletcher 
> *Sent:* Wednesday, March 25, 2020 11:56 AM
> *To:* vittorio.berto...@auth0.com; 'Brian Campbell'  40pingidentity@dmarc.ietf.org>
> *Cc:* 'Brian Campbell' ; 'oauth' <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> If we don't want to give guidance on how the RS determines the correct key
> to use to validate the token, then maybe we should state that explicitly.
> "The mechanism used by the RS to determine the correct key to use to
> validate the access token is out of scope for this specification".
>
> That way at least we are being very clear that the spec is not t

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

[Vittorio Bertocci]

OK, I caught up with the discussion. Very interesting.
It seems that the conclusion is that there’s no simple mechanism we can add at 
this point that would easily gel with existing deployment, hence either we tell 
people to STOP using multiple keys, or we make them aware of the futility of 
doing so as a way of enforcing security boundaries.
Is that the correct conclusion? If yes, I would suggest we use the language I 
suggested in Brian’s thread (“The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs”) to warn the RS developer that 
the AS could do that, and in the security section we warn the AS developer that 
using multiple keys won’t help much given that the RS won’t differentiate 
between tokens signed with keys from the same metadata collection anyway, hence 
it’s enough to compromise one key to generate tokens that will be accepted 
regardless of type or any other classification..
WDYT?

From: Vittorio Bertocci 
Date: Wednesday, March 25, 2020 at 16:53
To: "Richard Backman, Annabelle" , 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 
, 'George Fletcher' 
, 'Brian Campbell' 

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

Oh wow, I completely missed that thread. Thanks for the link. Reading…

From: OAuth  on behalf of "Richard Backman, Annabelle" 

Date: Wednesday, March 25, 2020 at 14:26
To: "vittorio.bertocci=40auth0@dmarc.ietf.org" 
, 'George Fletcher' 
, 'Brian Campbell' 

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

This is another manifestation of the limits of jwks_uri that I’ve brought up on 
the list 
previously<https://mailarchive.ietf.org/arch/msg/oauth/eCZ-wUU2iwTyfx-zuqr2K3bM8-8/>.

Using different signing keys does not actually limit the blast radius of each 
key, since the validator doesn’t know that each key should only be considered 
valid for one type of token. This takes away one of the major drivers for using 
different keys. If the text says deployments can use different keys, it needs 
to clarify the limited value of that.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth  on behalf of 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 

Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

That works for me!

From: George Fletcher 
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian Campbell' 

Cc: 'Brian Campbell' ; 'oauth' 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

If we don't want to give guidance on how the RS determines the correct key to 
use to validate the token, then maybe we should state that explicitly. "The 
mechanism used by the RS to determine the correct key to use to validate the 
access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com> wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.







From: Brian Campbell 
<mailto:bcampbell=40pingidentity@dmarc.ietf.org>

Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher <mailto:gffle...@aol.com>

Cc: Brian Campbell 
<mailto:bcampb...@pingi

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

[Vittorio Bertocci]

Oh wow, I completely missed that thread. Thanks for the link. Reading…

From: OAuth  on behalf of "Richard Backman, Annabelle" 

Date: Wednesday, March 25, 2020 at 14:26
To: "vittorio.bertocci=40auth0@dmarc.ietf.org" 
, 'George Fletcher' 
, 'Brian Campbell' 

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

This is another manifestation of the limits of jwks_uri that I’ve brought up on 
the list 
previously<https://mailarchive.ietf.org/arch/msg/oauth/eCZ-wUU2iwTyfx-zuqr2K3bM8-8/>.

Using different signing keys does not actually limit the blast radius of each 
key, since the validator doesn’t know that each key should only be considered 
valid for one type of token. This takes away one of the major drivers for using 
different keys. If the text says deployments can use different keys, it needs 
to clarify the limited value of that.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: OAuth  on behalf of 
"vittorio.bertocci=40auth0@dmarc.ietf.org" 

Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' , 'Brian Campbell' 

Cc: 'oauth' 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

That works for me!

From: George Fletcher 
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian Campbell' 

Cc: 'Brian Campbell' ; 'oauth' 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

If we don't want to give guidance on how the RS determines the correct key to 
use to validate the token, then maybe we should state that explicitly. "The 
mechanism used by the RS to determine the correct key to use to validate the 
access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com> wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.







From: Brian Campbell 
<mailto:bcampbell=40pingidentity@dmarc.ietf.org>

Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher <mailto:gffle...@aol.com>

Cc: Brian Campbell 
<mailto:bcampb...@pingidentity.com>; Vittorio 
Bertocci <mailto:vittorio.berto...@auth0.com>; 
oauth <mailto:oauth@ietf.org>

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







I don't think you are missing anything, George (except that, to be pedantic, 
`kid` is a header rather than a claim).







The question gave me pause, however, and makes me think that maybe the draft, 
with the aim of improved interoperability, should have some more explicit text 
about the use of the 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri.























On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org> 
<mailto:40aol@dmarc.ietf.org><mailto:40aol@dmarc.ietf.org> > wrote:



Can we not use the 'kid' claim to inform the RS as to which key is being used? 
What am I missing?



On 3/25/20 1:51 PM, Brian Campbell wrote:



I think, even without that statement in the draft, that ASes already have

license to use different keys if they so choose. And maybe I'm not creative

enough but I can't think of what problematic assumptions RSes might make

that would prevented by it. So perhaps just removing that whole 

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

[Vittorio Bertocci]

I think I am missing something here. It’s not that I don’t want to give 
guidance, is that it seems that the guidance you are thinking of isn’t 
necessary unless we think that enforcing explicitkey-token type assignment 
declaration is necessary. I didn’t get the impression that it was the proposal 
so far, what I have read was “if the intent was to prevent token 
confusion/substitution, this is insufficient”, to which the answer was “that 
was not the intent”.
And if preventing token substitution/confusion is not the aim, then the only 
guidance required here to the RS is “expect that any key published in the doc 
pointed by jwks_uri could be used to sign the AT” which seems actionable enough.
I do agree that the language could be more explicitly aimed at that outcome.. 
Would something to the effect of “The RS should expect the AS to use any of the 
keys published in the JWKS doc to sign JWT ATs” work better?

From: Brian Campbell 
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci 
Cc: George Fletcher , Brian Campbell 
, oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

It seems to me that leaving that out of scope is rather antithetical to the 
previously stated reason for the profile using only asymmetric signatures, 
namely that "this profile focuses on a solution that is as close to turnkey as 
possible for developers." And I'd suggest that, to borrow your words, looking 
at this from the useful guidance standpoint rather than the “lawyering up” 
perspective, some guidance on determining the correct key to use from the keys 
at the jwks_uri to verify the signature on the AT would be very useful in 
general and also prevent the kind of potential missteps you described. I mean, 
if nothing is said about it or even if it'd said to be out of scope, a working 
interoperable approach could probably be inferred by knowing and applying bits 
of JWS, JWA, JWK, etc.. But, to me anyway, it seems incongruent to expect folks 
to figure all that out but at the same time believe them capable of mistakes 
that would be prevented by only pointing out that ATs and ID tokens might be 
signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that 
kind of guidance in the Asymmetric bit of 
https://openid.net/specs/openid-connect-core-1_0.html#Signing and 
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's not 
perfect (this 
issue<https://bitbucket..org/openid/connect/issues/1161/key-rotation-should-require-a-delay>
 was raised just recently) but attempts to convey how verification key 
selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this one. 
And I've spent more time here than I'd like to admit so I won't argue it 
further.



On Wed, Mar 25, 2020 at 12:57 PM 
mailto:vittorio.berto...@auth0.com>> wrote:
That works for me!

From: George Fletcher mailto:gffle...@aol.com>>
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>; 'Brian 
Campbell' 
mailto:40pingidentity@dmarc.ietf.org>>
Cc: 'Brian Campbell' 
mailto:bcampb...@pingidentity.com>>; 'oauth' 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

If we don't want to give guidance on how the RS determines the correct key to 
use to validate the token, then maybe we should state that explicitly. "The 
mechanism used by the RS to determine the correct key to use to validate the 
access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?
On 3/25/20 2:44 PM, 
vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com> wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future..



Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it.. But if the 
consensus is that the sentence is confusing, I can also take it out.







Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in 

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

[Brian Campbell]

It seems to me that leaving that out of scope is rather antithetical to the
previously stated reason for the profile using only asymmetric signatures,
namely that "this profile focuses on a solution that is as close to turnkey
as possible for developers." And I'd suggest that, to borrow your words,
looking at this from the useful guidance standpoint rather than the
“lawyering up” perspective, some guidance on determining the correct key to
use from the keys at the jwks_uri to verify the signature on the AT would
be very useful in general and also prevent the kind of potential missteps
you described. I mean, if nothing is said about it or even if it'd said to
be out of scope, a working interoperable approach could probably be
inferred by knowing and applying bits of JWS, JWA, JWK, etc.. But, to me
anyway, it seems incongruent to expect folks to figure all that out but at
the same time believe them capable of mistakes that would be prevented by
only pointing out that ATs and ID tokens might be signed by different keys.

FWIW there's some ~8 year old text in OIDC that kinda attempts to give that
kind of guidance in the Asymmetric bit of
https://openid.net/specs/openid-connect-core-1_0.html#Signing and
https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys - it's
not perfect (this issue
<https://bitbucket.org/openid/connect/issues/1161/key-rotation-should-require-a-delay>
was raised just recently) but attempts to convey how verification key
selection is to be done and account for key rotation too.

This seems rather cut and dry to me but maybe I'm "in the weeds" on this
one. And I've spent more time here than I'd like to admit so I won't argue
it further.



On Wed, Mar 25, 2020 at 12:57 PM  wrote:

> That works for me!
>
>
>
> *From:* George Fletcher 
> *Sent:* Wednesday, March 25, 2020 11:56 AM
> *To:* vittorio.berto...@auth0.com; 'Brian Campbell'  40pingidentity@dmarc.ietf.org>
> *Cc:* 'Brian Campbell' ; 'oauth' <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> If we don't want to give guidance on how the RS determines the correct key
> to use to validate the token, then maybe we should state that explicitly.
> "The mechanism used by the RS to determine the correct key to use to
> validate the access token is out of scope for this specification".
>
> That way at least we are being very clear that the spec is not trying to
> specify how that happens.
>
> Thoughts?
>
> On 3/25/20 2:44 PM, vittorio.berto...@auth0.com wrote:
>
> Brian, there are plenty of ways in which an RS can surprise you with odd 
> behavior- for example, developers might see that you used a key for signing 
> an IDtoken and use that for init all their validation middleware for ATs as 
> well, say because the library only supports one key at a time, and then end 
> up failing at runtime when/if the assumption ceases to apply in the future.
>
>
>
> Would that be legitimate of them to take such a dependency, even without 
> warning text? No. However I am not looking at this from the “lawyering up” 
> perspective, but from the useful guidance standpoint as well. I am well aware 
> that being concise is a feature, but I am also not crazy about making every 
> specification into an intelligence test for the reader. If a 16 words 
> sentence can help prevent a likely misstep, I’d be inclined to keep it. But 
> if the consensus is that the sentence is confusing, I can also take it out.
>
>
>
>
>
> Brian & George, in the spirit of keeping things simple, and given that this 
> was more of a “just in case” warning rather than a security feature clamored 
> for- if the language is problematic I’d be more inclined to take the sentence 
> out rather than complicating the guidance further.
>
>
>
>
>
> From: Brian Campbell  
> 
>
> Sent: Wednesday, March 25, 2020 11:21 AM
>
> To: George Fletcher  
>
> Cc: Brian Campbell  ; 
> Vittorio Bertocci  
> ; oauth  
>
> Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2..0 
> Access Tokens"
>
>
>
>
>
> I don't think you are missing anything, George (except that, to be pedantic, 
> `kid` is a header rather than a claim).
>
>
>
>
>
> The question gave me pause, however, and makes me think that maybe the draft, 
> with the aim of improved interoperability, should have some more explicit 
> text about the use of the 'kid' header in a JWT AT and how it references the 
> verification key in the content at the jwks_uri.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
> mailto:40aol@dmarc.ietf.org> 
> <40a

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

[vittorio . bertocci=40auth0 . com]

That works for me!

 

From: George Fletcher  
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian Campbell' 

Cc: 'Brian Campbell' ; 'oauth' 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

If we don't want to give guidance on how the RS determines the correct key to 
use to validate the token, then maybe we should state that explicitly. "The 
mechanism used by the RS to determine the correct key to use to validate the 
access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to 
specify how that happens.

Thoughts?

On 3/25/20 2:44 PM, vittorio.berto...@auth0.com 
<mailto:vittorio.berto...@auth0.com>  wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future.
 
Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.
 
 
 
Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.
 
 
 
From: Brian Campbell  <mailto:bcampbell=40pingidentity@dmarc.ietf.org> 
 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher  <mailto:gffle...@aol.com> 
Cc: Brian Campbell  <mailto:bcampb...@pingidentity.com> 
; Vittorio Bertocci  
<mailto:vittorio.berto...@auth0.com> ; oauth  
<mailto:oauth@ietf.org> 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"
 
 
 
I don't think you are missing anything, George (except that, to be pedantic, 
`kid` is a header rather than a claim). 
 
 
 
The question gave me pause, however, and makes me think that maybe the draft, 
with the aim of improved interoperability, should have some more explicit text 
about the use of the 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri. 
 
 
 
 
 
 
 
 
 
 
 
On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org>   
<mailto:40aol@dmarc.ietf.org> <mailto:40aol@dmarc.ietf.org> > wrote:
 
Can we not use the 'kid' claim to inform the RS as to which key is being used? 
What am I missing?
 
On 3/25/20 1:51 PM, Brian Campbell wrote:
 
I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
 
On Wed, Mar 25, 2020 at 10:11 AM mailto:40auth0@dmarc.ietf.org>   
<mailto:40auth0@dmarc.ietf.org> <mailto:40auth0@dmarc.ietf.org> > wrote:
 
 
Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").
 
As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
 
 
 
*From:* Brian Campbell   <mailto:bcampbell=40pingidentity@dmarc.ietf.org> 
<mailto:bcampbell=40pingidentity@dmarc.ietf.org>  
<mailto:bcampbell=40pingidentity@dmarc.ietf.org> 

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci   <mailto:vittorio.berto...@auth0.com> 
<mailto:vittorio.berto...@auth0.com>  <mailto:vittorio.berto...@auth0.com> 

*Cc:* Richard Backman, Annabelle   <mailto:richa...@amazon.com> 
<mailto:richa...@amazon.com>  <mailto:richa...@amazon.com> 
; oauth <
oauth@ietf.org <mailto:oauth@ietf.org>   <mailto:oauth@ietf.org> 
<mailto:oauth@ietf.org> >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OA

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

[George Fletcher]

If we don't want to give guidance on how the RS determines the correct 
key to use to validate the token, then maybe we should state that 
explicitly. "The mechanism used by the RS to determine the correct key 
to use to validate the access token is out of scope for this specification".


That way at least we are being very clear that the spec is not trying to 
specify how that happens.


Thoughts?

On 3/25/20 2:44 PM, vittorio.berto...@auth0.com wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.

  


Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- if 
the language is problematic I’d be more inclined to take the sentence out rather 
than complicating the guidance further.

  


From: Brian Campbell 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher 
Cc: Brian Campbell ; Vittorio Bertocci 
; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens"

  


I don't think you are missing anything, George (except that, to be pedantic, 
`kid` is a header rather than a claim).

  


The question gave me pause, however, and makes me think that maybe the draft, 
with the aim of improved interoperability, should have some more explicit text 
about the use of the 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri.

  

  

  

  

  


On Wed, Mar 25, 2020 at 11:54 AM George Fletcher mailto:40aol@dmarc.ietf.org> > wrote:

Can we not use the 'kid' claim to inform the RS as to which key is being used? 
What am I missing?

On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
  
On Wed, Mar 25, 2020 at 10:11 AM 
40auth0@dmarc.ietf.org <mailto:40auth0@dmarc.ietf.org> > wrote:
  


Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").
  
As stated below, the intent wasn’t to prevent substitution/confusion, but

mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
  
  
  
*From:* Brian Campbell  <mailto:bcampbell=40pingidentity@dmarc.ietf.org> 

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci  <mailto:vittorio.berto...@auth0.com> 

*Cc:* Richard Backman, Annabelle  <mailto:richa...@amazon.com> 
; oauth <
oauth@ietf.org <mailto:oauth@ietf.org> >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
  
  
  
I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's

comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..
  
  
  
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
40auth0@dmarc.ietf.org <mailto:40auth0@dmarc.ietf.org> > wrote:
  
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with

different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
  
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they

all can be used for signing. What prevents the AS to use one key from that
list for

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

[vittorio . bertocci=40auth0 . com]

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.

 

Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- 
if the language is problematic I’d be more inclined to take the sentence out 
rather than complicating the guidance further.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher 
Cc: Brian Campbell ; Vittorio Bertocci 
; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

I don't think you are missing anything, George (except that, to be pedantic, 
`kid` is a header rather than a claim). 

 

The question gave me pause, however, and makes me think that maybe the draft, 
with the aim of improved interoperability, should have some more explicit text 
about the use of the 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri. 

 

 

 

 

 

On Wed, Mar 25, 2020 at 11:54 AM George Fletcher 
mailto:40aol@dmarc.ietf.org> > wrote:

Can we not use the 'kid' claim to inform the RS as to which key is being used? 
What am I missing?

On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
 
On Wed, Mar 25, 2020 at 10:11 AM mailto:40auth0@dmarc.ietf.org> > wrote:
 

Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").
 
As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
 
 
 
*From:* Brian Campbell  <mailto:bcampbell=40pingidentity@dmarc.ietf.org> 

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci  <mailto:vittorio.berto...@auth0.com> 

*Cc:* Richard Backman, Annabelle  <mailto:richa...@amazon.com> 
; oauth <
oauth@ietf.org <mailto:oauth@ietf.org> >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
 
 
 
I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..
 
 
 
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci mailto:40auth0@dmarc.ietf.org> > wrote:
 
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
 
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the

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

[Brian Campbell]

I don't think you are missing anything, George (except that, to be
pedantic, `kid` is a header rather than a claim).

The question gave me pause, however, and makes me think that maybe the
draft, with the aim of improved interoperability, should have some more
explicit text about the use of the 'kid' header in a JWT AT and how it
references the verification key in the content at the jwks_uri.





On Wed, Mar 25, 2020 at 11:54 AM George Fletcher  wrote:

> Can we not use the 'kid' claim to inform the RS as to which key is being
> used? What am I missing?
>
> On 3/25/20 1:51 PM, Brian Campbell wrote:
>
> I think, even without that statement in the draft, that ASes already have
> license to use different keys if they so choose. And maybe I'm not creative
> enough but I can't think of what problematic assumptions RSes might make
> that would prevented by it. So perhaps just removing that whole sentence,
> "An authorization server MAY elect to use different keys to sign id_tokens
> and JWT access tokens."? Just a thought anyway.
>
> On Wed, Mar 25, 2020 at 10:11 AM 
>  wrote:
>
>
> Thank you for the perspective- I guessed something similar (“there would
> be no way for the RS to know what key is used for what").
>
> As stated below, the intent wasn’t to prevent substitution/confusion, but
> mostly to give ASes license to use different keys if they choose to (for
> the reasons listed below, or any other reason they might have) and a
> headsup to RSes so that they don’t make assumptions.
>
>
>
> *From:* Brian Campbell  
> 
> *Sent:* Wednesday, March 25, 2020 8:48 AM
> *To:* Vittorio Bertocci  
> 
> *Cc:* Richard Backman, Annabelle  ; 
> oauth 
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
> comment was an assumption that signing ATs and ID Tokens with different
> keys would be done to prevent token substitution/confusion. And there's not
> really a practical way to achieve that with the mechanics of the jwks_uri...
>
>
>
> On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
>  wrote:
>
> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>
>
>
>
>
>
> *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.*
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
bcampb...@pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https:

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

[George Fletcher]

Can we not use the 'kid' claim to inform the RS as to which key is being 
used? What am I missing?


On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM  wrote:


Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").

As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.



*From:* Brian Campbell 
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci 
*Cc:* Richard Backman, Annabelle ; oauth <
oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"



I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..



On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*

Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the validation
section. That doesn’t mean this is useless, an AS might elect to use
different keys for its own purposes (eg separation of concerns for
forensics, different strengths, different lifecycles, and so on).






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




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM  wrote:

> Thank you for the perspective- I guessed something similar (“there would
> be no way for the RS to know what key is used for what").
>
> As stated below, the intent wasn’t to prevent substitution/confusion, but
> mostly to give ASes license to use different keys if they choose to (for
> the reasons listed below, or any other reason they might have) and a
> headsup to RSes so that they don’t make assumptions.
>
>
>
> *From:* Brian Campbell 
> *Sent:* Wednesday, March 25, 2020 8:48 AM
> *To:* Vittorio Bertocci 
> *Cc:* Richard Backman, Annabelle ; oauth <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
> comment was an assumption that signing ATs and ID Tokens with different
> keys would be done to prevent token substitution/confusion. And there's not
> really a practical way to achieve that with the mechanics of the jwks_uri..
>
>
>
> On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>
>
>
>
>
>
> *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.*
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
bcampb...@pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66=gmail=1541693608526000=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html>
*If you’re not a current customer, click here
<https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_s

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

[vittorio . bertocci=40auth0 . com]

Thank you for the perspective- I guessed something similar (“there would be no 
way for the RS to know what key is used for what").

As stated below, the intent wasn’t to prevent substitution/confusion, but 
mostly to give ASes license to use different keys if they choose to (for the 
reasons listed below, or any other reason they might have) and a headsup to 
RSes so that they don’t make assumptions.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 8:48 AM
To: Vittorio Bertocci 
Cc: Richard Backman, Annabelle ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's 
comment was an assumption that signing ATs and ID Tokens with different keys 
would be done to prevent token substitution/confusion. And there's not really a 
practical way to achieve that with the mechanics of the jwks_uri. 

 

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org> > wrote:

>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with 
>different keys is to publish the keys in two different JWK sets. This only way 
>to do this today is by publishing separate OAuth 2.0 authorization server 
>metadata and OIDC Discovery metadata files, where the JWK set in the former 
>applies to access tokens and the JWK set in the latter applies to ID Tokens.

Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they all 
can be used for signing. What prevents the AS to use one key from that list for 
IDtokens and another for ATs? Separate discovery docs shouldn’t be necessary. 
Sure, there would be no way for the RS to know what key is used for what- but 
similar mechanisms are already in place today for handling signing key 
rotation: e.g. the discovery doc lists the current key and the future key, but 
uses only the current- and the RS has no way of distinguishing between the two. 
The situation here can be analogous, any key in the discovery doc should be 
considered valid by the RS, and in fact there’s no requirement about selecting 
specific keys in the validation section. That doesn’t mean this is useless, an 
AS might elect to use different keys for its own purposes (eg separation of 
concerns for forensics, different strengths, different lifecycles, and so on).

 

 


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.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[vittorio . bertocci=40auth0 . com]

Fair. I went back to the aggregated research rather than the individual emails 
and I did find those samples from you- thanks for pointing this out. 
Nonetheless, I don’t think this changes the main argument. Symmetric isn’t 
disallowed, it just cannot give a complete end to end solution that would 
increase the likelihood prompt interoperability out of the box, hence it seems 
meaningful to recommend it in an interop profile.

 

From: Brian Campbell  
Sent: Wednesday, March 25, 2020 8:10 AM
To: Vittorio Bertocci 
Cc: Richard Backman, Annabelle ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

 

 

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org> > wrote:

>4 p1: Saying asymmetric signatures are RECOMMENDED presupposes that key 
>distribution is the implementer’s primary concern. MAC-based implementations 
>shouldn’t be seen as some weird edge case scenario (though it’d be worth 
>including some Security Considerations text calling out the key distribution 
>challenges when dealing with loosely coupled ASes and RSes).

In the spirit of achieving the simplest, most actionable core interop profile, 
with as little left as exercise to the reader as possible, I would prefer to 
keep symmetric keys out of scope. 

Although you are right that MAC-based implementations have a role to play in 
the OAuth2 ecosystem, key distribution is a problem left to the developer to 
solve; and all the sample JWTs ATs I got from the providers I worked with were 
signed with discoverable keys.

Again, that doesn’t mean that MAC-based implementations shoulnd’t be used: only 
that this profile focuses on a solution that is as close to turnkey as possible 
for developers, and that requests as little delta as possible to providers 
already using JWT for their ATs.

 

I'm not trying to re-litigate the decision or question consensus but I will ask 
that you don't use the justification that "all the sample JWTs ATs I got from 
the providers I worked with were signed with discoverable keys" because I 
explicitly included several example JWT ATs in the samples that I provided that 
were using AEAD symmetric encryption, which is similar to MAC-based but with 
the added benefit of confidentiality of the claims payload. 

 

See also 
https://mailarchive.ietf.org/arch/msg/oauth/DAFccKDPJRhA5Z-vLIrx7u5XU4Q/

 

 


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.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri.

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

> *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
> different keys is to publish the keys in two different JWK sets. This only
> way to do this today is by publishing separate OAuth 2.0 authorization
> server metadata and OIDC Discovery metadata files, where the JWK set in the
> former applies to access tokens and the JWK set in the latter applies to ID
> Tokens.*
>
> Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
> all can be used for signing. What prevents the AS to use one key from that
> list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
> necessary. Sure, there would be no way for the RS to know what key is used
> for what- but similar mechanisms are already in place today for handling
> signing key rotation: e.g. the discovery doc lists the current key and the
> future key, but uses only the current- and the RS has no way of
> distinguishing between the two. The situation here can be analogous, any
> key in the discovery doc should be considered valid by the RS, and in fact
> there’s no requirement about selecting specific keys in the validation
> section. That doesn’t mean this is useless, an AS might elect to use
> different keys for its own purposes (eg separation of concerns for
> forensics, different strengths, different lifecycles, and so on).
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

> *>4 p1: Saying asymmetric signatures are RECOMMENDED presupposes that key
> distribution is the implementer’s primary concern. MAC-based
> implementations shouldn’t be seen as some weird edge case scenario (though
> it’d be worth including some Security Considerations text calling out the
> key distribution challenges when dealing with loosely coupled ASes and
> RSes).*
>
> In the spirit of achieving the simplest, most actionable core interop
> profile, with as little left as exercise to the reader as possible, I would
> prefer to keep symmetric keys out of scope.
>
> Although you are right that MAC-based implementations have a role to play
> in the OAuth2 ecosystem, key distribution is a problem left to the
> developer to solve; and all* the sample JWTs ATs I got from the providers
> I worked with were signed with discoverable keys.*
>
> Again, that doesn’t mean that MAC-based implementations shoulnd’t be used:
> only that this profile focuses on a solution that is as close to turnkey as
> possible for developers, and that requests as little delta as possible to
> providers already using JWT for their ATs.
>

I'm not trying to re-litigate the decision or question consensus but I will
ask that you don't use the justification that "all the sample JWTs ATs I
got from the providers I worked with were signed with discoverable keys"
because I explicitly included several example JWT ATs in the samples that I
provided that were using AEAD symmetric encryption, which is similar to
MAC-based but with the added benefit of confidentiality of the claims
payload.

See also
https://mailarchive.ietf.org/arch/msg/oauth/DAFccKDPJRhA5Z-vLIrx7u5XU4Q/

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertocci]

the claims defined in…”.
Likewise for §2.2.3.1 p2 and SCIM Core.
Similar to the above. Technically you are absolutely right, however OIDC, token 
introspection and SCIM are associated to specific functionality and topics that 
can help the reader frame the intent, whereas the JWT Claims registry contains 
a lot of stuff without scoping things further or hinting at similarities of 
intent. Same question as above: do you see harm in keeping the reference sin 
the current form?
>§2.2.2 p4: This should reference Sections 4.2 and 4.3 of RFC 7519, which 
>provide the requirements for Public and Private Claim Names.
Great catch. Added.
>§3 p2: This paragraph is redundant and should be removed.
Good point. Removed.
>§4 p4: We should call out the checks that are necessary from a security 
>perspective, but we should not mandate a specific order except where there are 
>dependencies. Step 7 in the list is redundant with the paragraph that follows, 
>and should be removed.
I believe the order (lifted from OIDC for the most part) does have some 
consideration (e.g signature check should be done as late as possible to make 
DoS harder, as preceding checks are computationally lighter and their failure 
might spare the RS from a heavier hit) but I don’t recall exactly, I’ll do some 
research in the morning and come back on this.
On step 7 (auth_time validation) being redundant: again, technically correct, 
this can be implied- but hinting at intended usage (especially with the 
discussions about that particular claim) seems prudent. How strongly do you 
feel about removing that step?

Knits: will sweep thru them tomorrow and apply to the text accordingly. THANK 
YOU!




From: OAuth  on behalf of "Richard Backman, Annabelle" 

Date: Tuesday, March 24, 2020 at 15:45
To: 'oauth' 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

Thanks for working on this, Vittorio! This is important work and I’m glad to 
see it moving forward.

I have thoughts on the “aud” and “scope” language, but I will share those 
separately, on your thread with George.

Discussion Topics:

  1.  §4 p1: Saying asymmetric signatures are RECOMMENDED presupposes that key 
distribution is the implementer’s primary concern. MAC-based implementations 
shouldn’t be seen as some weird edge case scenario (though it’d be worth 
including some Security Considerations text calling out the key distribution 
challenges when dealing with loosely coupled ASes and RSes).
  2.  §4 p3: The only practical way for the AS to sign ATs and ID Tokens with 
different keys is to publish the keys in two different JWK sets. This only way 
to do this today is by publishing separate OAuth 2.0 authorization server 
metadata and OIDC Discovery metadata files, where the JWK set in the former 
applies to access tokens and the JWK set in the latter applies to ID Tokens. If 
this is the intent, we need to clearly explain this. If not, we need to provide 
a way for the AS to tell the RS which key(s) to use for ATs, or acknowledge 
that the AS can’t.

Minor Suggestions:

  1.  §2.1 p3: This should be reworded to describe the usage of the 
“application/at+jwt” media type for the “typ” header parameter. See Section 2.3 
of RFC 8417<https://tools.ietf.org/html/rfc8417#section-2.3> for how this was 
worded for SETs.
  2.  §2.2: All the JWT claims defined in RFC 7519 are fair game, so there is 
no need to explicitly call out “iat” and “jti” unless you want to change their 
OPTIONAL status to something else. I’d be in favor of making them REQUIRED, as 
they are highly valuable and including them represents a negligible burden on 
the AS.

Also, given the confusion around the meaning of “auth_time”, it might be worth 
calling out that as per definition in 7519, “iat” is the issue time for the 
access token itself, not for the session or anything else.
  3.  §2.2.1: With the addition of the clarifying paragraph in this section, 
you can do away with the additional descriptions on “auth_time”, “acr”, and 
“amr”. Just reference OIDC, i.e., drop everything after “as defined in section 
2 of 
[OpenID.Core<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#ref-OpenID.Core>].”
  4.  §2.2.2 p3: Instead of specifically referencing OIDC and Token 
Introspection, maybe just say implementers SHOULD use claims defined in the JWT 
Claims Registry when appropriate? We could retain the references as examples, 
e.g., “such as the claims defined in…”.

 *   Likewise for §2.2.3.1 p2 and SCIM Core.

  1.  §2.2.2 p4: This should reference Sections 4.2 and 4.3 of RFC 7519, which 
provide the requirements for Public and Private Claim Names.
  2.  §3 p2: This paragraph is redundant and should be removed.
  3.  §4 p4: We should call out the checks that are necessary from a security 
perspective, but we should not mandate a specific order except where there are 
dependencies. Step 7 in the list is redundant wit

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

[Richard Backman, Annabelle]

To borrow a term from ML, I think the "aud", "scope", and resource 
indicator-related text is overfitted to a specific set of deployment scenarios, 
and a specific way of using scopes and resource indicators.

Consider the following:

1. There may be no "scope" parameter
The "scope" parameter is OPTIONAL in authorization requests. So an AS/RS 
operator could decide they're going to omit "scope" entirely and use multiple 
resource parameters instead. Since there are no scopes, there is no opportunity 
for confusion. In this case, a JWT AT with a multi-valued "aud" claim and no 
"scope" claim would seem appropriate. While multiple resource indicators could 
be pushed into a single scope string, this introduces opportunities for serious 
security impacting encoding/decoding/parsing bugs. The more I think about it, 
the more "I don't have to deal with parsing a scope string" seems like a 
compelling reason to go this route... __

2. The scopes may apply to all audiences
An AS/RS operator may use "scope" to indicate a role or policy (or set of 
policies) that the client wants, and allow the client to narrow their 
permissions using "resource" parameters. This would allow the client to obtain 
narrowly scoped access tokens for specific use cases without needing to define 
separate roles/policies for each. In this case, a JWT AT with a multi-valued 
"aud" claim and a "scope" claim would seem appropriate, as the scope claim is 
intended to apply to all of the audience values.

3. The mapping between audience and scope may be unambiguous
There are a lot of deployments to which the blast radius risk you're trying to 
address by requiring "aud" simply does not apply. It may seem innocuous to 
require these deployments to explicitly include a broad audience like 
"api.example.com" anyway, that can lead to implementers ignoring the 
requirement (leading to interop issues), not validating it (also leading to 
interop issues or security issues if the deployment wants to start actually 
using it for real), or doing something funky with it since there isn't anything 
"real" that the value needs to conform to. 

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocci" 
 wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



Thanks George for the super thorough review and feedback!
Inline

  >  Section 1. Introduction
 ��� second line: scenario should be plural --> scenarios
 ��� second sentence: "are not ran by" --> "are not run by"
�� cofidentiality --> confidentiality
Fixed. Thanks!

> Section 2.2.1 Authentication Information Claims
 ��� I'm not sure that this definition of `auth_time` allows for the
case where a user is required to solve an additional challenge.
If the challenge entails going back to the AS, then I believe the language (in 
the initial paragraph of 2.2.1 and in auth_time itself)  accommodates for that 
and does require the auth_time to be updated.
If you hit the AS and present an authentication factor (such as your challenge) 
and obtain a new token in the process, the auth_time will reflect the time of 
your latest authentication just like an id_token would in the same 
circumstances (think protected route in a web app requiring step up auth) and 
(likely) associated session artifacts (think RTs or cookies with sliding 
expiration, the challenge would count as activity and move the expiration).

> ��� I think there is a difference between session_start_time and 
> last
auth_time. This feels more like it's defining the session_start_time
concept.
>�� These same issues can apply to the `acr` and `amr` values as well.
Per the above, the intent is more to express the last time the user performed 
any authentication action rather than the start time. The intent is to provide 
information as current as possible, as it might be relevant to the RS decisions 
whereas the history before current conditions might not be consequential.

  >   �� Even if for this secondary challenge a new refresh_token is issued,
it is unlikely many relying parties will want to treat that as issuing a
new session. The goal is to keep the user logged in to a single session.
Could you expand on the practical implications of the above? The intent isn't 
as much to reflect session identifying information per se, but to provide the 
RS with the most up to date information about the circumstances in which the 
current AT was obtained. The fact that a session was initially established 
using acr level 0 doesn’t really matter if the AT I am receiving now has been 
obtained after a stepup that brought acr to 1, if my RS cares auth 
authentication levels my authorization decision shouldn't be influenced by 
whether somewhere the session artifact didn’t 

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

[Vittorio Bertocci]

Thanks Nikos!
You are right that the goals of the two specs are different; however the 
current spec reflects in large part both what was observed in the proprietary 
JWT ATs in existing systems (hence making interop more likely/meeting a need 
that seems widespread) and the current practice of abusing id_tokens for 
calling API. People do that because their API do leverage the info in the 
id_token, and include those info in their custom use of JWT for ATs for the 
same reason. If you add to this the fact that a lot of popular libraries would 
actually not validate the token if it would not comply with the validation 
requirements in OIDC, I think we can conclude there’s value in specifying those 
settings are requirements for successful interop.

From: Nikos Fotiou 
Date: Tuesday, March 24, 2020 at 13:55
To: 'Vittorio Bertocci' 
Cc: 'Hannes Tschofenig' , 'oauth' 
Subject: RE: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

Just a general comment, OIDC has been designed for a specific reason (“identity 
layer on top of the OAuth 2.0”) whereas JWT access tokens are used for more 
applications. Since the goal of this specification is to “provide a 
standardized and interoperable profile as an alternative to the proprietary JWT 
access tokens layout”,  I feel it is restrictive.

Best,
Nikos

From: Vittorio Bertocci 
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou 
Cc: Hannes Tschofenig ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

Hi Nikos,
thanks for taking the time to review and write down your feedback!
Inline

- In Section 2.2 why nbf claim 
(https://tools..ietf.org/html/rfc7519#section-4.1.5)<https://tools.ietf.org/html/rfc7519#section-4.1.5)>
 is not considered? I can imagine some interesting applications of this claim.
The validation rules are partly following the ones defined in OpenID Connect, 
given that a lot of in market deployments reuse some low level JWT validation 
components.

  - In the same section, it is not clear why some claims are required, 
especially exp, sub, and client_id. The last two claims are not even used 
during token validation.
 Being this an interop profile, it reflects the information commonly found in 
many existing JWT based access tokens solutions in the wild. Both sub and 
client_id provide information that proved to be useful to RSes and 
SDKs/middlewares, hence guaranteeing their presence will help creating reusable 
libraries with broader applicability. The AS has ready access to that info, and 
there are no obvious security reasons for omitting them. Also, sub and exp are 
both required in OIDC, and clientID is available via aud (also required) - 
hence requiring their presence helps developers to reuse existing validation 
logic to at least some extent.

  - RFC7519 specifies that, in the general case, the aud claim is an array of 
StringOrURI values. In this draft it is not clear if this still the case, or 
here aud is a simple string (e.g., in page 5 it is stated: the resource 
indicated in the aud claim, rather than the resource*s*).
For simplicity, and above all for avoiding ambiguity in evaluating to what 
resource the granted scopes should be applied to, the idea would be to restrict 
to a single string.

  - In the token validation procedure, i.e., Section 4, is there any reason why 
the resource server first checks the aud claim, then the signature, and finally 
the exp claim? Given the fact that Error responses are not specified, returning 
something like “invalid aud claim” even for tokens with invalid signature may 
result in privacy/security attacks.
 The sequence of those checks follows 
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.  As 
OIDC doesn't define error responses nor call this aspect out in the security 
considerations, I largely relied on this being mainstream.

  - IMHO The token validation procedure it too bound to the particular 
discovery mechanisms mentioned at the beginning of this section. E.g., Step 2 
mentions a “registration” process, and Step 3 mentions and an “Issuer 
Identifier” which must much the iss claim. Moreover, I think it should be 
explicitly mentioned that the resource server “must validate that the JWT 
access token has been singed with a signing key that corresponds to the 
authorization server included in the iss claim”
As per the other points, the language follows closely OIDC.
The step does contain the phrase "The resource server MUST use the keys 
provided by the authorization server." Do you feel the language should be more 
explicit? The document doesn't specify any other mechanism for acquiring keys, 
hence it shouldn't be too ambiguous... but we can always tighten it up..


On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou 
mailto:fot...@aueb.gr>> wrote:
Hi all,

Allow me some comments and forgive me if some of them are naïve.
- In Section 2.2 wh

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

[Vittorio Bertocci]

Thanks George for the super thorough review and feedback! 
Inline

  >  Section 1. Introduction
 ��� second line: scenario should be plural --> scenarios
 ��� second sentence: "are not ran by" --> "are not run by"
�� cofidentiality --> confidentiality
Fixed. Thanks!

> Section 2.2.1 Authentication Information Claims
 ��� I'm not sure that this definition of `auth_time` allows for the 
case where a user is required to solve an additional challenge.
If the challenge entails going back to the AS, then I believe the language (in 
the initial paragraph of 2.2.1 and in auth_time itself)  accommodates for that 
and does require the auth_time to be updated. 
If you hit the AS and present an authentication factor (such as your challenge) 
and obtain a new token in the process, the auth_time will reflect the time of 
your latest authentication just like an id_token would in the same 
circumstances (think protected route in a web app requiring step up auth) and 
(likely) associated session artifacts (think RTs or cookies with sliding 
expiration, the challenge would count as activity and move the expiration).

> ��� I think there is a difference between session_start_time and 
> last 
auth_time. This feels more like it's defining the session_start_time 
concept.
>�� These same issues can apply to the `acr` and `amr` values as well.
Per the above, the intent is more to express the last time the user performed 
any authentication action rather than the start time. The intent is to provide 
information as current as possible, as it might be relevant to the RS decisions 
whereas the history before current conditions might not be consequential.

  >   �� Even if for this secondary challenge a new refresh_token is 
issued, 
it is unlikely many relying parties will want to treat that as issuing a 
new session. The goal is to keep the user logged in to a single session.
Could you expand on the practical implications of the above? The intent isn't 
as much to reflect session identifying information per se, but to provide the 
RS with the most up to date information about the circumstances in which the 
current AT was obtained. The fact that a session was initially established 
using acr level 0 doesn’t really matter if the AT I am receiving now has been 
obtained after a stepup that brought acr to 1, if my RS cares auth 
authentication levels my authorization decision shouldn't be influenced by 
whether somewhere the session artifact didn’t change its sessionID after the 
stepup. Same for acr, auth_time

> Section 2.2.3 Authorization Claims
 �� I find the statement "All the individual scope strings in the scope 
claim MUST have meaning for the resource indicated in the aud claim" 
somewhat problematic. In many deployments today for 1st party clients to 
the authorization server and taking into account mobile applications, 
the access token most like contains scopes for many of the 1st party 
backend APIs. It's possible to get around this by setting the 'aud' 
claim to something like "com.example.apis" and hence all the issued 
scopes map to that audience claim but that is just working around the 
MUST in the spec. Given the lack of specificity of the 'aud' claim and 
the 'resource indicator' claim for that matter, pretty much anything can 
be made to comply. In that context, it seems like RECOMMEND is a better 
normative clause.
For 1st party solutions, I would argue that delegation might not be the right 
primitive hence I wouldn't necessarily use scopes to express permissions; but 
that's a rabbit hole I'll try to avoid for the time being __
For the aud, I think that what you characterized as workaround would actually 
be by design. The aud defines the applicability of the current token, so that 
in case of leakage the blast radius of the incident can be contained. If the 
solution designed decides that this particular token should be reusable across 
multiple assets, I think it makes sense for the aud to reflect that explicitly. 
That's the system designing volunteering a scope xpansion of the scope, and 
given that it has security implications I think it's good to require it to be 
an explicit, opt in action. At the same time, given that scopes are often used 
to define permissions, I believe it makes sense to find mechanisms to minimize 
the chance that RSes would misinterpret the applicability of a scope (see 
discussion with Takahiko/Nikos). Summing all the above, I'd be inclined to keep 
the MUST.

> Section 3. Requesting a JWT Access Token
 �� Per my comments above I suspect that requiring all JWT access 
tokens 
to include an audience claim will just devolve to audience claims that 
are somewhat pointless (in order to meet this MUST in the spec). Given 
the mobile app environment today, it is unreasonable to ask the mobile 
apps to downscope every access 

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

[Nikos Fotiou]

Just a general comment, OIDC has been designed for a specific reason (“identity 
layer on top of the OAuth 2.0”) whereas JWT access tokens are used for more 
applications. Since the goal of this specification is to “provide a 
standardized and interoperable profile as an alternative to the proprietary JWT 
access tokens layout”,  I feel it is restrictive.

 

Best,

Nikos 

 

From: Vittorio Bertocci  
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou 
Cc: Hannes Tschofenig ; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

 

Hi Nikos,

thanks for taking the time to review and write down your feedback!

Inline

 

- In Section 2.2 why nbf claim 
(https://tools..ietf.org/html/rfc7519#section-4.1.5) 
<https://tools.ietf.org/html/rfc7519#section-4.1.5)>  is not considered? I can 
imagine some interesting applications of this claim.  

The validation rules are partly following the ones defined in OpenID Connect, 
given that a lot of in market deployments reuse some low level JWT validation 
components.

 

  - In the same section, it is not clear why some claims are required, 
especially exp, sub, and client_id. The last two claims are not even used 
during token validation. 

 Being this an interop profile, it reflects the information commonly found in 
many existing JWT based access tokens solutions in the wild. Both sub and 
client_id provide information that proved to be useful to RSes and 
SDKs/middlewares, hence guaranteeing their presence will help creating reusable 
libraries with broader applicability. The AS has ready access to that info, and 
there are no obvious security reasons for omitting them. Also, sub and exp are 
both required in OIDC, and clientID is available via aud (also required) - 
hence requiring their presence helps developers to reuse existing validation 
logic to at least some extent.

 

  - RFC7519 specifies that, in the general case, the aud claim is an array of 
StringOrURI values. In this draft it is not clear if this still the case, or 
here aud is a simple string (e.g., in page 5 it is stated: the resource 
indicated in the aud claim, rather than the resource*s*).  

For simplicity, and above all for avoiding ambiguity in evaluating to what 
resource the granted scopes should be applied to, the idea would be to restrict 
to a single string.

 

  - In the token validation procedure, i.e., Section 4, is there any reason why 
the resource server first checks the aud claim, then the signature, and finally 
the exp claim? Given the fact that Error responses are not specified, returning 
something like “invalid aud claim” even for tokens with invalid signature may 
result in privacy/security attacks. 

 The sequence of those checks follows 
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.  As 
OIDC doesn't define error responses nor call this aspect out in the security 
considerations, I largely relied on this being mainstream.

 

  - IMHO The token validation procedure it too bound to the particular 
discovery mechanisms mentioned at the beginning of this section. E.g., Step 2 
mentions a “registration” process, and Step 3 mentions and an “Issuer 
Identifier” which must much the iss claim. Moreover, I think it should be 
explicitly mentioned that the resource server “must validate that the JWT 
access token has been singed with a signing key that corresponds to the 
authorization server included in the iss claim”

As per the other points, the language follows closely OIDC. 

The step does contain the phrase "The resource server MUST use the keys 
provided by the authorization server." Do you feel the language should be more 
explicit? The document doesn't specify any other mechanism for acquiring keys, 
hence it shouldn't be too ambiguous... but we can always tighten it up.

 

 

On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou mailto:fot...@aueb.gr> > wrote:

Hi all,

 

Allow me some comments and forgive me if some of them are naïve.

- In Section 2.2 why nbf claim 
(https://tools..ietf.org/html/rfc7519#section-4.1.5) 
<https://tools.ietf.org/html/rfc7519#section-4.1.5)>  is not considered? I can 
imagine some interesting applications of this claim.

- In the same section, it is not clear why some claims are required, especially 
exp, sub, and client_id. The last two claims are not even used during token 
validation.

- RFC7519 specifies that, in the general case, the aud claim is an array of 
StringOrURI values. In this draft it is not clear if this still the case, or 
here aud is a simple string (e.g., in page 5 it is stated: the resource 
indicated in the aud claim, rather than the resource*s*).

- In the token validation procedure, i.e., Section 4, is there any reason why 
the resource server first checks the aud claim, then the signature, and finally 
the exp claim? Given the fact that Error responses are not specified, returning 
something li

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

[George Fletcher]

I think one of the problems we have in being super specific about how 
the JWT access token is constructed is that is means it's not possible 
for many organizations to follow. How scopes are implemented is very 
varied across deployments which means that some may conform to the 
perspective of the spec and many may not.


Personally, I'm not a big fan of trying to use scopes for fine-grain 
authorization. I don't think that is what they were intended for when 
originally designed. (This can be seen by the RAR spec introducing a 
completely different way of specifying fine-grain authorization 
context.) Even in multi-tenant systems, I don't see issues with using 
sub-resource scopes as each tenant should define the scopes that make 
sense for that tenant. I don't think the AS needs to understand the 
scopes, just provide a mechanism to issue the correct scope under user 
consent to the client and let the RS apply the authorization policy when 
it gets the scopes out of the token.


I'll wait for your response to my other feedback :)

On 3/24/20 3:07 PM, Vittorio Bertocci wrote:

You are too fast  I am still replying to your other comments! 
Yes, it is possible for resource servers to define sub-resource specific 
scopes, but it cannot be mandated- and it can be extremely problematic when 
your AS is multitenant. The resource identifier in those scenarios can be a 
LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 
1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, 
provisioning and even bandwidth use standpoints. I have experienced this 
firsthand when Azure AD moved from v1 style resource identification (where 
resource was a mandatory request param) to v2, where the resource was inferred 
from the scopes via scopes stuffing.

From: OAuth  on behalf of George Fletcher 

Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci , Takahiko Kawasaki 

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

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values (e.g. 
'read', 'write', 'delete'). It is very possible that in the context of a 
calendar services and an inbox service... the system defines scopes like 
'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity.
On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

   I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for

resource servers. In other words, if "aud" is determined based on the

"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS

is facading a collection of existing finer grained resources, scopes

representing permissions might be ambiguous - if my API facades both

calendar and inbox, what does the "read" scope refer to? Having an audience

resolves that ambiguity.




--
Identity Standards Architect
Verizon Media Work: george.fletc...@oath.com
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertocci]

You are too fast  I am still replying to your other comments! 
Yes, it is possible for resource servers to define sub-resource specific 
scopes, but it cannot be mandated- and it can be extremely problematic when 
your AS is multitenant. The resource identifier in those scenarios can be a 
LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 
1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, 
provisioning and even bandwidth use standpoints. I have experienced this 
firsthand when Azure AD moved from v1 style resource identification (where 
resource was a mandatory request param) to v2, where the resource was inferred 
from the scopes via scopes stuffing.

From: OAuth  on behalf of George Fletcher 

Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci , Takahiko Kawasaki 

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

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values (e.g. 
'read', 'write', 'delete'). It is very possible that in the context of a 
calendar services and an inbox service... the system defines scopes like 
'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity.
On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

  I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for

resource servers. In other words, if "aud" is determined based on the

"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS

is facading a collection of existing finer grained resources, scopes

representing permissions might be ambiguous - if my API facades both

calendar and inbox, what does the "read" scope refer to? Having an audience

resolves that ambiguity.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values 
(e.g. 'read', 'write', 'delete'). It is very possible that in the 
context of a calendar services and an inbox service... the system 
defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' in which there 
is no ambiguity.


On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

   I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for
resource servers. In other words, if "aud" is determined based on the
"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS
is facading a collection of existing finer grained resources, scopes
representing permissions might be ambiguous - if my API facades both
calendar and inbox, what does the "read" scope refer to? Having an audience
resolves that ambiguity.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertocci]

Hi Takahiko,
thank you for reviewing and taking the time to write down your feedback!
Inline

[..]  apparently conflicts with RFC 8707. I'm afraid vendors that support
> RFC 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.

I don't think this can be characterized as conflict. As a profile, it is
expected that this spec will be more restrictive. As long as a token
complying with the profile requirements is also valid according to 8707, I
believe we are in valid territory even if the vice versa does not hold (eg
a token can comply with 8707 but not be well formed according to a profile)..

  The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible.

Could you expand on the specific points you find unclear?

  I don't think the rule referring to the "scope" parameter is worth being
> defined. That "aud" is missing but "scope" is available is enough for
> resource servers. In other words, if "aud" is determined based on the
> "scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS
is facading a collection of existing finer grained resources, scopes
representing permissions might be ambiguous - if my API facades both
calendar and inbox, what does the "read" scope refer to? Having an audience
resolves that ambiguity.
Also, many AS operate as multitenant services, where the need to solve
resource references ambiguity is even greater; and plenty of real world 1st
party solutions use OAuth for calling their first party API, without
implementing delegated authz logic hence not using scopes directly.
Also, see the next point.

  Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".

The most widespread JWT token validation logic deployed today is repurposed
from OIDC, where aud is mandatory. Most of the JWT AT solutions in the wild
use it. I believe that's enough reason to mandate aud in an interop profile..

On Mon, Mar 23, 2020 at 11:47 PM Takahiko Kawasaki 
wrote:

> (1)
> The requirement in the paragraph below excerpted from "3. Requesting a JWT
> Access Token":
>
> *If it receives a request for an access token containing more than one
> resource parameter, an authorization server issuing JWT access tokens MUST
> reject the request and fail with "invalid_request" as described in section
> 4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
> [RFC8707].  See Section 2.2 and Section 5 for more details on how this
> measure ensures there's no confusion on to what resource the access token
> granted scopes apply.*
>
>
> apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
> 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.
>
> (2)
> Regarding another paragraph shown below from the same section.
>
> *If the request does not include a resource parameter, the authorization
> server MUST use in the aud claim a default resource indicator.  If a scope
> parameter is present in the request, the authorization server SHOULD use it
> to infer the value of the default resource indicator to be used in the aud
> claim.  The mechanism through which scopes are associated to default
> resource indicator values is outside the scope of this specification.  If
> the values in the scope parameter refer to different default resource
> indicator values, the authorization server SHOULD reject the request with
> invalid_scope as described in section 4.1.2.1 of [RFC6749].*
>
>
> The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible. In addition, I don't think the rule
> referring to the "scope" parameter is worth being defined. That "aud" is
> missing but "scope" is available is enough for resource servers. In other
> words, if "aud" is determined based on the "scope", why do we have to set
> "aud" redundantly?
>
> Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".
>
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou  wrote:
>
>> Hi all,
>>
>>
>>
>> Allow me some comments and forgive me if some of them are naïve.
>>
>> - In Section 2.2 why nbf claim (
>> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>>  is not considered?
>> I can imagine some interesting applications of this claim.
>>
>> - In the same section, it is not clear why some claims are required,
>> especially exp, sub, and client_id. The last two claims are not even used
>> 

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

[Vittorio Bertocci]

Hi Nikos,
thanks for taking the time to review and write down your feedback!
Inline

- In Section 2.2 why nbf claim (
> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>  is not considered? I
> can imagine some interesting applications of this claim.

The validation rules are partly following the ones defined in OpenID
Connect, given that a lot of in market deployments reuse some low level JWT
validation components.

  - In the same section, it is not clear why some claims are required,
> especially exp, sub, and client_id. The last two claims are not even used
> during token validation.

 Being this an interop profile, it reflects the information commonly found
in many existing JWT based access tokens solutions in the wild. Both sub
and client_id provide information that proved to be useful to RSes and
SDKs/middlewares, hence guaranteeing their presence will help creating
reusable libraries with broader applicability. The AS has ready access to
that info, and there are no obvious security reasons for omitting them.
Also, sub and exp are both required in OIDC, and clientID is available via
aud (also required) - hence requiring their presence helps developers to
reuse existing validation logic to at least some extent.

  - RFC7519 specifies that, in the general case, the aud claim is an array
> of StringOrURI values. In this draft it is not clear if this still the
> case, or here aud is a simple string (e.g., in page 5 it is stated: the
> resource indicated in the aud claim, rather than the resource*s*).

For simplicity, and above all for avoiding ambiguity in evaluating to what
resource the granted scopes should be applied to, the idea would be to
restrict to a single string.

  - In the token validation procedure, i.e., Section 4, is there any reason
> why the resource server first checks the aud claim, then the signature, and
> finally the exp claim? Given the fact that Error responses are not
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.

 The sequence of those checks follows
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.  As
OIDC doesn't define error responses nor call this aspect out in the
security considerations, I largely relied on this being mainstream.

  - IMHO The token validation procedure it too bound to the particular
> discovery mechanisms mentioned at the beginning of this section. E.g., Step
> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
> Identifier” which must much the iss claim. Moreover, I think it should be
> explicitly mentioned that the resource server “must validate that the JWT
> access token has been singed with a signing key that corresponds to the
> authorization server included in the iss claim”

As per the other points, the language follows closely OIDC.
The step does contain the phrase "The resource server MUST use the keys
provided by the authorization server." Do you feel the language should be
more explicit? The document doesn't specify any other mechanism for
acquiring keys, hence it shouldn't be too ambiguous... but we can always
tighten it up.


On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou  wrote:

> Hi all,
>
>
>
> Allow me some comments and forgive me if some of them are naïve.
>
> - In Section 2.2 why nbf claim (
> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>  is not considered? I
> can imagine some interesting applications of this claim.
>
> - In the same section, it is not clear why some claims are required,
> especially exp, sub, and client_id. The last two claims are not even used
> during token validation.
>
> - RFC7519 specifies that, in the general case, the aud claim is an array
> of StringOrURI values. In this draft it is not clear if this still the
> case, or here aud is a simple string (e.g., in page 5 it is stated: the
> resource indicated in the aud claim, rather than the resource*s*).
>
> - In the token validation procedure, i.e., Section 4, is there any reason
> why the resource server first checks the aud claim, then the signature, and
> finally the exp claim? Given the fact that Error responses are not
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.
>
> - IMHO The token validation procedure it too bound to the particular
> discovery mechanisms mentioned at the beginning of this section. E.g., Step
> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
> Identifier” which must much the iss claim. Moreover, I think it should be
> explicitly mentioned that the resource server “must validate that the JWT
> access token has been singed with a signing key that corresponds to the
> authorization server included in the iss claim”
>
>
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* OAuth  *On 

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

[George Fletcher]

Feedback on the spec...

Section 1. Introduction
��� second line: scenario should be plural --> scenarios
��� second sentence: "are not ran by" --> "are not run by"

Section 2.2.1 Authentication Information Claims
��� I'm not sure that this definition of `auth_time` allows for the 
case where a user is required to solve an additional challenge. Take the 
case of a user who is required to pass a secondary challenge before the 
"stock purchase" action can be completed. According to the current spec 
definition, the `auth_time` value MUST NOT be updated when this 
secondary challenge is completed.


��� I think there is a difference between session_start_time and last 
auth_time. This feels more like it's defining the session_start_time 
concept.


�� These same issues can apply to the `acr` and `amr` values as well.

�� Even if for this secondary challenge a new refresh_token is issued, 
it is unlikely many relying parties will want to treat that as issuing a 
new session. The goal is to keep the user logged in to a single session.


Section 2.2.3 Authorization Claims
�� I find the statement "All the individual scope strings in the scope 
claim MUST have meaning for the resource indicated in the aud claim" 
somewhat problematic. In many deployments today for 1st party clients to 
the authorization server and taking into account mobile applications, 
the access token most like contains scopes for many of the 1st party 
backend APIs. It's possible to get around this by setting the 'aud' 
claim to something like "com.example.apis" and hence all the issued 
scopes map to that audience claim but that is just working around the 
MUST in the spec. Given the lack of specificity of the 'aud' claim and 
the 'resource indicator' claim for that matter, pretty much anything can 
be made to comply. In that context, it seems like RECOMMEND is a better 
normative clause.


Section 3. Requesting a JWT Access Token
�� Per my comments above I suspect that requiring all JWT access tokens 
to include an audience claim will just devolve to audience claims that 
are somewhat pointless (in order to meet this MUST in the spec). Given 
the mobile app environment today, it is unreasonable to ask the mobile 
apps to downscope every access token before making an API call to the 
backend APIs which is what the spirit of audience and resource 
indicators seem to imply.


�� Why MUST the AS reject a request with more than one resource 
parameter? If a request comes in with no resource parameter and multiple 
scopes the AS is not required to reject that request. Is there much of a 
semantic difference between the two? In the case of no resource 
parameter and multiple scopes the AS might issue an access token with 
multiple audience values (as is allowed by RFC 7519). Also, the audience 
claim is not solely for resource indicator values but is defined to just 
be a string. To me it feels like the text is implying that the only 
valid audience value is also a resource indicator (which from previous 
discussions on the list it was implied they have a slightly different 
semantic).


�� The model described here works well if myco.example really only 
provides a single service. But if instead myco.example provides multiple 
services each with their own endpoints (srva.myco.example, 
srvb.myco.example) and scopes, for me this model begins to break down. 
Either mobile apps are required to downscope all tokens to just the 
service they are calling at that point in time (which can have latency 
and connectivity issues), or myco.example has to create a generic 
"audience" string that represents all of example.com which doesn't seem 
to be the spirit of the existing specs.


�� In summary, I feel that this text is binding too tightly resource 
indicators to the audience claim. What is described is perfectly 
reasonable in a use case that is applying resource indicators in this 
way but is not indicative of the widely deployed models that already exist.


Section 4. Validating JWT Access Tokens
�� Step 4. -- Can we change the wording to not require resource 
indicators? What about... "The resource server MUST validate that the 
'aud' claim contains a string that represents the audience of this 
resource server."


Section 5. "cross-JWT confusion"
�� I think there may be confusion around what is meant by "distinct 
resources". In my example above, are srva.myco.example and 
srvb.myco.example "distinct resources"? or is the goal here to say that 
we want different audience values generated for cross-organization 
resources. For example, are mail.google.com and youtube.com "distinct 
resources"? or would an audience for google suffice in meeting the 
meaning of this paragraph?


� I'm having the same confusion in the next paragraph regarding the 
phrase "different resources". Are services provided by the same company 
"different resources" or are they all considered the same resource. Can 

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

[Filip Skokan]

Ad 1) the language is tricky but it does not say forbid the client from
sending in two resource values to the authorization endpoint, it says that
when access token is issued (i.e. the authorization_code grant at the token
endpoint) one of the granted resource values must be part of the request or
default to end up with an access token with a single audience. A resulting
refresh token contains all granted resource values. I don't see this as a
conflict but rather further profiling.

Ad 2) I disagree with making `aud` optional.

S pozdravem,
*Filip Skokan*


On Tue, 24 Mar 2020 at 07:48, Takahiko Kawasaki  wrote:

> (1)
> The requirement in the paragraph below excerpted from "3. Requesting a JWT
> Access Token":
>
> *If it receives a request for an access token containing more than one
> resource parameter, an authorization server issuing JWT access tokens MUST
> reject the request and fail with "invalid_request" as described in section
> 4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
> [RFC8707].  See Section 2.2 and Section 5 for more details on how this
> measure ensures there's no confusion on to what resource the access token
> granted scopes apply.*
>
>
> apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
> 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.
>
> (2)
> Regarding another paragraph shown below from the same section.
>
> *If the request does not include a resource parameter, the authorization
> server MUST use in the aud claim a default resource indicator.  If a scope
> parameter is present in the request, the authorization server SHOULD use it
> to infer the value of the default resource indicator to be used in the aud
> claim.  The mechanism through which scopes are associated to default
> resource indicator values is outside the scope of this specification.  If
> the values in the scope parameter refer to different default resource
> indicator values, the authorization server SHOULD reject the request with
> invalid_scope as described in section 4.1.2.1 of [RFC6749].*
>
>
> The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible. In addition, I don't think the rule
> referring to the "scope" parameter is worth being defined. That "aud" is
> missing but "scope" is available is enough for resource servers. In other
> words, if "aud" is determined based on the "scope", why do we have to set
> "aud" redundantly?
>
> Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".
>
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou  wrote:
>
>> Hi all,
>>
>>
>>
>> Allow me some comments and forgive me if some of them are naïve.
>>
>> - In Section 2.2 why nbf claim (
>> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>>  is not considered?
>> I can imagine some interesting applications of this claim.
>>
>> - In the same section, it is not clear why some claims are required,
>> especially exp, sub, and client_id. The last two claims are not even used
>> during token validation.
>>
>> - RFC7519 specifies that, in the general case, the aud claim is an array
>> of StringOrURI values. In this draft it is not clear if this still the
>> case, or here aud is a simple string (e.g., in page 5 it is stated: the
>> resource indicated in the aud claim, rather than the resource*s*).
>>
>> - In the token validation procedure, i.e., Section 4, is there any reason
>> why the resource server first checks the aud claim, then the signature, and
>> finally the exp claim? Given the fact that Error responses are not
>> specified, returning something like “invalid aud claim” even for tokens
>> with invalid signature may result in privacy/security attacks.
>>
>> - IMHO The token validation procedure it too bound to the particular
>> discovery mechanisms mentioned at the beginning of this section. E.g., Step
>> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
>> Identifier” which must much the iss claim. Moreover, I think it should be
>> explicitly mentioned that the resource server “must validate that the JWT
>> access token has been singed with a signing key that corresponds to the
>> authorization server included in the iss claim”
>>
>>
>>
>>
>>
>> Best,
>>
>> Nikos
>>
>>
>>
>> *From:* OAuth > *On
>> Behalf Of *Hannes Tschofenig
>> *Sent:* Monday, March 23, 2020 11:18 PM
>> *To:* oauth 
>> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
>> 2.0 Access Tokens"
>>
>>
>>
>> Hi all,
>>
>>
>>
>> this is a working group last call for "JSON Web Token (JWT) Profile for
>> OAuth 2.0 Access Tokens".
>>
>>
>>
>> Here is the document:
>>
>> 

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

[Takahiko Kawasaki]

(1)
The requirement in the paragraph below excerpted from "3. Requesting a JWT
Access Token":

*If it receives a request for an access token containing more than one
resource parameter, an authorization server issuing JWT access tokens MUST
reject the request and fail with "invalid_request" as described in section
4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
[RFC8707].  See Section 2.2 and Section 5 for more details on how this
measure ensures there's no confusion on to what resource the access token
granted scopes apply.*


apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
8707 won't support this draft unless the requirement is loosened, for
example from MUST to SHOULD.

(2)
Regarding another paragraph shown below from the same section.

*If the request does not include a resource parameter, the authorization
server MUST use in the aud claim a default resource indicator.  If a scope
parameter is present in the request, the authorization server SHOULD use it
to infer the value of the default resource indicator to be used in the aud
claim.  The mechanism through which scopes are associated to default
resource indicator values is outside the scope of this specification.  If
the values in the scope parameter refer to different default resource
indicator values, the authorization server SHOULD reject the request with
invalid_scope as described in section 4.1.2.1 of [RFC6749].*


The rule described here whereby to determine the default value of the "aud"
claim is unintelligible. In addition, I don't think the rule referring to
the "scope" parameter is worth being defined. That "aud" is missing but
"scope" is available is enough for resource servers. In other words, if
"aud" is determined based on the "scope", why do we have to set "aud"
redundantly?

Requiring the "aud" as a MUST claim is the reason that this draft has to
introduce philosophy about "aud" that may conflict with other
specifications and may not be supported by all implementers. I would
suggest changing "REQUIRED" to "OPTIONAL".


Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou  wrote:

> Hi all,
>
>
>
> Allow me some comments and forgive me if some of them are naïve.
>
> - In Section 2.2 why nbf claim (
> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>  is not considered? I
> can imagine some interesting applications of this claim.
>
> - In the same section, it is not clear why some claims are required,
> especially exp, sub, and client_id. The last two claims are not even used
> during token validation.
>
> - RFC7519 specifies that, in the general case, the aud claim is an array
> of StringOrURI values. In this draft it is not clear if this still the
> case, or here aud is a simple string (e.g., in page 5 it is stated: the
> resource indicated in the aud claim, rather than the resource*s*).
>
> - In the token validation procedure, i.e., Section 4, is there any reason
> why the resource server first checks the aud claim, then the signature, and
> finally the exp claim? Given the fact that Error responses are not
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.
>
> - IMHO The token validation procedure it too bound to the particular
> discovery mechanisms mentioned at the beginning of this section. E.g., Step
> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
> Identifier” which must much the iss claim. Moreover, I think it should be
> explicitly mentioned that the resource server “must validate that the JWT
> access token has been singed with a signing key that corresponds to the
> authorization server included in the iss claim”
>
>
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* OAuth  *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, March 23, 2020 11:18 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
> Access Tokens"
>
>
>
> Hi all,
>
>
>
> this is a 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-04
>
>
>
> Please send you comments to the OAuth mailing list by April 6, 2020.
>
>
>
> Ciao
>
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Nikos Fotiou]

Hi all,

 

Allow me some comments and forgive me if some of them are naïve.

- In Section 2.2 why nbf claim
(https://tools.ietf.org/html/rfc7519#section-4.1.5) is not considered? I can
imagine some interesting applications of this claim.

- In the same section, it is not clear why some claims are required,
especially exp, sub, and client_id. The last two claims are not even used
during token validation.

- RFC7519 specifies that, in the general case, the aud claim is an array of
StringOrURI values. In this draft it is not clear if this still the case, or
here aud is a simple string (e.g., in page 5 it is stated: the resource
indicated in the aud claim, rather than the resource*s*).

- In the token validation procedure, i.e., Section 4, is there any reason
why the resource server first checks the aud claim, then the signature, and
finally the exp claim? Given the fact that Error responses are not
specified, returning something like “invalid aud claim” even for tokens with
invalid signature may result in privacy/security attacks.

- IMHO The token validation procedure it too bound to the particular
discovery mechanisms mentioned at the beginning of this section. E.g., Step
2 mentions a “registration” process, and Step 3 mentions and an “Issuer
Identifier” which must much the iss claim. Moreover, I think it should be
explicitly mentioned that the resource server “must validate that the JWT
access token has been singed with a signing key that corresponds to the
authorization server included in the iss claim”  

 

 

Best,

Nikos

 

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth 
Subject: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"

 

Hi all,

 

this is a 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-04 

 

Please send you comments to the OAuth mailing list by April 6, 2020.

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you. 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth