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

Vittorio Bertocci <> Fri, 22 January 2021 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D62B3A0CFF for <>; Fri, 22 Jan 2021 14:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u8ek1Pz99Pqz for <>; Fri, 22 Jan 2021 14:15:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BB223A1484 for <>; Fri, 22 Jan 2021 14:14:54 -0800 (PST)
Received: by with SMTP id z21so4765341pgj.4 for <>; Fri, 22 Jan 2021 14:14:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=MsmbUgQwEk2DMc9tWIINR0YviuiXQ5FwXD28u7K5GPxNxX4eIx8ITGqbrVRhlSAWeu iAVVdYkYVEwkQMcjGk0YTHzFwtVKT7F3hMLdyTWVRwcy6kwRk0Xc+3OAGlfXJCMTVdey nw7Ax9D7k4PfZsE019f3QTW/OYOcp/C8Yu82kufW18Eyezu6PmswJcu6Slu/A5oFWQzv HYcywL7NHG5cFvPhJBkSJUwuvyEYrElVY2XTH2lNVZIxzbBwJFUfLljV2teJCO9Oomhb 3aDNhnA4NCkxbzWjJrEN21wg79v0Xuqg2xsXOtqf11stSEeb9hsbkiNtws/T71KmImac u9xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=OTl/ZAts2FOb8a9d+O2cykTb4cKbzRtTnh4qg9FYvY7LamKG3aDpfhAoIMYdDtzlyq y5jgccRravNLJItSFE79JP5fQLZWj7TyZOuHBvnjob7V43CusXsXYqooMx4BuPsqIr55 0UPAtES+s1Ftdac364uA3mzvwZijssNrKJ78Q1hZATvspQ/7OmoUjV8GM+odberZZ5AN nalIedN0PV2PJhlcIn0Xuhq4fr99D0VKTAhnFP3jfBn432gyi3Fb/uVncDmsehN2Sy8P NbZhK6uwIG5XLtbnm6ZqxHzirc9fMbglH2G6We7cOv1t2nsKWCRyDzEUiaBOW4M7OouS rzCw==
X-Gm-Message-State: AOAM532k47fhceop+sgi1how5XGypwOocHHuVLO/9dVosIUesRc+Okc5 cX00RdWFUyWPNnoBJqHVSjj51Jed1z2SPw==
X-Google-Smtp-Source: ABdhPJxWMTev4LvOsrUoIzEo1NL8zAWWsg4DlsKMWKOqxk8uee2TjVimL/n/FJ3LAqios9jQ2dYXSQ==
X-Received: by 2002:a62:8801:0:b029:1b9:c4af:8148 with SMTP id l1-20020a6288010000b02901b9c4af8148mr7199465pfd.18.1611353693555; Fri, 22 Jan 2021 14:14:53 -0800 (PST)
Received: from ([2603:1036:301:402a::5]) by with ESMTPSA id c4sm3090249pfo.35.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 14:14:52 -0800 (PST)
From: Vittorio Bertocci <>
To: Roman Danyliw <>, "" <>
Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyECus6VlABw7Xgdw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 22 Jan 2021 22:14:51 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
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: Fri, 22 Jan 2021 22:15:45 -0000

NP, thank you for the followup!
I posted an update reflecting the feedback and comments. We're version 11.

On 1/14/21, 06:35, "Roman Danyliw" <> wrote:

    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.