NP, thank you for the followup!
I posted an update reflecting the feedback and comments. We're version 11.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-11
Thanks
V.
On 1/14/21, 06:35, "Roman Danyliw" <r...@cert.org> wrote:
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
