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

Roman Danyliw <> Thu, 14 January 2021 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C1B33A1304 for <>; Thu, 14 Jan 2021 06:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vA39JU7A6qoI for <>; Thu, 14 Jan 2021 06:36:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FFB33A1009 for <>; Thu, 14 Jan 2021 06:35:59 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 10EEZvlN013644; Thu, 14 Jan 2021 09:35:57 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 10EEZvlN013644
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=yc2bmwvrj62m; t=1610634957; bh=xfsxXe/sxQuSNesecYOyfVOW/dSZaeHYXGGTPMxQyc0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=q2AfIvGF4FeY2SiwyINDBrEBDRAt2o1X4dd1ov0J+NminMv1yl7/bN+P+GwCJc95j AwbuAwb/82c1Yu8uKZBIgrGJoborA1OeEtJEDtwmt+G24kofyICecEvHbbJpsOoEB8 EqhPyWicRkoLokaPuOuNyOTD5jG9CSawfo1I+Ofk=
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 10EEZqLY042329; Thu, 14 Jan 2021 09:35:52 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 14 Jan 2021 09:35:52 -0500
Received: from ([fe80::555b:9498:552e:d1bb]) by ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 14 Jan 2021 09:35:52 -0500
From: Roman Danyliw <>
To: Vittorio Bertocci <>, "" <>
Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyECus6VlA=
Date: Thu, 14 Jan 2021 14:35:50 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jan 2021 14:36:03 -0000

Hi Vittorio!

So sorry for the delay, I didn't appreciate this was awaiting on a response.

> -----Original Message-----
> From: Vittorio Bertocci <>
> Sent: Thursday, November 19, 2020 3:45 AM
> To: Roman Danyliw <>rg>;
> 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-
> on behalf of> 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.