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

["Richard Backman, Annabelle" <[e-mail]>]

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