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

Roman Danyliw <rdd@cert.org> Sun, 15 November 2020 16:38 UTC

Return-Path: <rdd@cert.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 548CA3A0876 for <oauth@ietfa.amsl.com>; Sun, 15 Nov 2020 08:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id R74L7A-JPR4L for <oauth@ietfa.amsl.com>; Sun, 15 Nov 2020 08:38:50 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9983A0869 for <oauth@ietf.org>; Sun, 15 Nov 2020 08:38:49 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu []) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0AFGcmGn035392 for <oauth@ietf.org>; Sun, 15 Nov 2020 11:38:48 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 0AFGcmGn035392
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1605458328; bh=vnAtwLOsBjsdNn5vbbaK3je81UZ5Qtgm3PYpxQcqh6s=; h=From:To:Subject:Date:From; b=OcqMEhhn8/9jFzp6rFLT1RXL6FfiyKy5RakgF06SNpe+XY8/yn4VKdCTTpYETgp6F KlenP9rm2Fzf7yj2Ji58RkYDXocd+Sqn71lqy2zeDoaUNAMioty9uNv9lt9MtqR86X xxgfa0yr0GnfJFhTtihFmMbZjCGRDla9aVzDags0=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu []) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0AFGcm3n011812 for <oauth@ietf.org>; Sun, 15 Nov 2020 11:38:48 -0500
Received: from MORRIS.ad.sei.cmu.edu ( by MORRIS.ad.sei.cmu.edu ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 15 Nov 2020 11:38:48 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Sun, 15 Nov 2020 11:38:48 -0500
From: Roman Danyliw <rdd@cert.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQ==
Date: Sun, 15 Nov 2020 16:38:45 +0000
Message-ID: <c55fe95c27fd4d00a2685db2f847330c@cert.org>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2X21bY6xJCvFXjL7_CnKjt-XyTM>
Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2020 16:38:52 -0000


I conducted an AD review of draft-ietf-oauth-access-token-jwt-10.  Thanks for the work in getting this document written.  My detailed feedback is below all are minor or editorial.

** Section 1.2.  Editorial.  Per "JWT access token   An OAuth 2.0 ...", maybe put a colon between these two phrase to making it clearer that "JWT access token" is being defined.

** Section 2.1.  As they are introduced here for the first time, provide a citation for OpenID Connect ID Tokens

** Section 2.2.  Typo. s/application.See/Application. See/

** Section 2.2.1.  Editorial.  Section 2.2 seems to list one, claim per line.  "acr" and "amr" are together.

** Section 2.2.2.  Editorial.  s/userinfo/UserInfo/

** 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 [OpenID.Core] SHOULD be codified in JWT access tokens via the corresponding claim names in that section of the OpenID Connect specification The same holds for  attributes defined in [RFC7662] and other identity related specifications registering claims in the JSON Web Token (JWT) IANA registry introduced in [RFC7519].", I didn't follow all of the guidance here.

-- What does "... SHOULD be codified in JWT access tokens via the corresponding claim names in that section of the OpenID Connect specification ..." mean practically?  Is it that the those OpenId.Core claim names should be the names used in this profile?

-- What does "... the same holds for attributes ... in the JSON Web Token (JWT) IANA registry ..." mean too?
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?

** 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?)?

** Section 3.  Nit.  Move the trailing & from the second to third line, so this third link opens with "&state ..."

** Section 4.  Editorial. Per "For the purpose of facilitating validation data retrieval, it is ...", there is missing word here

** Section 4.  Please provide a reference to the "OpenID Connect discovery document"

** 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?

** Section 5.  Editorial.  The reference to [Oauth2.Security.BestPractices] to cover the danger if clients selecting their own sub is in Section 4.14 (s/Section 4.13 of/Section 4.14 of/).

** 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).

** Appendix A.  Typo. s/lenght/length/