Original text:
5.1. This specification introduces a new parameter in the "WWW- <del> Authenticate" response to indicate the resource identifier of the protected resource: </del>  <del> The resource identifier of the protected resource. </del>  The HTTP status code and error string in the response are defined by RFC6750. <del> The issuer parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </del>  5.2. At any point, for any reason determined by the protected resource, the protected resource MAY respond with a new "WWW-Authenticate" <del> challenge that includes a value for the resource identifier to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del>  5.3.

Reviewer comments:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Revised text:
5.1. This specification introduces a new parameter in the "WWW-  <ins> Authenticate" response to indicate the protected resource metadata URL: </ins>  <ins> The URL of the protected resource metadata. </ins> The HTTP status code and error string in the response are defined by RFC6750.  <ins> The "resource_metadata" parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </ins> 5.2. At any point, for any reason determined by the protected resource, the protected resource MAY respond with a new "WWW-Authenticate"  <ins> challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.