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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Mar 2020 21:17:36 +0000

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.

---

From: "Nikos Fotiou" <[email-masked]>
Date: Tue, 24 Mar 2020 03:32:29 +0200

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 <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth <[email-masked]>
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:

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.

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 24 Mar 2020 15:46:44 +0900

(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 <[email-masked]> wrote:

> - 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.
>
> - 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*).
>
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, March 23, 2020 11:18 PM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
> Access Tokens"
>
>
>
> Hi all,
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Filip Skokan <[email-masked]>
Date: Tue, 24 Mar 2020 10:31:12 +0100

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 <[email-masked]> wrote:

> 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?
>
>> <https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered?
>> I can imagine some interesting applications of this claim.
>>
>> *From:* OAuth <oauth-bounces@ietf..org <[email-masked]>> *On
>> Behalf Of *Hannes Tschofenig
>> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
>> 2.0 Access Tokens"
>>
>>
>>
>> Hi all,
>>
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Mar 2020 13:39:48 -0400

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 
an access token be issued with scopes for both mail.google.com and 
youtube.com? And if not, why note? Preventing this puts undue burden on 
mobile based applications.

Section 6. Privacy
 �� cofidentiality --> confidentiality

Thanks,
George

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 24 Mar 2020 10:57:02 -0700

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

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

> especially exp, sub, and client_id. The last two claims are not even used

 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.

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

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

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

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 24 Mar 2020 11:14:35 -0700

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

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

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

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

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Mar 2020 14:47:35 -0400

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.

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Mar 2020 14:47:35 -0400

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 24 Mar 2020 19:07:31 +0000

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 <[email-masked]> on behalf of George Fletcher <gffletch=[email-masked]>
Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci <Vittorio=[email-masked]>, Takahiko Kawasaki <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

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:

resolves that ambiguity.

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Mar 2020 15:55:42 -0400

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

-- 
Identity Standards Architect
Verizon Media                     Work: [email-masked]
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Mar 2020 15:55:42 -0400

---

From: "Nikos Fotiou" <[email-masked]>
Date: Tue, 24 Mar 2020 22:55:36 +0200

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 <[email-masked]> 
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Nikos,

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”    

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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

- 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 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 <[email-masked] <mailto:[email-masked]> > On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth <[email-masked] <mailto:[email-masked]> >
Subject: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi all,

Here is the document:

Ciao

Hannes & Rifaat

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

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 24 Mar 2020 22:30:00 +0000

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 
>    ï¿½ï¿½ 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 token before making an API call to the 
    backend APIs which is what the spirit of audience and resource 
    indicators seem to imply.
Partly addressed in the preceding point, but this is a great opportunity to clarify the intent further. The mobile client isn't required to downscope; rather, the fact that a token cab be applied to a broad range of API should be clearly identified and expressed by the logical audience. The system designer can even choose to have a single token that can be used to call any API, containing every scope for every API; the profile only asks for this choice to be manifest, by choosing an appropriate audience identifier and acknowledging that all the scopes in the token are applicable to the same logical resource (that is, the aggregate of all the APIs). 

     >  ï¿½ï¿½ 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).
This is another consequence of making extra clear what the token refers to, and what the intended semantic of the scopes is. The idea is that the token is always restricted to ONE specific audience. The profile allows for different mechanisms for the AS to determine what value the audience should be, including via inference from scopes, but coherently with the scope confusion prevention principle, if that inference cannot lead to a single resource identifier in the audience, the request should be rejected.
The intent is really to be as simple as unambiguous as possible, and capture what most mainstream providers already do in JWT ATs. If a RS has more sophisticated requirements, they can always decide to do more and not follow the interop profile. Defining more complex rules to prevent scope/resource association confusion simply doesn’t seem to be justified by the frequency of the scenario in the wild.

>  Also, the audience 
Section 3 of the profile does define aud as a resource indicator, enumerating an exhaustive list of possible requests that all end in a resource indicator as aud, or an error. Did I miss some cases? I don’t recall specifics about aud values in this profile having other possible values, sorry for having missed that. Do you have a snippet referring to those discussions? Thx

    >  ï¿½ï¿½ The model described here works well if myco.example really only 
