Hi! I conducted an AD review of draft-ietf-oauth-access-token-jwt-10. Thanks for the work in getting this document written. My detailed feedback is below all are minor or editorial.
** Section 1.2. Editorial. Per "JWT access token An OAuth 2.0 ...", maybe put a colon between these two phrase to making it clearer that "JWT access token" is being defined. ** Section 2.1. As they are introduced here for the first time, provide a citation for OpenID Connect ID Tokens ** Section 2.2. Typo. s/application.See/Application. See/ ** Section 2.2.1. Editorial. Section 2.2 seems to list one, claim per line. "acr" and "amr" are together. ** Section 2.2.2. Editorial. s/userinfo/UserInfo/ ** Section 2.2.2. Per "Any additional attributes whose semantics Any additional attributes whose semantics are well described by the attribute's description found in Section 5.1 of [OpenID.Core] SHOULD be codified in JWT access tokens via the corresponding claim names in that section of the OpenID Connect specification The same holds for attributes defined in [RFC7662] and other identity related specifications registering claims in the JSON Web Token (JWT) IANA registry introduced in [RFC7519].", I didn't follow all of the guidance here. -- What does "... SHOULD be codified in JWT access tokens via the corresponding claim names in that section of the OpenID Connect specification ..." mean practically? Is it that the those OpenId.Core claim names should be the names used in this profile? -- What does "... the same holds for attributes ... in the JSON Web Token (JWT) IANA registry ..." mean too? Maybe my read it wrong, but it seems like this text saying that beyond the required claims listed in section 2.2, you can use any of the other claims as long as they are in the IANA JWT registry. Isn't that simpler, since the Section 5.1. OpenID.Core attributes are registered? ** Section 3. What would be the case where it would not be appropriate for the resource parameter value to be the same as the aud claim in the access token (the text currently says SHOULD, why not MUST?)? ** Section 3. Nit. Move the trailing & from the second to third line, so this third link opens with "&state ..." ** Section 4. Editorial. Per "For the purpose of facilitating validation data retrieval, it is ...", there is missing word here ** Section 4. Please provide a reference to the "OpenID Connect discovery document" ** Section 4. Per the validation guidelines on access token validation, is there parallel text needed to discuss the RS use of the token say: checking that the acr has a value that is appropriate (so it can have confidence in the security of the authentication used between client/AS)? Or that the right entitlements/groups/etc were present for the requested operation? ** Section 5. Editorial. The reference to [Oauth2.Security.BestPractices] to cover the danger if clients selecting their own sub is in Section 4.14 (s/Section 4.13 of/Section 4.14 of/). ** Section 5. This text seems to restate much of the text from [OAuth2.Security.BestPractices]. Do other section apply here? Perhaps also add that the SecCons of individual claims apply here too if used in the profile (as this profile allows pretty much anything in the JWT registry to be used). ** Appendix A. Typo. s/lenght/length/ Regards, Roman _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
