[OAUTH-WG] Opsdir last call review of draft-ietf-oauth-resource-metadata-08
Bo Wu via Datatracker <noreply@ietf.org> Thu, 29 August 2024 12:53 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from [10.244.2.118] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id B069AC15106B; Thu, 29 Aug 2024 05:53:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Bo Wu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172493598435.69923.1519783976733419021@dt-datatracker-68b7b78cf9-q8rsp>
Date: Thu, 29 Aug 2024 05:53:04 -0700
Message-ID-Hash: ZWOXEUSQAP3VXFUJEOD7UDEDWK4YSFZB
X-Message-ID-Hash: ZWOXEUSQAP3VXFUJEOD7UDEDWK4YSFZB
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: Bo Wu <lana.wubo@huawei.com>
Subject: [OAUTH-WG] Opsdir 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/mLOwDh4tCy2d6FfjVJacqs0Vh8M>
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: Bo Wu Review result: Has Nits Hi, I'm the assigned Ops reviewer. I think this document is ready with nits. Here are some nits and questions: nits: 1) The Figure 1 Sequence Diagram does not seem to match the text in the steps. For example, step 5 in the diagram corresponds to step 5 and the first half of step 6 in the text description, and there is no "user agent" (step 8) in the diagram. Therefore, it is recommended that sequence numbers be added to the diagram. 2) s/The resource value returned/The "resource" value returned 3) s/specific member names such as resource/specific member names such as "resource" Some questions: 1) Section 1 Introduction The metadata for a protected resource is retrieved from a well-known location as a JSON [RFC8259] document, which declares information about its capabilities and optionally, its relationships to other services. Do other services refer to authorization servers? If yes, then it is recommended to use authorization servers directly. 2) Section 1 Introduction The means by which the client obtains the location of the protected resource is out of scope. In some cases, the location may be manually configured into the client. In Section 5.3, there is also text: This specification is intended to be deployed in scenarios where the client has no prior knowledge about the resource server, It seems that text in Introduction means that the resource server is prior knowledge of the client if I understand correctly. Am I correct? 3) Section 1.2. Terminology Resource Identifier: The Protected resource's resource identifier, which is a URL that uses the https scheme and has no query or fragment components. Protected resource metadata is published at a .well-known location [RFC8615] derived from this resource identifier, as described in Section 3. resource REQUIRED. The protected resource's resource identifier, which is a URL that uses the https scheme and has no query or fragment components. Using these well-known resources is described in Section 3. The two descriptions look almost same. Perhaps the reference of the definition can be used, for example: Resource Identifier: The Protected resource's resource identifier, which is a URL (see Section 2). 4) Section 5.3 Client Identifier and Client Authentication There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client Registration [RFC7591] to register the client prior to initiating the authorization flow. Future extensions might define alternatives, such as using URLs to identify clients. On “Future extensions",does this mean the extensions of RFC 7591? Thanks, Bo Wu
- [OAUTH-WG] Opsdir last call review of draft-ietf-… Bo Wu via Datatracker
- [OAUTH-WG] Re: Opsdir last call review of draft-i… Michael Jones
- [OAUTH-WG] Re: Opsdir last call review of draft-i… Michael Jones
- [OAUTH-WG] Re: Opsdir last call review of draft-i… Michael Jones
- [OAUTH-WG] Re: Opsdir last call review of draft-i… Wubo (lana)