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

[Vittorio Bertocci <[e-mail]>]

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 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.
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 that go into an authorization decision, as alluded to in the last paragraph of that section.
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 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.
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=[e-mail]>
Date: Wednesday, March 25, 2020 at 17:25
To: Vittorio Bertocci <[e-mail]>, 'oauth' <[e-mail]>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[richanna]
Comments inline.
[/richanna]

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


From: Vittorio Bertocci <vittorio.bertocci=[e-mail]>
Date: Wednesday, March 25, 2020 at 2:53 AM
To: "Richard Backman, Annabelle" <[e-mail]>, 'oauth' <[e-mail]>
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [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.

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.

[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]

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

[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]

>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.
[richanna]
As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
[/richanna]

>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?
[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]
>§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?
[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]
>§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.

[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]
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?

[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]

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:

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.

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.

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”

–
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