RFC 9728 - OAuth 2.0 Protected Resource Metadata endpoint.

Serves the protected-resource metadata document at /.well-known/oauth-protected-resource (RFC 9728 §3) so that a client - or an authorization server acting on its behalf - can discover, from the resource identifier alone, which authorization server(s) issue tokens for this resource, the scopes it recognises, and how it expects bearer tokens to be presented. This is the resource-server analogue of the RFC 8414 authorization-server metadata DiscoveryController serves, and the discovery half of the RFC 9728 §5.1 WWW-Authenticate: Bearer ..., resource_metadata challenge AttestoPhoenix.Plug.Authenticate emits on a 401: the challenge points a client here, and this endpoint answers.

The document is assembled by Attesto.ProtectedResourceMetadata.metadata/2; this controller contributes transport concerns only and adds no policy of its own. The members are derived from the protocol and host configuration the rest of the server already carries:

• resource (RFC 9728 §2, REQUIRED) - the resource identifier, the core builder's default: the access-token audience a resource server validates is exactly its resource identifier.
• authorization_servers - this server's issuer. An OAuth deployment that is both the authorization server and the protected resource issues its own tokens, so the issuer is the authorization server for this resource; a client that reads this document then fetches that issuer's RFC 8414 metadata to run the flow.
• scopes_supported - the host's :scopes_supported, the same list the RFC 8414 document advertises, so the two never drift.
• bearer_methods_supported - the host's :bearer_methods_supported (AttestoPhoenix.Config), the RFC 6750 token-presentation methods the resource server accepts. Defaults to ["header", "body"], matching AttestoPhoenix.Plug.Authenticate (the Authorization header, §2.1, and a POST form-body access_token, §2.2); a header-only resource server sets ["header"] so the document describes exactly what it accepts.

The response carries no secrets and is identical for every caller, so it is served unauthenticated, and RFC 9728 §3.1 permits caching, so a public, cacheable Cache-Control header is set.

Wiring

Like the other metadata endpoints, the host pipeline must place the AttestoPhoenix.Config under conn.private[:attesto_phoenix_config] and the derived Attesto.Config under conn.private[:attesto_protocol_config]. Both are required; a missing value raises rather than serving a partial document, because a document that omits authorization_servers or resource would misdirect a client.