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.
> ** 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?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
