MCP Draft DCR Deprecation: What Client ID Metadata Documents Change

Before an MCP client can ask a user for access, the authorization server needs some details about that client: its identifier, where it may receive an authorization response, and how it will interact with the token endpoint. For an application you already know, those details can be registered ahead of time. The more interesting case is a client arriving at a service it has never used before.

Dynamic Client Registration (DCR) gives that client a way to introduce itself programmatically. It submits metadata to a registration endpoint and receives a client ID to use in the authorization flow. That is a useful fit for independently developed MCP clients connecting to independently operated services, without someone arranging every pairing in advance.

The reviewed MCP authorization draft now recommends support for a different approach: Client ID Metadata Documents (CIMD). Instead of asking each authorization server to issue an identifier, the client uses an HTTPS URL where its metadata is published. DCR remains a deprecated compatibility fallback in that draft, rather than being deprecated across OAuth.

The change raises two practical questions: what work does hosting the metadata remove, and what can an authorization server trust about the client using that URL? Those are worth separating. A portable client description is useful, but it is not proof of which application is running on the user’s machine.

First, here is where the two mechanisms sit in the draft’s selection order. Existing pre-registration still comes first:

flowchart TD
    Start[Client discovers authorization-server metadata] --> Known{Existing pre-registration?}
    Known -->|Yes| Existing[Use existing client details]
    Known -->|No| Metadata{CIMD supported?}
    Metadata -->|Yes| URL[Use HTTPS metadata URL as client ID]
    Metadata -->|No| Dynamic{DCR supported?}
    Dynamic -->|Yes| Register[Register through deprecated compatibility path]
    Dynamic -->|No| Manual[Manual registration and user-entered details]
    Existing --> Authorize[Continue authorization and consent]
    URL --> Authorize
    Register --> Authorize
    Manual --> Authorize

That is a useful implementation direction, not evidence that every DCR deployment was inherently unsafe. The trade-off is clearer if we follow a client through both approaches instead of treating deprecation as a verdict on the whole protocol.

Use the same hypothetical example as the OAuth proxy article: Naledi wants Notes Desktop to read her team’s notes at https://notes.example/mcp. The service uses https://auth.notes.example as its authorization server. That server may broker an Entra relationship, but the registration question here is between Notes Desktop and the notes authorization server.

DCR Does Not Require an Uncontrolled Registration Database#

With DCR, Notes Desktop submits metadata to a registration endpoint and receives a client ID from that authorization server. The metadata includes such things as redirect URIs and the token-endpoint authentication method. Registration does not grant access to Naledi’s notes; it establishes details used during the later authorization flow.

An open endpoint that accepts unlimited submissions can create an operational problem. So can a consent screen that presents any submitted name as a trusted brand. Neither behaviour is an unavoidable requirement of RFC 7591.

The RFC allows protected registration using an initial access token. It also defines software statements, signed assertions about client software that the authorization server can evaluate against a trusted issuer and its own policy. A signature from an arbitrary issuer is not enough, but a trusted statement can provide evidence beyond a self-asserted display name.

Its security considerations discuss abuse controls, including rate limiting. Credential expiry is represented by client_secret_expires_at when applicable; registration retention and retirement need a deliberate deployment policy. Expiring a secret is not the same as deleting a client record. More fundamentally, Appendix A.5 explicitly permits stateless registration designs. A permanent database row per request is not a protocol invariant.

There is also a separate registration-management protocol. RFC 7592 section 2.3 defines client deletion, but RFC 7592 is optional and Experimental. You cannot assume every DCR endpoint supports it. Equally, its optional status is not evidence that operators are forbidden from retiring registrations.

For Notes Desktop, DCR still means establishing a registration relationship with each distinct authorization server it needs. If hundreds of services have separate authorization servers, the bookkeeping can become inconvenient. CIMD offers a different arrangement for that problem without requiring us to pretend DCR has no safeguards.

CIMD Moves the Metadata to a Portable Address#

Suppose Notes Desktop’s publisher hosts a document at https://desktop.example/oauth/client-metadata.json. With CIMD, that HTTPS URL is the client ID. The publisher prepares the document before users connect; Notes Desktop does not first ask each supporting authorization server to issue another identifier.

The authorization server advertises client_id_metadata_document_supported in its metadata. When Notes Desktop uses its URL identifier, the server obtains and validates the document, including the exact match between its client_id field and the URL, and checks the requested redirect against the document’s allowed redirects and applicable rules. This is metadata validation, not permission to skip the rest of OAuth.

The benefit is portability: the same URL can identify the client’s metadata to multiple supporting authorization servers. Each still decides whether to accept the client and what access to allow. A portable identifier does not carry a portable user grant.

The CIMD draft cited here, version -00, permits caching in section 4.4. It does not require a live fetch on every authorization request. That makes the hosting dependency more manageable, but creates a freshness question: when the publisher changes a redirect URI, a server with cached metadata needs an appropriate refresh policy.

