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.)