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

[Vittorio Bertocci <[e-mail]>]

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 anything else.
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 <[e-mail]> on behalf of "Richard Backman, Annabelle" <richanna=[e-mail]>
Date: Tuesday, March 24, 2020 at 15:45
To: 'oauth' <[e-mail]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

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

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

Discussion Topics:

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

Minor Suggestions:

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

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

     *   Likewise for §2.2.3.1 p2 and SCIM Core.

  1.  §2.2.2 p4: This should reference Sections 4.2 and 4.3 of RFC 7519, which provide the requirements for Public and Private Claim Names.
  2.  §3 p2: This paragraph is redundant and should be removed.
  3.  §4 p4: We should call out the checks that are necessary from a security perspective, but we should not mandate a specific order except where there are dependencies. Step 7 in the list is redundant 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 <[e-mail]> on behalf of George Fletcher <gffletch=[e-mail]>
Organization: AOL LLC
Date: Tuesday, March 24, 2020 at 12:56 PM
To: Vittorio Bertocci <vittorio.bertocci=[e-mail]>, Vittorio Bertocci <[e-mail]>, Takahiko Kawasaki <[e-mail]>
Cc: oauth <[e-mail]>
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.

I'll wait for your response to my other feedback :)
On 3/24/20 3:07 PM, Vittorio Bertocci wrote:

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

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



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

Date: Tuesday, March 24, 2020 at 11:48

To: Vittorio Bertocci <Vittorio=[e-mail]><mailto:Vittorio=[e-mail]>, Takahiko Kawasaki <[e-mail]><mailto:[e-mail]>

Cc: oauth <[e-mail]><mailto:[e-mail]>

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



Focusing just on this comment...



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

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



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



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



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



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



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



is facading a collection of existing finer grained resources, scopes



representing permissions might be ambiguous - if my API facades both



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



resolves that ambiguity.






--

Identity Standards Architect

Verizon Media                     Work: [e-mail]<mailto:[e-mail]>

Mobile: [phone]           Twitter: http://twitter.com/gffletch

Office: [phone]           Photos: http://georgefletcher.photography