[OAUTH-WG] Secdir last call review of draft-ietf-oauth-resource-metadata-08

David Mandelberg via Datatracker <noreply@ietf.org> Fri, 16 August 2024 22:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from [10.244.2.52] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 20911C14F5FC; Fri, 16 Aug 2024 15:41:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: David Mandelberg via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.22.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172384809277.1449681.408544072139184106@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Fri, 16 Aug 2024 15:41:32 -0700
Message-ID-Hash: AMAFETEVMXAY52YI5VLL4XL4Z4KZMJ4Z
X-Message-ID-Hash: AMAFETEVMXAY52YI5VLL4XL4Z4KZMJ4Z
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-oauth-resource-metadata.all@ietf.org, last-call@ietf.org, oauth@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: David Mandelberg <david@mandelberg.org>
Subject: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-resource-metadata-08
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8-bNrdJwOXxKHzBs28eR_iJVR1E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Reviewer: David Mandelberg
Review result: Has Nits

Overall, looks good. I just have a couple of questions that might not need any
changes to the doc.

Section 5.2 says "SHOULD retrieve the updated protected resource metadata and
use the new metadata values obtained" which makes sense for the values included
directly in the metadata. For the URLs like jwks_uri though, is the client
expected to retrieve those again even if the URL itself didn't change? Or does
that not need to be specified?

What do you think about adding something to section 5.2 about redoing all
validation (like checking the resource field and validating the signature in
signed_metadata) before using new values? I'd hope that any implementations
would do that without it being specified, but I could see some bugs if the code
path for fetching initial values is different than the code path for updating
values.