I think that the granularity of the calls is fully within the control of the designer. If srva.myco.example and srvb.myco.example share analogous characteristics (same policies, lifecycle, resource ownership, etc) them it's perfectly valid to assign a logical myco.example audience encompassing them all, regardless of deployment model. If there are differences in terms of policies, auth strength requirements, lifecycle, risk and impact of a leak, or any other boundary, then the audience requirement will guarantee that those differences are reflected in tokens requested and cached, in the way in which access is partitioned, and so on and so forth. If there are security requirements such as the ones enumerated, the latency and connectivity issues aren’t a blocking factor; and if there aren't, nothing prevents you from having a logical audience value. From the expressive power point of view, the requirement of having a single audience doens't prevent you from doing any of the single token logic you are hinting at- especially if you plan to use specialized scopes anyway.

   >   ï¿½ï¿½ 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.
We might have different experiences here. The JWT access tokens from popular products I studied in the research I presented in Stuttgart were almost all using the aud claim in this way. I am sure that there are other models, and there was at least one exception, but in interop terms this seems to be the most common way of using JWT for ATs- and it has the advantage of being very simple and unambiguous.

> 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."
Could you make an example in which you'd want to use an identifier that is not a resource indicator? Given that we have the spec, and "audience of the resource server" seems to be the exact semantic of resource indicators, it seemed a slam dunk to use it here... 

   > 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 think the key point here is - we don’t know. I agree the language isn't clear there. Let me expand on the intent, and perhaps we can get to a better formulation.
OAuth2 doesn’t demand that RS and AS are run by the same entity, but that's the most common scenario. FB doesn't need to specify a resource, because the resource is implicit.. it's the FB graph, you can’t get a token for anything else. The only differentiator ends up being the scopes. Same for many other providers, google, Microsoft for its own Graph, etc.
However many AS as a service don’t have the benefit of a default, implicit resource, especially in multi tenancy scenarios, given that they'll need to issue tokens for a number of different recipients. Whether resources are cross organization, or cross department, or following any other arbitrary segregation/factoring model is something we cannot infer- it's up to the developer to determine that. What I am trying to express here is that the operator of the AS as a service (or any other form of "AS for rent") should surface resources as a primitive for modeling and identifying intended recipients of ATs. Does tis help? How would you express that? 

>      ï¿½ I'm having the same confusion in the next paragraph regarding the 
See preceding point. We can't enter in the merit of what constitutes a resource, as that depends on the modeling of the domain specific problem the developer is tackling. The highest order bit is that if two entities (API, etc.. intended token recipients) have different security characteristics (e.g. leaking a token for one has different consequences than if you'd leak a token for the other), they should be modeled as different resources. And if they are different resources, we should do what we can to avoid confusion in how we express access grants to them (hence the big discussion on multiresource, scope confusion, etc).

---------
On 3/24/20, 10:39, "George Fletcher" <[email-masked]> wrote:

    Feedback on the spec...
    
    Section 1. Introduction
     ï¿½ï¿½ï¿½ second line: scenario should be plural --> scenarios
     ï¿½ï¿½ï¿½ second sentence: "are not ran by" --> "are not run by"
    
     ï¿½ï¿½ï¿½ I'm not sure that this definition of `auth_time` allows for the 
    
     ï¿½ï¿½ï¿½ 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.
    
     ï¿½ï¿½ I find the statement "All the individual scope strings in the scope 
    
     ï¿½ï¿½ Per my comments above I suspect that requiring all JWT access tokens 
    
     ï¿½ï¿½ Why MUST the AS reject a request with more than one resource 
    
     ï¿½ï¿½ The model described here works well if myco.example really only 
    
     ï¿½ï¿½ 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."
    
     ï¿½ï¿½ I think there may be confusion around what is meant by "distinct 
    
     ï¿½ I'm having the same confusion in the next paragraph regarding the 
    
    Section 6. Privacy
     ï¿½ï¿½ cofidentiality --> confidentiality

    Thanks,
    George

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 24 Mar 2020 22:36:30 +0000

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 <[email-masked]>
Date: Tuesday, March 24, 2020 at 13:55
To: 'Vittorio Bertocci' <[email-masked]>
Cc: 'Hannes Tschofenig' <[email-masked]>, 'oauth' <[email-masked]>
Subject: RE: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Best,
Nikos

Hi Nikos,

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

On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

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

Best,
Nikos

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

Hi all,

Here is the document:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 24 Mar 2020 22:45:35 +0000

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 with the paragraph that follows, and should be removed.

