Last Call Review of draft-ietf-oauth-resource-metadata-08
review-ietf-oauth-resource-metadata-08-opsdir-lc-wu-2024-08-29-00

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