Hi Vittorio! So sorry for the delay, I didn't appreciate this was awaiting on a response.
> -----Original Message----- > From: Vittorio Bertocci <vittorio.berto...@auth0.com> > Sent: Thursday, November 19, 2020 3:45 AM > To: Roman Danyliw <r...@cert.org>; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10 > > 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" <oauth- > boun...@ietf.org on behalf of r...@cert.org> 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 This looks fine to me. > > ** 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." Oh, got it. Thanks for explaining. > > ** 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. Hmm. I wish it could be clearer but I now understand the trade off you made. Please leave the text as is. > > ** 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? I re-read [OAuth2.Security.BestPractices] and my suggestion; and agree with your assessment. Almost nothing in the BCP is about specific to the token content and format which this narrow focus of this draft. Again, sorry for delay. Regards, Roman > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
