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 <oauth-boun...@ietf.org> on behalf of Roberto Polli
<robipo...@gmail.com>
Date: Friday, April 2, 2021 at 02:55
To: oauth <oauth@ietf.org>
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