Knits:

  1.  §1 p1 s2: Terminology: “OAuth2” -> “OAuth 2.0”

     *   Also §1 p3 s2

  1.  §1 p1 s4: “All of the known commercial implementations known at this time”
Really? All of them? Known to who? I suggest changing this to: “At the time of writing, many commercial implementations”
  2.  §1 p2 s1:

     *   “Most vendor” -> “Many vendor”
     *   “including information in forms of claims meant to support the same scenarios”
The word “including” is ambiguous in this context, creating something of a garden path sentence. Assuming I understood the intent correctly, how about: “using JWT claims to convey the information needed to support a common set of use cases”

  1.  §1 p4 s1: Plurality: “access tokens layouts” -> “access token layouts”
  2.  §1 p4 s2: Plurality: “authorization requests parameters” -> “authorization request parameters”
  3.  §2 p1 s1: Duplicate word: “JWT tokens” -> “JWTs”
  4.  §2.1 p3 s2: Terminology: “id_tokens” -> “OpenID Connect ID Tokens”

     *   Also: §5 p1 s1

  1.  §2.2.1 p1 s1: Duplicate word: “the the types” -> “the types”
  2.  §2.2.2 p1 s1: Typo: “roudtrips” -> “round trips”
  3.  §2.2.2 p1 s2: Grammar: “as it is the case” -> “as is the case”
  4.  §2.2.2 p3 s1:

     *   Plural agreement: “semantic is well described” -> “semantics are well described”
     *   Apostrophe: “attributes description” -> “attribute’s description”

  1.  §2.2.2 p4 s1: Plurality: “Authorization server” -> “Authorization servers”
  2.  §2.2.3 p2 s1: Plurality: “scopes strings” -> “scope strings”
  3.  §4 p2 s3: Terminology: “Openid discovery” -> “OpenID Connect discovery”

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

From: OAuth <[email-masked]> on behalf of George Fletcher <gffletch=[email-masked]>
Organization: AOL LLC
Date: Tuesday, March 24, 2020 at 12:56 PM
To: Vittorio Bertocci <vittorio.bertocci=[email-masked]>, Vittorio Bertocci <[email-masked]>, Takahiko Kawasaki <[email-masked]>
Cc: oauth <[email-masked]>
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.

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.

From: OAuth <[email-masked]><mailto:[email-masked]> on behalf of George Fletcher <gffletch=[email-masked]><mailto:gffletch=[email-masked]>

To: Vittorio Bertocci <Vittorio=[email-masked]><mailto:Vittorio=[email-masked]>, Takahiko Kawasaki <[email-masked]><mailto:[email-masked]>

Cc: oauth <[email-masked]><mailto:[email-masked]>

resolves that ambiguity.

--

Verizon Media                     Work: [email-masked]<mailto:[email-masked]>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 24 Mar 2020 23:59:37 +0000

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. 

–

On 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocci" <[email-masked] on behalf of vittorio.bertocci=[email-masked]> wrote:

---------

    Feedback on the spec...

    Section 1. Introduction

    Section 6. Privacy

    Thanks,
    George

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 25 Mar 2020 09:52:39 +0000

Thank you for the kind words and the super thorough review, Annabelle!
Comments inline. I’ll reply to the aud/scope thread tomorrow.

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

>§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).

>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.
Great catch! I reworded accordingly.
>§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.
You are right that explicitly calling out those claims isn’t necessary given their current OPTIONAL status- thought in the spirit of making life easier for developers, given their importance I thought it was useful to explicitly reference them in the specification.
I’d personally be in favor of making those claims REQUIRED as well- especially JTI- I believe that they were marked OPTIONAL as the result of the discussions in Stuttgart, but if more people want to chime in favor of promoting them to REQUIRED, I’d be happy to change.

>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…
This is such a great point. Added language to preempt confusion there.
>§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>].”
You are right the individual descriptions aren’t strictly necessary and I did consider dropping the list, however I thought that for readability maintaining the list would make it easier for the skimmer to unpacks the content. Do you see harm in keeping the list, or is it more of a matter of conciseness?
>§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.
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 <[email-masked]> on behalf of "Richard Backman, Annabelle" <richanna=[email-masked]>
Date: Tuesday, March 24, 2020 at 15:45
To: 'oauth' <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Discussion Topics:

Minor Suggestions:

