Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications

[Vittorio Bertocci <[e-mail]>]

Hi Roberto,
Thanks for the comments and apologies for the delay. Inline


  *   An example with client_credential grant type would be nice too.
Are you thinking of specific aspects that aren’t sufficiently clear from the text that would be clarified by one example? Unless there’s something specific, at this late stage I’d like to avoid big edits.


  *   + The terms "Collision-Resistant",  is used according to Section 2 of {{JWT}}.
Is the feedback to add the reference to section 2, or to add a dash? The referenced section 4.2 of RFC7519 clarifies the use of the term, hence it seems unnecessary to mention section 2 as well (given that the notion of collision resistance is clear outside of this context too).


  *   - mentioning "none" alg can be redundant. I'd reference all the JWT BCP instead.
Calling out “none” was specifically brought up during discussions as something that is worth calling out. Although we might be formally covered by simply referencing the BCP, forcing the user to resolve a reference and process another large document seems to lose efficacy, clarity and immediacy of the guidance.


  *   Is it worth mentioning the "implicit flow"?
What would you want to highlight of that particular case?


  *   - " ... scope parameter..."  should `scope` be quoted?
That’s’ a good question! Given that scope the parameter and scope the claim appear in the same sentence, I chose to use the quotes for the claim and leave the parameter unquoted to make it easier for the reader to follow (see also the subsequent paragraph). I am inclined to leave it as is and see whether the editors accept it.


  *   ^ otherwise the error returned is ...? Should we reference §4 here?
This was a hotly debated point. The consensus we landed on is enshrined in P4 of Section 5, which we do reference from there. Substantially, establishing clear rules for how to make that match or how the AS should react to it is very hard, hence we explicitly leave handling the details to individual implementations.


  *   which are the delegated scenarios described in RFC7519? Do you refer to "When using an administratively delegated
      namespace" ? It is not clear to a first-reader.
I mean the most classical oauth use cases :) The core scenarios described in RFC7519 are about a resource owner delegating limited access to a third party application, as stated in the abstract and most of the document. The mainstream literature covering oauth uses the term consistently, and the section goes on describing user level attributes that have no direct role in the identity of the client application. I believe the intent of this section should be reasonably clear with someone with some familiarity with oauth, which I’d assume as prerequisite.


  *   - iiuc `jti` is required, the example does not report it.
Great catch! In draft 06 we made both JTI and IAT REQUIRED, but we never updated the sample. Adding both in the upcoming revision. Thank you.


  *   the step about forbidding "none" is limitative WRT JWT BCP 8725
I think the limitation in the case of JWTs used as ATs is justified.
Whereas openid connect’s ID_tokens (also JWTs) can be acquired thru a direct TLS channel between the client and the AS, hence obviating for the need of an explicit signature check, that isn’t usually the case with access tokens- there the requestor (the client) and the intended recipient (the RS) are separate entities. The responsibility of the token validation falls on the RS, which has no direct channel toward the AS (excluding introspection, which would largely make the entire JWT encoding of ATs moot) hence needs a way of validating tokens independently, and a signature is the common practice. Although alternative mechanisms are possible, they are uncommon enough to be safely excluded from an interop profile.

From: OAuth <[e-mail]> on behalf of Roberto Polli <[e-mail]>
Date: Friday, April 2, 2021 at 02:55
To: oauth <[e-mail]>
Subject: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications

Hi Vittorio et al,

some considerations on oauth access token jwt follows.
You can see them here too https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit

An example with client_credential grant type would be nice too.

My 2¢,
R.

§ 1.2  Terminology

+ The terms "Collision-Resistant",  is used according to Section 2 of {{JWT}}.

§2.1 Header

- mentioning "none" alg can be redundant. I'd reference all the JWT BCP instead.
- I'd add an example header, eg


~~~ example

{

  "typ": "at+jwt",

  "alg": "PS256"

}

~~~


§ 2.2.1 Authentication Information Claims

Is it worth mentioning the "implicit flow"?

§2.2.2 Identity Claims

- use the "Collision-Resistant" definition in {{JWT}}

§2.2.3 Authorization Claims

- " ... scope parameter..."  should `scope` be quoted?
-  "All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim."
^ otherwise the error returned is ...? Should we reference §4 here?

§2.2.3.1 Claims for Authorization Outside of Delegation Scenarios
- which are the delegated scenarios described in RFC7519? Do you refer to "When using an administratively delegated
      namespace" ? It is not clear to a first-reader.


§3 Requesting a JWT Access Token
- an example with `client_credential` grant type would be great.
- iiuc `jti` is required, the example does not report it.

§4 Validating JWT Access Tokens

- the step about forbidding "none" is limitative WRT JWT BCP 8725