Nor does CIMD erase authorization-server state. The server may retain cached metadata, local acceptance policy, consent records, grants and token-lifecycle information. It can avoid issuing a new registration record just to learn each client’s metadata; that is a narrower and more useful claim than calling the whole system stateless. Removing a metadata document is not a universal revocation mechanism for existing grants or tokens.

For the notes service, the practical gain is fewer server-specific registration exchanges. The next question is what the document actually proves.

The Publisher’s Domain Is Not the Running Application#

An HTTPS metadata document associates the retrieved metadata with its hosting origin. It does not prove that the process presenting that URL controls the domain, and it does not independently verify the organisation or brand named inside the JSON.

Anybody can copy a public client ID. That remains true when the identifier is a URL. Client IDs are not secrets.

Consider a malicious local application using Notes Desktop’s real metadata URL. If the document permits a localhost callback, that application may start its own authorization flow and listen on a permitted local redirect. The authorization server fetches the genuine publisher’s document. No domain takeover was necessary: the attacker reused a public identifier and initiated a new transaction.

The MCP localhost redirect risk discussion addresses precisely this distinction. The CIMD -00 draft’s sections 6.2 and 6.4 also matter when evaluating public-client impersonation and trust. A correct fetch cannot establish which executable is listening on Naledi’s machine.

PKCE does not close that gap. It binds code redemption to the verifier associated with the initiating flow. In this example, the malicious application generated its own verifier and challenge, so it can complete its own flow. PKCE remains essential protection against attacks such as interception of a legitimate client’s code; it is not application attestation.

A metadata URL tells you where the description came from, not which program is asking for access.

Consent interfaces should therefore distinguish the metadata origin from an unverified display name. A lookalike name on an attacker-controlled domain does not become a verified brand because HTTPS works. Local acceptance policy, vetted integrations or stronger client authentication where feasible remain separate decisions. CIMD gives those decisions an origin to examine, not a reason to stop examining them.

Fetching Metadata Creates Its Own Boundary#

Moving metadata to a URL also means the authorization server makes an outbound request using client-supplied input. Without restrictions, that can become server-side request forgery: an attacker persuades the server to contact internal services on the attacker’s behalf.

The CIMD -00 security considerations discuss this retrieval risk. Treat document fetching as a constrained subsystem. Require HTTPS for metadata URLs and reject private, loopback and link-local destinations, including addresses reached through DNS resolution. Loopback exceptions for desktop callback URIs do not make loopback metadata fetches acceptable.

If redirects are followed, validate every destination again. Revalidate DNS and enforce the destination restrictions at connection time so a rebinding or time-of-check/time-of-use change cannot bypass the initial check. Bound response size, request duration and redirect count, and enforce outbound network policy. A JSON parser is not an egress firewall.

Authenticating the user before fetching can reduce anonymous abuse, but it is not sufficient protection. An authenticated attacker can still submit a hostile URL; one compromised account should not expose the authorization server’s internal network. Caching helps availability and request volume, but it cannot make a dangerous first fetch safe.

This is the operational exchange CIMD asks you to evaluate: less per-server registration negotiation, but a public metadata hosting dependency and a security-sensitive retrieval path. Neither side of that exchange is free.

Registration Still Does Not Authorise a Note#

Return to Naledi’s original request. Once the server accepts Notes Desktop’s metadata, it still needs the appropriate user authorization, redirect validation and code-flow protections. RFC 9700 section 2.1.1 mandates PKCE for public clients and recommends it for confidential clients. That distinction matters more than calling every desirable defence a universal mandate.

When the client eventually calls the notes service, the resource server must validate the trusted issuer, signature or authenticated introspection result, audience, expiry and scopes. It must then enforce user, tenant and object-level authorization. Access tokens need not be JWTs, and assuming every issuer provides an interchangeable sub claim is not an identity-mapping strategy.

If Naledi asks for another team’s note, a valid token and a correctly retrieved metadata document do not settle whether she may read it. The notes service’s sharing policy does. Registration, transaction security and resource authorization answer different questions.

If the authorization server is an Entra-backed proxy, there is another boundary: shared Entra consent does not approve every downstream client. The proxy must obtain explicit user-per-client consent before forwarding the downstream authorization request upstream. The companion walkthrough explains the separate states, codes and token lifecycles needed to preserve that decision.

Entra application creation can also be automated through Microsoft Graph. That privileged provisioning route is different from arbitrary-client interoperable registration. Check the actual deployment’s capabilities rather than treating every enterprise identity provider as having the same limitations.

The practical conclusion is modest. Prefer the reviewed MCP draft’s selection order, evaluate CIMD for portable metadata, and retain the controls that make authorization meaningful. These trade-offs explain the appeal of the draft’s direction; they do not establish a causal history of its authors’ decision. A deprecation is a reason to reassess your integration, not permission to replace one trust assumption with another.

DCR Does Not Require an Uncontrolled Registration Database#

CIMD Moves the Metadata to a Portable Address#

The Publisher’s Domain Is Not the Running Application#

Fetching Metadata Creates Its Own Boundary#

Registration Still Does Not Authorise a Note#

Further Reading#