CIMD
An emerging client identity authentication scheme for MCP that provides client identification information through a metadata document. Proposed as an alternative to DCR dynamic registration, it aims to address problems of client registration proliferation and lack of verification in MCP deployment scenarios.
Timeline (last 90 days)
The CIMD mechanism complements the dynamic client registration (DCR) and client assertions (private_key_jwt) already present in the OAuth ecosystem.
Even when combined, the four OAuth extensions still cannot express cross-agent delegation chain traceability in a standardized way.
None of the four extensions provides a unified answer for scenarios such as permission downgrade during refresh of long-running tasks and task interruption recovery.
CIMD suits agent deployment scenarios with a large number of clients that require dynamic management.
The MCP specification wording indicates that DCR may be used, but CIMD should be used where possible.
The core idea of CIMD (Client ID Metadata Document) is to make the client ID itself an HTTPS URL pointing to a metadata document, rather than a randomly generated string.
In Sam Welland's demo, DCR generates a new application on the authorization server over and over again upon repeated disconnections and reconnections, whereas CIMD always reuses the same application.
DCR is best suited for long-lived clients, while CIMD is best suited for ephemeral temporary agents and MCP client-server scenarios.
In the CIMD scheme, the client exposes a client.json document for the authorization server to fetch and inspect; the registration step is eliminated entirely and the authorization server does not need to store anything.
The root of trust that CIMD relies on is the PKI system of HTTPS itself, replacing a centralized registry with domain name ownership.
1 more timeline events
All Facts (11)
CIMD suits agent deployment scenarios with a large number of clients that require dynamic management.
50%UnverifiedThe CIMD mechanism complements the dynamic client registration (DCR) and client assertions (private_key_jwt) already present in the OAuth ecosystem.
50%UnverifiedEven when combined, the four OAuth extensions still cannot express cross-agent delegation chain traceability in a standardized way.
50%UnverifiedNone of the four extensions provides a unified answer for scenarios such as permission downgrade during refresh of long-running tasks and task interruption recovery.
50%UnverifiedThe MCP specification wording indicates that DCR may be used, but CIMD should be used where possible.
50%UnverifiedThe core idea of CIMD (Client ID Metadata Document) is to make the client ID itself an HTTPS URL pointing to a metadata document, rather than a randomly generated string.
50%UnverifiedDCR is best suited for long-lived clients, while CIMD is best suited for ephemeral temporary agents and MCP client-server scenarios.
50%UnverifiedIn the CIMD scheme, the client exposes a client.json document for the authorization server to fetch and inspect; the registration step is eliminated entirely and the authorization server does not need to store anything.
50%UnverifiedThe root of trust that CIMD relies on is the PKI system of HTTPS itself, replacing a centralized registry with domain name ownership.
50%UnverifiedCIMD does not provide guarantees of client code integrity; it can only prove that the request came from the domain name owner and cannot verify whether the client code has been tampered with.
50%UnverifiedIn Sam Welland's demo, DCR generates a new application on the authorization server over and over again upon repeated disconnections and reconnections, whereas CIMD always reuses the same application.
50%