Knits:

     *   Also §1 p3 s2

     *   Also: §5 p1 s1

–

resolves that ambiguity.

--

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Mar 2020 09:09:43 -0600

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci <vittorio.bertocci=
[email-masked]> 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._

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Mar 2020 09:47:35 -0600

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 <vittorio.bertocci=
[email-masked]> 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).
>

---

From: <[email-masked]>
Date: Wed, 25 Mar 2020 09:06:58 -0700

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 <bcampbell=[email-masked]> 
Sent: Wednesday, March 25, 2020 8:10 AM
To: Vittorio Bertocci <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

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.

---

From: <[email-masked]>
Date: Wed, 25 Mar 2020 09:11:15 -0700

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.

Sent: Wednesday, March 25, 2020 8:48 AM

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.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Mar 2020 11:51:03 -0600

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 <vittorio.bertocci=
[email-masked]> 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 <bcampbell=[email-masked]>
> *Sent:* Wednesday, March 25, 2020 8:48 AM
> *To:* Vittorio Bertocci <[email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]>; oauth <
> [email-masked]>
> *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
> 2.0 Access Tokens"
>
>
>
> *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>
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
[email-masked]
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: 
<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> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<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&source=gmail&ust=1541693608526000&usg=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_source=Email&utm_campaign=WF-COVID19-New-EMSIG>
for
a more relevant offer.*

---

From: George Fletcher <[email-masked]>
Date: Wed, 25 Mar 2020 13:53:56 -0400

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:
>> really a practical way to achieve that with the mechanics of the jwks_uri..
>>
>>
>>
>> review, use, distribution or disclosure by others is strictly prohibited...

---

From: George Fletcher <[email-masked]>
Date: Wed, 25 Mar 2020 13:53:56 -0400

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Mar 2020 12:20:39 -0600

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 <gffletch=
[email-masked]> wrote:

> On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=[email-masked]> wrote:
>
>
> *From:* Brian Campbell <bcampbell=[email-masked]> <bcampbell=[email-masked]>
> *To:* Vittorio Bertocci <[email-masked]> <[email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]> <[email-masked]>; oauth <[email-masked]>
> On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci <vittorio.bertocci=[email-masked]> wrote:
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: <[email-masked]>
Date: Wed, 25 Mar 2020 11:44:00 -0700

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 <bcampbell=[email-masked]> 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher <[email-masked]>
Cc: Brian Campbell <[email-masked]>; Vittorio Bertocci <[email-masked]>; oauth <[email-masked]>
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 <gffletch=[email-masked] <mailto:[email-masked]> > wrote:

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

 
On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=
[email-masked] <mailto:[email-masked]> > wrote:

 
*From:* Brian Campbell  <mailto:bcampbell=[email-masked]> <bcampbell=[email-masked]>
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci  <mailto:[email-masked]> <[email-masked]>
*Cc:* Richard Backman, Annabelle  <mailto:[email-masked]> <[email-masked]>; oauth <
[email-masked] <mailto:[email-masked]> >
*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 <vittorio.bertocci=
[email-masked] <mailto:[email-masked]> > wrote:

 

 

-- 

Brian Campbell 
Distinguished Engineer 
[email-masked] <mailto:[email-masked]>  
w: +1 720.317.2061 
c: +1 303.918.9415 

Connect with us: 

 <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>  <https://www.linkedin.com/company/21870>  <https://twitter.com/pingidentity>  <https://www.facebook.com/pingidentitypage>  <https://www.youtube.com/user/PingIdentityTV>  <https://www.pingidentity.com/en/blog.html> 

If you’re not a current customer, click here <https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG>  for a more relevant offer.

---

From: George Fletcher <[email-masked]>
Date: Wed, 25 Mar 2020 14:56:12 -0400

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?

---

From: <[email-masked]>
Date: Wed, 25 Mar 2020 11:57:36 -0700

That works for me!

From: George Fletcher <[email-masked]> 
Sent: Wednesday, March 25, 2020 11:56 AM
To: [email-masked]; 'Brian Campbell' <bcampbell=[email-masked]>
Cc: 'Brian Campbell' <[email-masked]>; 'oauth' <[email-masked]>
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, [email-masked] <mailto:[email-masked]>  wrote:

 

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

 

 

On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch=[email-masked] <mailto:gffletch=[email-masked]>   <mailto:[email-masked]> <mailto:[email-masked]> > wrote:

 
 
