Define client trust for MCP metadata documents
Client ID Metadata Documents give MCP authorisation servers a resolvable client identifier. Define trusted applications and metadata change controls before treating that identifier as approval to access internal systems.
Trace the interfaces between applications and records before changing a system.
An MCP connection may redirect a user to sign-in and consent before allowing an application to read internal material. Review client trust alongside user permissions. The name and logo are not independent proof that an application is approved.
The 28 July 2026 specification changes the preferred registration mechanism. Client ID Metadata Documents use a client-hosted HTTPS URL as the identifier. Earlier mechanisms also provided identifiers, with different portability and trust arrangements.
A resolvable identifier helps a server inspect what a client declares about itself. The organisation still needs policy for acceptable clients, redirect destinations and metadata changes. Assign an owner and test enforcement.
What changed on 28 July
The 2026-07-28 authorisation specification deprecates Dynamic Client Registration and points new implementations at Client ID Metadata Documents instead. Registration is, in the specification’s words, “retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents”.
The mechanics matter more than the deprecation. Under a metadata document the client identifier is an HTTPS URL, and that URL resolves to a JSON document the client hosts. The document has to carry a client identifier, a client name and a list of redirect URIs, and the identifier inside it has to match the URL exactly. The authorisation server fetches the document when it sees a URL-shaped identifier, checks that match, checks the redirect URI in the request against the list the document declares, and then shows the user a consent screen carrying the client name.
- 01 Client hosts A JSON document at an HTTPS URL it controls, naming itself and its redirect URIs.
- 02 Client presents The URL is the client identifier in the authorisation request.
- 03 Server resolves The authorisation server fetches the document and checks the identifier matches the URL.
- 04 Server validates Redirect URI against the document, document structure, and whatever domain policy the enterprise has set.
- 05 User consents The screen shows the name from the document. A token follows, bound to one resource.
Two properties follow from that, and both are worth having. The identifier is stable: the same client presents the same URL to every authorisation server, and the client registration rules note that identifiers of this kind are “portable across authorization servers” with no re-registration when the server changes. And the identifier is resolvable, so anyone can fetch the document and read what the client says about itself before a token is ever issued.
| Dynamic Client Registration | Client ID Metadata Documents |
|---|---|
| The identifier is opaque and minted per authorisation server | The identifier is an HTTPS URL that resolves to a document |
| Credentials are bound to the issuer and re-registration follows a change of server | The identifier is portable, and a change of server needs no re-registration |
| Apply a registration policy and govern identifiers issued by the server | A domain to put on a list, known before anything is approved |
| Preserve submitted registration metadata for review and change control | What the client says about itself is a document anyone can fetch and re-read |
| Deprecated, and retained for servers that cannot do the other thing | The mechanism the specification directs new implementations towards |
The name on the consent screen is one the client chose
This is the part a security review has to get right, and it is easy to read past. The document is hosted by the client. The client name is a string the client wrote. The logo is an image the client serves. What the authorisation server validates is internal consistency — that the identifier matches the URL, that the redirect URI is on the declared list, that the JSON parses — and not that the application behind it is the one the person approving it believes they are approving.
The specification is honest about this. In its own worked flow, the validation steps are the identifier match, the redirect URI check and the document structure, followed by an item marked optional: the domain being allowed via a trust policy. The trust policy is the control. It is optional in the protocol because it cannot be anything else — only the enterprise knows which domains it is willing to see on a consent screen.
An identifier that says where a client comes from is an improvement. It becomes a control only when somebody writes down which origins are acceptable.
Dynamic Client Registration can be governed through registration policies and issued identifiers. Metadata documents provide a different input: a portable URL and declared metadata. Both require an assessment of the application and restrictions on access.
What to do about it
Review origin policy and metadata refresh together. Define what happens when a refreshed document changes material fields. HTTP caching affects when the server sees a change, so preserve the reviewed state and specify how later versions are handled.
Protocol support alone does not describe access controls. Ask which transport, authorisation and registration mechanisms the supplier uses, which extensions are supported and how enterprise policy is enforced. Assess these against the proposed deployment.
What this does not tell you
The metadata document mechanism rests on an IETF draft rather than a published RFC, and the specification cites it at its initial draft revision. Drafts change, and a control built on one is a control to revisit rather than to write once.
The cited specification covers HTTP-based transport and distinguishes local transport, where credentials are obtained from the environment. Local servers need their own inventory, access restrictions and credential controls. Risk depends on the available tools and data.
Client identity is also not agent identity. Knowing which application is asking does not tell you on whose authority it acts, what it may reach, or when its credential expires. The protocol’s roadmap of 22 August 2026 puts proof of possession and workload identity federation next, which is an acknowledgement that the delegation problem is still open rather than a solution to it.
Client trust policy is one architecture control. Test an approved connection, an unapproved client and a metadata change. These results support assessment without establishing that all applicable obligations are met.
The identity-platform owner should document which origins and applications may reach consent and receive tokens. Test enforcement and metadata changes. A permissive default needs a deliberate decision and a stated operating boundary.