Hi all,

 

Allow me some comments and forgive me if some of them are naïve.

- In Section 2.2 why nbf claim
(https://tools.ietf.org/html/rfc7519#section-4.1.5) is not considered? I can
imagine some interesting applications of this claim.

- In the same section, it is not clear why some claims are required,
especially exp, sub, and client_id. The last two claims are not even used
during token validation.

- RFC7519 specifies that, in the general case, the aud claim is an array of
StringOrURI values. In this draft it is not clear if this still the case, or
here aud is a simple string (e.g., in page 5 it is stated: the resource
indicated in the aud claim, rather than the resource*s*).

- In the token validation procedure, i.e., Section 4, is there any reason
why the resource server first checks the aud claim, then the signature, and
finally the exp claim? Given the fact that Error responses are not
specified, returning something like “invalid aud claim” even for tokens with
invalid signature may result in privacy/security attacks.

- IMHO The token validation procedure it too bound to the particular
discovery mechanisms mentioned at the beginning of this section. E.g., Step
2 mentions a “registration” process, and Step 3 mentions and an “Issuer
Identifier” which must much the iss claim. Moreover, I think it should be
explicitly mentioned that the resource server “must validate that the JWT
access token has been singed with a signing key that corresponds to the
authorization server included in the iss claim”  

 

 

Best,

Nikos

 

From: OAuth <oauth-boun...@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"

 

Hi all,

 

this is a working group last call for "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens".

 

Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04 

 

Please send you comments to the OAuth mailing list by April 6, 2020.

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you. 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to