During authorization, a client presents an HTTPS URL as its client_id, and the authorization server fetches a JSON document from that URL. What is this mechanism, and what must the document contain?
Select an answer to reveal the explanation.
Short Explanation
Here the client's ID is literally a web address, and the document behind it is the client's business card. It has to carry its own ID, a name, and where to send you back afterwards, and that ID has to match the URL character for character.
Full Explanation
With Client ID Metadata Documents, a client uses an HTTPS URL as its client identifier, and that URL points to a JSON document describing the client. This addresses the common MCP case where client and server have no prior relationship. Clients must host the document at an HTTPS URL whose client_id uses the https scheme and contains a path; the document must include at least client_id, client_name and redirect_uris; and the client_id value in the document must match the document URL exactly. Authorization servers should fetch the document when they see a URL-formatted client_id, must validate that client_id matches the URL exactly, must validate presented redirect URIs against the document, must check the JSON is valid with required fields. Calling it Dynamic Client Registration fails because that mechanism has the client POST metadata to the authorization server's registration endpoint and receive credentials back, the opposite direction. Calling it Protected Resource Metadata fails by concept: that document is published by the MCP server to name its authorization servers, not by a client to describe itself. Calling it a pre-registration record fails because pre-registration means the client already holds an identifier issued in advance. Exam caveat: an authorization server fetching client-supplied URLs must guard against SSRF. Operational check: fetch the client_id URL and confirm the document's client_id is byte-identical to it.