Telechat Review of draft-ietf-oauth-resource-metadata-10
review-ietf-oauth-resource-metadata-10-httpdir-telechat-bishop-2024-09-27-00

I have only a passing familiarity with the details of OAuth, so some of my
questions may be born out of ignorance there. However, I think I understand the
general use case for this protocol.

The structure itself seems sound -- for any given application URL, there is a
defined 1:1 mapping to a metadata URL from which a client can retrieve
information about the application. This information includes which
authorization server(s) the client could use to retrieve an acceptable
authentication token, and by extension retrieve the authorization servers'
metadata.

I have a few questions, which may or may not warrant changes to the document:

It was not entirely clear to me how the client maps an arbitrary URL which may
be handled by an application (e.g. https://example.com/library/foo) to the
resource identifier URL of the application itself. (This may be handled by the
extension of the WWW-Authenticate header, which I have a separate question
about later.)

Section 3 describes both a default well-known suffix and describes the
possibility of other suffixes as well. I found this confusing on a first read;
it might be clearer to simply describe the format and where it is published by
default. Application-specific suffixes can state in their registering
specification that the same format is to be used; the possibility can be
mentioned here as an aside.

Section 3.1 says that the metadata does not provide "general information about
the host", which seems potentially incorrect if the path is empty.

Section 3.3 is the first mention of the WWW-Authenticate use case; there's no
forward reference to Section 5 or mention of it in the introduction.

Section 5 defines a way for a WWW-Authenticate header to point to the
application's metadata. There appear to be no requirements on where this URL
can point. Must it be on the same server? Must it use HTTPS? (The client is
required to validate the server certificate, so probably.) Must it be under
.well-known or can it be an arbitrary path?

Throughout Section 5, WWW-Authenticate is referred to as a response. I
understand the shorthand, but it's actually a header field which can be
included in a response. A reference to Section 3 of RFC6750 might also be
useful here, beyond the general reference to the RFC.

(I'm a little unclear when the server returns a 401 with WWW-Authenticate
versus a 3XX to the authorization server, but that's an OAuth question not
specific to this document.)