Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10

[Vittorio Bertocci <[e-mail]>]

Thank you Roman for the thorough review!
I applied all the editorial and typo fixes. I have a few questions on some comments, once solved I'll update accordingly and push a new version.
Thanks!
Inline


>On 11/15/20, 08:39, "OAuth on behalf of Roman Danyliw" <[e-mail] on behalf of [e-mail]> wrote:
>[..]    
>    ** 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 [..]
>   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?
 You are right, that's not very clear. 
In a nutshell, what I am trying to say is "if you want to express an attribute for which there's already a well-established claim available, use that rather than inventing  new one.".
That still allows for non-IANA claims to be introduced, as long as the implementer has done the due diligence and verified that the attribute they convey isn't covered in the IANA JWT registry.
I explicitly mention OpenID Connect as source of claims mostly to ensure that the reader will understand at first glance that when it comes to user information a JWT AT can convey the same information obtained via OpenID Connect, without the need to follow the link and consult the change controller/reference column of the claims to realize that. One of the goals I am hoping this spec will achieve is to stop people from abusing ID tokens and using them in lieu of access tokens (as Kubernetes routinely does, for example), hence the "denormalized" language of that section.
Here's an alternative formulation that tries to preserve that clarity while referring to the registry: 

"Any additional identity attribute whose semantic is well described by an entry in the JSON Web Token (JWT) IANA registry introduced in [RFC7519] SHOULD be encoded using the corresponding claim name.
Note that the JWT IANA registry includes the claims found in Section 5.1 of [OpenID.Core]."
   
What do you think? Waiting for your feedback before changing the language in the draft.
   
>    ** 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?)?
This was actually a MUST until draft 3, then Brian pointed out that this would have made this profile more restrictive than resource indicators itself- which led me to soften the requirement accordingly. Brian's comment in its entirety:
|Resource Indicators is about how the client conveys the target to the AS and says " The authorization server may use the exact 'resource' value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource". The following from |sec 3 is more restrictive / prescriptive, which seems to reach beyond the scope of the JWT access token profile. 
||  "If the request includes a resource parameter (as defined in
|| [ResourceIndicators]), the resulting JWT access token aud claim MUST
||   have the same value as the resource parameter in the request."    
 
>    ** 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?   
That's a good point. The last paragraph of section 4 was meant to be a catch-all for those cases, mentioning entitlements under the "authorization claims" umbrella and everything else as "any other contextual information". The thing that makes me hesitate before getting more specific than that is that it can be a slippery slope (acr, amr, entitlements etc are good candidates, but the same might be said about auth_time for max_age like scenarios, for example... where to draw the line?) and being those optional, not everyone might readily understand without adding more color/context. Combined with how difficult reaching consensus for the inclusion of session properties in access tokens, plus the fact thatRFC6750 does not give RS specific guidance for how to act on authorization info (scopes), I opted for generic language.
If you feel strongly about more specific guidance being required for those claims, I can propose more specific language- but before doing so, I wanted to offer the context above to see if it changes things.   
 
    
 >   ** 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).
I combed draft-ietf-oauth-security-topics-16 and besides the parts about sub, client_id and aud (already referenced by the current spec, or further restricted- as it the case for the audience considerations), the BCP doesn’t appear to offer further guidance that would vary depending on the content of the token. The guidance seems mostly on how the token is obtained, and the mechanisms described operate at the message level hence apply to JWT access tokens and opaque tokens in the same way. Did you have any specific section of the BCP in mind? 
I also took a look at rfc7519 SecCon and it doesn’t appear to offer claims-specific considerations. Finally, I combed thru rfc8725 and it seems the current spec covers all the content specific recommendations that apply to this scenario, namely in section 4 for the audience, issue and subject validation, and section 2.1 and 4 for the strong typing.
Bottom line: I could add a generic recommendation to consider OAuth2.Security.BestPractices, rfc7519 and rfc8725 when considering the security of a JWT access token, but the only section that seem directly applicable seems the 4.14 we already reference. What do you think? Do we need that blanket reference?