RFC 9728 defines the "resource_metadata" parameter for WWW-Authenticate challenges.
Two examples: ``` GET / HTTP/1.1 Host: resource.example.com HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata= "https://resource.example.com/.well-known/oauth-protected-resource"; ``` ``` GET /resource1 HTTP/1.1 Host: resource.example.com HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata= " https://resource.example.com/.well-known/oauth-protected-resource/resource1"; ``` For clients that use this parameter to fetch metadata, section 3.3 states: > If the protected resource metadata was retrieved from a URL returned by the > protected resource via the WWW-Authenticate resource_metadata parameter, then > the resource value returned MUST be identical to the URL that the client used > to make the request to the resource server. Given that the resource value must match the URL the client used, the client has all the information it needs in order to make a request to the well-known URL, even in the absence of the parameter. It can simply compute the well-known location given the URL it requested, and fetch the corresponding metadata. It seems to me that the only real utility of this parameter is when well-known URIs are not being used. Applications (such as MCP) that make use of discovery using well-known URLs could just profile this as a requirement, obviating the use of the parameter. Does this seem like a reasonable conclusion? Jared Hanson Co-Founder ja...@keycard.ai www <https://www.keycard.ai> | linkedin <https://www.linkedin.com/in/jaredhanson> | github <https://github.com/jaredhanson>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
