[OAUTH-WG] RAR WGLC feedback

Aaron Parecki <aaron@parecki.com> Fri, 28 October 2022 18:40 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31553C14F74B for <oauth@ietfa.amsl.com>; Fri, 28 Oct 2022 11:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_UtvgL_lm0x for <oauth@ietfa.amsl.com>; Fri, 28 Oct 2022 11:40:29 -0700 (PDT)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46288C14F6E5 for <oauth@ietf.org>; Fri, 28 Oct 2022 11:40:29 -0700 (PDT)
Received: by mail-vk1-xa34.google.com with SMTP id b81so2880032vkf.1 for <oauth@ietf.org>; Fri, 28 Oct 2022 11:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=gAKviZ4nO04loziX9O7uV72XRk/HLWY5AuW82KJIWEk=; b=XHiGbXNq7BGSd+3Ah/87VbbC1l1370qq22HKnb6bxQT138KyVVUsUabXYSq3wx0QWq hxm0GjZZLMSeX0rGxqhgfgQxQoulGzRGP+9PDOmL99HjejInowy39xDNNepQMIlWR1gM gpdhgXWL5N3grMUS6U7ZRxsgy/TnefWBOh2itA9l0320WtkeeSrY41jbjPNiX12lb0AH NekZ4hLcNeD1z34/r1TK5/lCZNsx4A6lRZSSJtLHMIn7TMZ0tisU0hY1I81Fy2oRkr8X QfZhdlDqjqrmzCzXTu1F/2gfTQxZTuCEzZd+9znjfE0nxKvMEyuWoMp8cytyawC/ljDa BAkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gAKviZ4nO04loziX9O7uV72XRk/HLWY5AuW82KJIWEk=; b=f2kBoPpANnYanLMAe3j4Hg6hWibkGWAool6buQvpheg/4osjIReHG/clGXGrqRex5A uUqMvp3i6R/hgxeankUYVse0zXEuboWtX7THjtntwz7wZS1eMttMscc75K9nvPcxO1OR X/41GdLlBYAYPBf6CykwnV8SLVLvsAR+IUxMfpkrL64Nh3vu8tedr8czLRhF+yAwpOm0 OK1NtnIBzB9uLa2UsLlvCN3IvAxrEDB7eiYsrHZmzPpyVqLrcXGCz9qwYqFOsdE567h+ IRTcn/+lablBD6XnfMmZJMMDE6K+jo3bkTUXrGFbBNrPfg7YToSuZyBwVBe0xv5ML6KR XtLQ==
X-Gm-Message-State: ACrzQf260/gRgj+cbBSFxR/jKLs6DvdEoaKc+xH4QaesxpnKURMsiEwF BQ4dOTMJxSrSif0cBZDMfM1Sb8D9PtmaKA==
X-Google-Smtp-Source: AMsMyM7pSmtoOtGTlpewYD+hcJ2+ZMb1sFhRyR6H+oO5RwUHDnhW44inFgnbuUhSnW6KjWCxqYmrlA==
X-Received: by 2002:a1f:31c4:0:b0:3b5:b7cc:e68a with SMTP id x187-20020a1f31c4000000b003b5b7cce68amr649132vkx.6.1666982426944; Fri, 28 Oct 2022 11:40:26 -0700 (PDT)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com. [209.85.217.44]) by smtp.gmail.com with ESMTPSA id 8-20020a05612208c800b003ab69e002d8sm506379vkg.35.2022.10.28.11.40.25 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 11:40:26 -0700 (PDT)
Received: by mail-vs1-f44.google.com with SMTP id d187so5960037vsd.6 for <oauth@ietf.org>; Fri, 28 Oct 2022 11:40:25 -0700 (PDT)
X-Received: by 2002:a05:6102:3192:b0:3a7:acc7:7c74 with SMTP id c18-20020a056102319200b003a7acc77c74mr310431vsh.68.1666982425650; Fri, 28 Oct 2022 11:40:25 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 28 Oct 2022 11:40:14 -0700
X-Gmail-Original-Message-ID: <CAGBSGjoa21ksVc4tT5roDZ1YRAvLQ6FFb6Dqh7XkvMG5zMf-Wg@mail.gmail.com>
Message-ID: <CAGBSGjoa21ksVc4tT5roDZ1YRAvLQ6FFb6Dqh7XkvMG5zMf-Wg@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Justin Richer <justin@bspk.io>, Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="00000000000053ed7b05ec1c97de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/v57qYaLOuywWCNhzBIJFgtutBfI>
Subject: [OAUTH-WG] RAR WGLC feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 28 Oct 2022 18:40:34 -0000

In reviewing RAR, I noticed a couple things. I've submitted the editorial
suggestions below as a PR.

* Changed "the requested scope, i.e., the permission, of an access token"
to "the requested scope, i.e., the limited capability, of an access token".
Scope isn't defined as "permission" in OAuth 2.0. Permissions are often
handled by internal mechanisms other than scopes, and scopes are more about
limiting the capability of an access token.
* Clarified the description of Token Introspection
* "the user consent" -> "the user consent prompt"
* "attacker vector" -> "attack vector"

https://github.com/oauthstuff/draft-oauth-rar/pull/90

I have some other notes as well, which I didn't have a quick fix for to
suggest in the PR.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.1

Would it be more appropriate to reference the JWT Access Token spec
(RFC9068) rather than just the JWT spec (RFC7519) now that it's an RFC?

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.2

Section 9.2 about the token introspection response is missing normative
language about whether and what specifically is recommended. The section
9.1 above does have "RECOMMENDED" for the authorization_details parameter.
I think this should match, but I'm not clear on exactly where this should
go. Perhaps this also suggests that "The authorization_details member
contains..." is ambiguous as to whether this is normative or just a
suggestion, and should be fixed as well.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-10

Again, "The AS publishes" and "Clients announce" are missing a keyword
"MUST/SHOULD/MAY", so it's not clear whether these are required.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-11.3

"the JSON schema id" should this be "the JSON Schema ID" or "the JSON
Schema `id`"?

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-13

Is this a "MUST" or a "must"?

"to learn the user data" - this sounds awkward, should it be "the user's
data"? Not sure if there is a better suggestion.

---
Aaron Parecki
https://aaronparecki.com