On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=
[email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <mailto:[email-masked]> > wrote:

 
*From:* Brian Campbell   <mailto:bcampbell=[email-masked]> <mailto:bcampbell=[email-masked]>  <mailto:bcampbell=[email-masked]> <bcampbell=[email-masked]>
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci   <mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> <[email-masked]>
*Cc:* Richard Backman, Annabelle   <mailto:[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]> <[email-masked]>; oauth <
[email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <mailto:[email-masked]> >
*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 <vittorio.bertocci=
[email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <mailto:[email-masked]> > wrote:

 

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

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 25 Mar 2020 14:56:12 -0400

Thoughts?

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 25 Mar 2020 21:25:39 +0000

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.

–

From: OAuth <[email-masked]> on behalf of "vittorio.bertocci=[email-masked]" <vittorio.bertocci=[email-masked]>
Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' <[email-masked]>, 'Brian Campbell' <bcampbell=[email-masked]>
Cc: 'oauth' <[email-masked]>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

That works for me!

Thoughts?
On 3/25/20 2:44 PM, [email-masked]<mailto:[email-masked]> wrote:

From: Brian Campbell <bcampbell=[email-masked]><mailto:bcampbell=[email-masked]>

To: George Fletcher <[email-masked]><mailto:[email-masked]>

Cc: Brian Campbell <[email-masked]><mailto:[email-masked]>; Vittorio Bertocci <[email-masked]><mailto:[email-masked]>; oauth <[email-masked]><mailto:[email-masked]>

On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> > wrote:

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> > wrote:

*From:* Brian Campbell  <mailto:bcampbell=[email-masked]><mailto:bcampbell=[email-masked]> <bcampbell=[email-masked]><mailto:bcampbell=[email-masked]>

*To:* Vittorio Bertocci  <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

*Cc:* Richard Backman, Annabelle  <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; oauth <

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> >

2.0 Access Tokens"

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> > wrote:

Tokens.*

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Mar 2020 15:26:16 -0600

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 <[email-masked]> wrote:

> That works for me!
>
>
>
> *From:* George Fletcher <[email-masked]>
> *Sent:* Wednesday, March 25, 2020 11:56 AM
> *To:* [email-masked]; 'Brian Campbell' <bcampbell=
> [email-masked]>
> *Cc:* 'Brian Campbell' <[email-masked]>; 'oauth' <
> [email-masked]>
> 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".
>
> From: Brian Campbell <bcampbell=[email-masked]> <bcampbell=[email-masked]>
>
> To: George Fletcher <[email-masked]> <[email-masked]>
>
> Cc: Brian Campbell <[email-masked]> <[email-masked]>; Vittorio Bertocci <[email-masked]> <[email-masked]>; oauth <[email-masked]> <[email-masked]>
>
> On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch=[email-masked] <mailto:[email-masked]> <[email-masked]> > wrote:
>
>
>
> [email-masked] <mailto:[email-masked]> <[email-masked]> > wrote:
>
>
>
> *From:* Brian Campbell  <mailto:bcampbell=[email-masked]> <bcampbell=[email-masked]> <bcampbell=[email-masked]> <bcampbell=[email-masked]>
>
> *To:* Vittorio Bertocci  <mailto:[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
>
> *Cc:* Richard Backman, Annabelle  <mailto:[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>; oauth <
>
> [email-masked] <mailto:[email-masked]> <[email-masked]> >
>
> [email-masked] <mailto:[email-masked]> <[email-masked]> > wrote:
>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 25 Mar 2020 23:46:11 +0000

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 <[email-masked]>
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci <[email-masked]>
Cc: George Fletcher <[email-masked]>, Brian Campbell <bcampbell=[email-masked]>, oauth <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
That works for me!

From: George Fletcher <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 25, 2020 11:56 AM
To: [email-masked]<mailto:[email-masked]>; 'Brian Campbell' <bcampbell=[email-masked]<mailto:[email-masked]>>
Cc: 'Brian Campbell' <[email-masked]<mailto:[email-masked]>>; 'oauth' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

--
[Ping Identity]<https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
[email-masked]<mailto:[email-masked]>
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us:
[Glassdoor logo]<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[LinkedIn logo]<https://www.linkedin.com/company/21870>[twitter logo]<https://twitter.com/pingidentity>[facebook logo]<https://www.facebook.com/pingidentitypage>[youtube logo]<https://www.youtube.com/user/PingIdentityTV>[Blog logo]<https://www.pingidentity.com/en/blog.html>
[https://www.pingidentity.com/content/dam/ping-6-2-assets/images/misc/emailSignature/2020/MFA-Offer.png]<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_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for a more relevant offer.

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

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 25 Mar 2020 23:53:23 +0000

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

To: "vittorio.bertocci=[email-masked]" <vittorio.bertocci=[email-masked]>, 'George Fletcher' <[email-masked]>, 'Brian Campbell' <bcampbell=[email-masked]>

–

That works for me!

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 26 Mar 2020 00:10:20 +0000

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 <[email-masked]>
Date: Wednesday, March 25, 2020 at 16:53
To: "Richard Backman, Annabelle" <richanna=[email-masked]>, "vittorio.bertocci=[email-masked]" <vittorio.bertocci=[email-masked]>, 'George Fletcher' <[email-masked]>, 'Brian Campbell' <bcampbell=[email-masked]>
Cc: 'oauth' <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

–

That works for me!

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 26 Mar 2020 00:24:40 +0000

[richanna]
Comments inline.
[/richanna]

–

From: Vittorio Bertocci <vittorio.bertocci=[email-masked]>
Date: Wednesday, March 25, 2020 at 2:53 AM
To: "Richard Backman, Annabelle" <[email-masked]>, 'oauth' <[email-masked]>
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[richanna]

  1.  While the current JWT AT implementations are a very useful point of reference, we should be careful not to over-index on them.
  2.  My concern is that I don’t want library/framework implementers to come away thinking they only need to support asymmetric signatures. They need to support the full set of JWS signing algorithms (other than “none”).
[/richanna]

[richanna]
I’ve already replied to the other thread, but I’ll note that “different strengths, different lifecycles” don’t matter much if the RS will accept both types of tokens, signed with either key.
[/richanna]

You are right that explicitly calling out those claims isn’t necessary given their current OPTIONAL status- thought in the spirit of making life easier for developers, given their importance I thought it was useful to explicitly reference them in the specification.
I’d personally be in favor of making those claims REQUIRED as well- especially JTI- I believe that they were marked OPTIONAL as the result of the discussions in Stuttgart, but if more people want to chime in favor of promoting them to REQUIRED, I’d be happy to change.
[richanna]
As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
[/richanna]

You are right the individual descriptions aren’t strictly necessary and I did consider dropping the list, however I thought that for readability maintaining the list would make it easier for the skimmer to unpacks the content. Do you see harm in keeping the list, or is it more of a matter of conciseness?
[richanna]
As evidenced by George’s questions, the individual descriptions are confusing. They aren’t worded as precisely as the paragraph above, and use different terms (e.g., “session”) that aren’t well defined. I’d keep the list but get rid of the extended description, or at the very least pare them down and reword them to match/reference the preceding paragraph.
[/richanna]
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?
[richanna]
A general statement that implementers SHOULD use claims from the registry where applicable would hold up better as future specs define identity-related claims, and I think better captures the intent of the claims registry. I think it’s appropriate to also refer developers to OIDC, Introspection, and SCIM as specs whose claims are likely to be applicable.
[/richanna]
Great catch. Added.
Good point. Removed.

[richanna]
Specs shouldn’t mandate things that don’t impact functionality or interoperability. If doing Y before X creates a security vulnerability, then by all means the spec should require X be done before Y. By all means, we can advise that implementers consider things like resource consumption in their design, but we should not assume that one fixed approach will work for everyone.

For example, Suppose an RS uses resource indicators that include tenant identifiers, and it needs to query the tenant database to resolve the identifier. This could mean that “aud” validation is more resource intensive than signature validation, particularly if the RS has the key material cached. Mandating that “aud” validation happen before signature validation creates a DoS risk at this RS.

Likewise, we should not assume that one metric like resource consumption should be optimized for over all else. Suppose an implementation uses a generic JWT library to parse and validate the JWT, and then checks that the type of the JWT returned by the library is “at+jwt”. This seems like a natural approach to me, especially since a generic library may not do any JWT type checking itself. Depending on the library’s interface, it could be quite awkward to do type checking first.
[/richanna]

[richanna]
I could see people reading step 7 as meaning that the use of “auth_time” inherently implies a fixed session lifetime, which may not be the case. Its value could simply be one signal amongst many that go into an authorization decision, as alluded to in the last paragraph of that section.
[/richanna]

Discussion Topics:

Minor Suggestions:

3.       §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.

4.       §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.

5.       §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>].”

6.       §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…”.

a.       Likewise for §2.2.3.1 p2 and SCIM Core.

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

8.       §3 p2: This paragraph is redundant and should be removed.

9.       §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.

Knits:

10.   §1 p1 s2: Terminology: “OAuth2” -> “OAuth 2.0”

a.       Also §1 p3 s2

11.   §1 p1 s4: “All of the known commercial implementations known at this time”
Really? All of them? Known to who? I suggest changing this to: “At the time of writing, many commercial implementations”

12.   §1 p2 s1:

b.       “Most vendor” -> “Many vendor”

c.       “including information in forms of claims meant to support the same scenarios”
The word “including” is ambiguous in this context, creating something of a garden path sentence. Assuming I understood the intent correctly, how about: “using JWT claims to convey the information needed to support a common set of use cases”

13.   §1 p4 s1: Plurality: “access tokens layouts” -> “access token layouts”

14.   §1 p4 s2: Plurality: “authorization requests parameters” -> “authorization request parameters”

15.   §2 p1 s1: Duplicate word: “JWT tokens” -> “JWTs”

16.   §2.1 p3 s2: Terminology: “id_tokens” -> “OpenID Connect ID Tokens”

d.       Also: §5 p1 s1

17.   §2.2.1 p1 s1: Duplicate word: “the the types” -> “the types”

18.   §2.2.2 p1 s1: Typo: “roudtrips” -> “round trips”

19.   §2.2.2 p1 s2: Grammar: “as it is the case” -> “as is the case”

20.   §2.2.2 p3 s1:

e.       Plural agreement: “semantic is well described” -> “semantics are well described”

f.        Apostrophe: “attributes description” -> “attribute’s description”

21.   §2.2.2 p4 s1: Plurality: “Authorization server” -> “Authorization servers”

22.   §2.2.3 p2 s1: Plurality: “scopes strings” -> “scope strings”

23.   §4 p2 s3: Terminology: “Openid discovery” -> “OpenID Connect discovery”

–

resolves that ambiguity.

--

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 26 Mar 2020 00:53:16 +0000

Yes, there isn’t a clear solution to this problem. My main concern at this point is that we don’t give the impression that an AS can establish security boundaries or prevent token mix up by using different keys. The text changes you suggest would address that.

–

From: Vittorio Bertocci <vittorio.bertocci=[email-masked]>
Date: Wednesday, March 25, 2020 at 5:10 PM
To: "Richard Backman, Annabelle" <[email-masked]>, "vittorio.bertocci=[email-masked]" <[email-masked]>, 'George Fletcher' <[email-masked]>, 'Brian Campbell' <[email-masked]>
Cc: 'oauth' <[email-masked]>
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

–

That works for me!

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Mar 2020 10:47:08 -0600

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 <
[email-masked]> 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 <[email-masked]>
> *Date: *Wednesday, March 25, 2020 at 14:26
> *To: *Vittorio Bertocci <[email-masked]>
> *Cc: *George Fletcher <[email-masked]>, Brian Campbell <bcampbell=
> [email-masked]>, oauth <[email-masked]>
> *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#RotateSigKeys -
> it's not perfect (this issue
>  <https://www.pingidentity.com/>
>
> *Brian Campbell*
> Distinguished Engineer
> *Connect with us: *
> <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
> <https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for
> a more relevant offer.*
>
>
> review, use, distribution or disclosure by others is strictly prohibited.

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 31 Mar 2020 21:33:35 +0000

I addressed all of the below, in line with your suggestion in nearly every case.
I am updating the draft as there are many changes accumulated at this point- will pick up the audiences and scope discussion afterwards.

> As evidenced by George’s questions, the individual descriptions are confusing. They aren’t worded as precisely as the paragraph above, and use different terms (e.g., “session”) that aren’t well def…
Alrighty, keeping the list with simplified descriptions seem to satisfy both PoVs. Done, I kept only the reference to OIDC.

> My concern is that I don’t want library/framework implementers to come away thinking they only need to support asymmetric signatures. They need to support the full set of JWS signing algorithms (other than “none”).
I see the concern, but I still think that we should be able to recommend one method in particular…  the asymmetric method does have concrete advantages in term of completeness of guidance, even if that doesn’t mean that the symmetric crypto should be ignored. Is there any other language you’d suggest that can achieve the goal of expressing that preference while minimizing the risk you are concerned about?

> I’ve already replied to the other thread, but I’ll note that “different strengths, different lifecycles” don’t matter much if the RS will accept both types of tokens, signed with either key.
point taken. I applied the changes discussed on the  other thread.

>As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
Promoted to RECOMMENDED

>Specs shouldn’t mandate things that don’t impact functionality or interoperability. If doing Y before X creates a security vulnerability, then by all means the spec should require X be done before Y. By all means, we can advise that implementers consider things like resource consumption in their design, but we should not assume that one fixed approach will work for everyone. [..]
Those are good examples. Also, I validated that the numbers in the idtoken validation steps in OIDC are in place only for layout purposes and there’s no normative intent behind it. To avoid any confusion, I switched the list from numbered to simple bullets.

>I could see people reading step 7 as meaning that the use of “auth_time” inherently implies a fixed session lifetime, which may not be the case. Its value could simply be one signal amongst many tha…
I am not convinced a lot of people would go for that interpretation, mostly as inferred from how that step is implemented in OIDC based solutions; however I don’t feel too strongly about that, I agree that 7 could be derived from the closing paragraph, and… by eliminating 7, we sidestep the challenges Aaron raised about how exactly would the RS signal to the client that authentication needs to reoccur. For all this considered, I am removing that step from the validation list.

> A general statement that implementers SHOULD use claims from the registry where applicable would hold up better as future specs define identity-related claims, and I think better captures the inten…
Added a reference to the JWT claims registry in 2.2.2. It was harder to do for SCIM given that we are explicitly feeding those attributes as JWT claims in this very profile.

From: "Richard Backman, Annabelle" <richanna=[email-masked]>
Date: Wednesday, March 25, 2020 at 17:25
To: Vittorio Bertocci <[email-masked]>, 'oauth' <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[richanna]
Comments inline.
[/richanna]

–

[richanna]

[richanna]

Great catch. Added.
Good point. Removed.

[richanna]

[richanna]

Discussion Topics:

Minor Suggestions:

Knits:

a.       Also §1 p3 s2

12.   §1 p2 s1:

d.       Also: §5 p1 s1

20.   §2.2.2 p3 s1:

–

You are too fast ?? I am still replying to your other comments! ??

resolves that ambiguity.

--

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 31 Mar 2020 21:33:45 +0000

Thank you! I updated the language accordingly, and added a warning in the security section aligned with your concerns.
Updating the draft shortly. Will pick up the audience/scope discussion right after that

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wednesday, March 25, 2020 at 17:53
To: Vittorio Bertocci <vittorio.bertocci=[email-masked]>, "vittorio.bertocci=[email-masked]" <[email-masked]>, 'George Fletcher' <[email-masked]>, 'Brian Campbell' <[email-masked]>
Cc: 'oauth' <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

–

–

That works for me!

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 31 Mar 2020 21:33:50 +0000

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

Date: Thursday, March 26, 2020 at 09:47

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2020 at 14:26
To: Vittorio Bertocci <[email-masked]<mailto:[email-masked]>>
Cc: George Fletcher <[email-masked]<mailto:[email-masked]>>, Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Thoughts?

2.0 Access Tokens"

Tokens.*

OAuth mailing list

OAuth mailing list

--
[Image removed by sender. Ping Identity]<https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
[email-masked]<mailto:[email-masked]>
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us:
[Image removed by sender. Glassdoor logo]<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[Image removed by sender. LinkedIn logo]<https://www.linkedin.com/company/21870>[Image removed by sender. twitter logo]<https://twitter.com/pingidentity>[Image removed by sender. facebook logo]<https://www.facebook.com/pingidentitypage>[Image removed by sender. youtube logo]<https://www.youtube.com/user/PingIdentityTV>[Image removed by sender. Blog logo]<https://www.pingidentity.com/en/blog.html>
[Image removed by sender.]<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_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for a more relevant offer.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Mar 2020 15:13:19 -0700

> >As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.

I'd also prefer REQUIRED, and thanks for already moving to RECOMMENDED
(which I was going to suggest as an alternative).

-Ben