DID-Based Service Discovery, Authentication, and Authorization Framework for MCP Agents

The Model Context Protocol (MCP) provides a standardized interface for AI assistants to interact with external tools and data sources. However, the current MCP core specification does not define service discovery, authentication, and authorization mechanisms. In practice, API keys or OAuth 2.0 are often used. These approaches typically rely on centralized trust domains and lack cryptographic verification of Agent identity, cross-domain interoperability, and self-sovereign identity. This document defines a framework for service discovery, authentication, and authorization of MCP Agents based on the W3C Decentralized Identifier (DID) standard [DID-CORE]. The framework enables MCP Agents to: Discover the DIDs and service endpoints of Agents offering specific capabilities through standard mechanisms; Possess globally unique, self-resolvable identity identifiers; Carry verification public keys and service endpoints in DID Documents; Perform mutual authentication based on signed challenges; Support fine-grained authorization using Verifiable Credentials. This framework is compatible with existing MCP transports (stdio, HTTP+SSE) and does not alter the underlying JSON-RPC message structure. It only extends the initialize method and introduces new authentication methods.

This document uses the following terms: MCP Host: An application that creates and manages one or more MCP Clients, e.g., Claude Desktop. MCP Client: An entity created by an MCP Host to establish and maintain a connection to a specific MCP Server, providing the Host with access to the Server's tools, resources, and prompts. MCP Server: An entity that provides tools, resources, and prompts to MCP Clients. MCP Servers may run locally (e.g., via the STDIO transport) or remotely (e.g., via the HTTP+SSE transport). Agent: A generic term used in this document to refer to an MCP Client or MCP Server, which may be AI-driven or act on behalf of an AI system. DID: Decentralized Identifier, as defined in [DID-CORE]. DID Document: A JSON-LD document associated with a DID, containing verification methods (public keys and other verification material) and service endpoints. DID Resolver: A component that resolves a DID into a DID Document. VC: Verifiable Credential, as defined in [VC-DATA-MODEL]. VP: Verifiable Presentation, a proof presented by a VC holder to a verifier. Service Discovery: The process of obtaining one or more candidate Agent DIDs and associated metadata based on query conditions (such as capability tags or domain names). Directory Service: A service that stores and indexes the mapping between Agent capabilities and DIDs. It can be a centralized web service or a decentralized network.

This mechanism adds a service discovery layer and an identity layer to the existing MCP client-server model:

| MCP Client | ----> | MCP Server | | (Claude) | | (DID Identity)| | (DID Identity)| +---------------+ +---------------+ +---------------+ ^ | | | Service discovery | | | (optional) | | +-------------------------+----------------------+ (DNS / Directory / Local Config) ]]> Each MCP Client and MCP Server possesses a DID. Before authentication, the Client obtains the Server's DID via a service discovery mechanism (if not already known) and then resolves the DID Document to obtain public keys and service endpoints. The Client includes its DID in the initialize request. The Server resolves the Client's DID to obtain its public key and performs challenge-response authentication. After successful authentication, a trust context is established, allowing subsequent tool calls, resource reads, etc.

This framework supports multiple DID methods, but for interoperability, the following two are recommended:

Used for MCP Servers (and enterprise clients requiring long-term identity) with stable domain names and web servers. Format: did:web:<domain>[:path] DID Document location: Derived from the DID by converting to an HTTPS URL, for example: did:web:example.com resolves to https://example.com/.well-known/did.json did:web:example.com:mcp resolves to https://example.com/mcp/did.json Trust model: Domain ownership + TLS certificate verification. Advantages: Supports document updates, key rotation, dynamic service endpoint changes. Uniqueness: Based on the globally unique registration system of DNS domain names.

Used for temporary or local MCP Clients and Servers, requiring no external infrastructure. Format: did:key:<multibase encoded public key> DID Document: A minimal DID Document is constructed locally from the public key embedded in the DID string. No network request is required; the resolver extracts the public key and creates a document containing it as a verification method with an authentication relationship. Trust model: Cryptographic self-authentication. Limitations: Does not support document updates, revocation, or service endpoints. Uniqueness: Based on cryptographic randomness (e.g., Ed25519 public keys) with negligible collision probability.

In the initialize request and response, the identity field declares the DID method used. Both parties SHOULD support did:key resolution; if dynamic service endpoint discovery is required, the Server SHOULD use did:web.

When MCP communication occurs over a local transport such as STDIO (Client and Server on the same Host, often parent-child processes), the trust boundary is already provided by the operating system. In such cases: did:key is the preferred method for both Client and Server identities, as it requires no domain, no web hosting, and no service endpoint publication. The public key embedded in the DID is sufficient for authentication if needed. Authentication is OPTIONAL. A Server SHOULD only require DID authentication if it handles sensitive operations, runs in a multi-user environment, or requires cryptographic auditability. Otherwise, the local process boundary may be considered sufficient. The absence of a network endpoint means service discovery via DID Document endpoints is irrelevant; the Client already knows how to reach the Server through the local process invocation.

In addition to standard fields, the DID Document of an MCP Agent may include the following extensions:

The following service types are defined: MCPEndpoint: Represents the connection endpoint of an MCP Server or, optionally, a Client. serviceEndpoint can be a URL string (e.g., https://example.com/sse) or an object describing the transport type and any required parameters. For example:

For non-HTTP transports such as stdio, the object form may be used to describe the command and arguments:

MCPDirectory: Represents a directory service endpoint. A client may query this directory to obtain a list of other Agents' DIDs (see Section 6.3). MCPCredentialStatus: Optional, pointing to a credential revocation list (such as a StatusList2021 resource). Example (did:web server):

Optionally, a capability field may be included in the DID Document to declare the MCP capabilities (e.g., tools, resources) supported by the Agent. However, detailed capabilities are still discovered via MCP protocol methods such as tools/list. The DID Document only provides entry-level information. Example:

Service discovery addresses the question: "How to find the DID of Agents providing specific capabilities?" This framework categorizes service discovery into three levels:

This is the most basic and common mechanism. The Client already possesses a connection URL for an MCP Server, for example from user configuration or a previous session cache. The user configures the MCP Server's connection URL (e.g., https://mcp.example.com/sse). The Client derives the Server's DID from the URL (assuming the Server uses did:web): did:web:mcp.example.com. The Client resolves the Server's DID via a DID Resolver, obtaining the DID Document containing the Server's authentication public key and the MCPEndpoint service endpoint. This resolution may happen before or after establishing the MCP connection; either order is acceptable. The Client MAY verify that the MCPEndpoint in the Document matches the configured URL to detect endpoint mismatches (e.g., due to stale configuration, path errors, or potential phishing attempts). If verification is performed after connecting, a mismatch SHOULD cause the Client to terminate the connection. The Client uses the public key from the Document to verify the Server's signature in subsequent authentication. This verification only protects the initial connection against configuration errors. It does not prevent the Server from later updating its endpoint in the DID Document; if the Server changes its endpoint, Clients can re-resolve the DID and use the updated value for future connections.

When the Client does not know a specific Server URL but knows an entry domain or organizational domain, DNS records can be used to discover MCP Servers. An organization can publish SRV records under its domain indicating the location of MCP services:

The Client queries _mcp._tcp.medical.example to obtain one or more Server hostnames and ports. For each result, the Client constructs a connection URL (e.g., https://mcp.medical.example:443) and connects to it. If the Server follows did:web, its DID is automatically derived as did:web:mcp.medical.example, and the Client then resolves that DID to obtain the public key and confirm identity. Multiple SRV records may be returned, allowing the Client to discover multiple MCP service instances under the same domain. Each instance is handled independently. DNS record updates have latency (TTL), and DNSSEC is recommended to ensure record authenticity. This mechanism is suitable for locating services by domain but does not support capability-based queries; for that, use a directory service (Section 6.3).

For more flexible and scalable capability queries (e.g., "find MCP Servers with medical image analysis capabilities"), a dedicated directory service should be used. The directory service stores information such as Agent DIDs, service endpoints, capability tags, and reputation, and provides query interfaces.

The directory service itself can be discovered through one of the following methods: DNS SRV records: Publish records under a known domain's _mcpdir._tcp to point to the directory service. Organization DID's service field: An organizational DID (e.g., did:web:example.com) declares an "type": "MCPDirectory" service endpoint in its Document. Local configuration: The Client is preconfigured with one or more trusted directory service URLs or DIDs.

The directory service provides an HTTP API. The Client sends a capability query and receives a list of candidate Agents:

Response:

The Client selects one or more DIDs from the candidates and then performs subsequent DID resolution and authentication. Note that the endpoint provided by the directory service is for initial connection only; the Client MUST still resolve the DID and authenticate the Server.

The directory service can also be implemented using a Distributed Hash Table (DHT) or blockchain smart contracts to avoid a single point of failure. For example, a registration contract can be deployed on Ethereum, allowing service providers to register their DIDs and capability tags. Clients query the contract to obtain a list of DIDs. This approach offers higher censorship resistance but has higher query latency and state synchronization complexity.

Regardless of the discovery mechanism used, the Client MUST remain cautious about the discovery results: DNS queries: DNSSEC SHOULD be used to validate responses and prevent DNS hijacking or poisoning. Directory services: The directory service SHOULD have its own DID and sign query responses (e.g., using JWS or JWT). The Client verifies the directory service's signature to ensure responses are not tampered with. The directory service MAY use did:web and protect transport with TLS. Verifying candidate DIDs: After discovery, the Client MUST perform standard DID resolution and authentication, and MAY optionally require the Server to present a VC proving its capabilities. Replay prevention: The directory service's signed responses SHOULD include a timestamp or nonce to prevent replay attacks.

This section defines a mutual authentication process based on signed challenges. It is assumed that the Client and Server have established a transport connection (stdio or HTTP+SSE) and that the Client has already obtained the Server's DID via some service discovery mechanism (or derived it from the URL). For local STDIO transport, authentication is OPTIONAL. A Server that does not require authentication simply omits the authentication capability in its initialize response, and the Client proceeds without the challenge-response flow. This is common for single-user, low-sensitivity local tools.

The Client adds an identity field to the initialize request, declaring its DID and authentication scheme:

The Server MAY declare its own DID and supported authentication schemes in the initialize response. When the Server uses did:web and the Client has already derived its DID from the URL, this field MAY be omitted. When the Server uses did:key or other methods that cannot be derived from the URL, the DID MUST be provided in this field.

If the Server requires authentication, it SHOULD send a custom RPC request mcpauth/challenge (or use the standard ping extension) after receiving the Client's initialized notification. The challenge flow is as follows: The Server generates a random nonce (at least 16 bytes) and constructs a challenge object:

The Server signs the challenge object with its own private key and sends the challenge and signature to the Client. The Client verifies the Server's signature using the authentication public key obtained by resolving the Server's DID (for did:key, the public key is decoded directly from the DID string; for did:web, it is extracted from the DID Document). The Client constructs a response object containing the original challenge, its own DID, a timestamp, etc., and signs it with the Client's private key. The Client sends the signed response to the Server via the mcpauth/response method. The Server verifies the Client's signature using the public key obtained by resolving the Client's DID (for did:key, decoded directly; for did:web, extracted from the DID Document). If valid, authentication succeeds, and a trust context is established. Signature computation: Use the signature algorithm corresponding to the key type declared in the DID Document (e.g., Ed25519). The signature input is a normalized JSON (JCS) or a specific serialized byte string, to be defined in a subsequent document. Note on serverDID: The challenge message MUST include the server's DID (serverDID field), independent of whether the Client has already learned the DID through other means. This makes the challenge self-contained and allows the Client to resolve the Server's document without relying on prior context.

After successful authentication, the parties MAY perform a Diffie-Hellman key exchange using the keyAgreement key from the DID Document to negotiate a symmetric session key for encrypting subsequent messages (e.g., using JWE). This step is optional and mainly intended for high-security scenarios.

Authentication only verifies identity; authorization requires the use of Verifiable Credentials (VCs). A trusted Issuer (which has its own DID) issues a VC to an Agent, declaring its capabilities. Example:

After authentication is complete, the Server MAY require the Client to present a VP. The Client wraps the VC into a VP, signs it, and sends it via the mcpauth/authorize request. The Server verifies the VP's signature, the VC issuer's signature, and the revocation status, then decides which tools and resources are allowed based on policy. Detailed procedures are not expanded in this document; see [VC-DATA-MODEL] and [PRESENTATION-EXCHANGE].

While MCP is originally designed as a client-server protocol, the mechanisms defined in this document (service discovery, DID authentication, VC authorization) also enable various multi-agent collaboration patterns. This section describes several common scenarios and how the proposed mechanisms apply.

In the simplest multi-agent scenario, two Agents collaborate directly. Each Agent acts as both an MCP Client and an MCP Server: Agent A (e.g., a medical diagnosis assistant) needs a capability offered by Agent B (e.g., image analysis). A discovers B's DID via a directory service, resolves B's DID Document to obtain the MCPEndpoint, and connects as a Client. If B also needs a capability from A (e.g., patient data retrieval), B can connect to A's MCPEndpoint as a Client. Both sides verify each other's DID signatures. Authorization can be enforced via VCs presented during the mcpauth/authorize step. This pattern works well for ad-hoc, short-lived collaborations where both Agents can expose endpoints.

A more common pattern uses a central orchestrator Agent (e.g., a task planner) that coordinates several specialist Agents. The orchestrator acts as the sole Client, connecting to multiple Server Agents: The orchestrator discovers specialist DIDs (e.g., via a directory service) and establishes authenticated connections with each. The orchestrator decomposes a complex task, calls the relevant tools on each specialist Server, and aggregates the results. Specialist Agents do not need to communicate directly, simplifying connection management and trust. This pattern aligns with the existing MCP architecture and is straightforward to implement with the mechanisms herein. A single Host may manage multiple Client connections on behalf of the orchestrator.

For more complex scenarios, Agents may form a mesh network without a central coordinator. Each Agent can initiate connections to any other Agent it discovers: Service discovery (Section 6) allows an Agent to find peers based on capabilities. DID authentication (Section 7) ensures that each connection is mutually verified. VCs (Section 8) allow fine-grained, transitive authorization. For example, Agent A connects to B for translation; B needs terminology from C, so B connects to C; B then combines C's data with its own translation and returns the result to A. This multi-hop flow is possible because each Agent can act as both Client and Server. Challenges in this pattern include avoiding circular dependencies, managing connection lifecycles, and ensuring that authorization tokens propagate correctly. These issues require additional protocol extensions beyond the scope of this document.

Another collaboration model uses a shared "blackboard" service (an MCP Server) that multiple Agents (Clients) can read from and write to: The blackboard Server maintains a shared state (e.g., a task queue, partial results). Each Agent authenticates to the blackboard with its DID and is authorized via VCs to perform specific operations (e.g., claim a task, post a result). The blackboard can also act as a discovery hub by listing the DIDs of connected Agents. This model is useful for asynchronous collaboration, where Agents may not be online simultaneously, and for coordination in complex workflows.

While the mechanisms in this document provide a foundation for multi-agent collaboration, several open issues remain: Connection management: Agents that maintain many concurrent Client-Server connections need robust lifecycle management and error handling. Circular dependencies and deadlocks: Multi-hop calls may lead to cycles; protocols should include timeouts, cancellation, and transaction semantics. Standardization of collaboration primitives: MCP currently lacks built-in primitives for task delegation, negotiation, and result aggregation. These may be defined in future MCP extensions. Performance: Multiple DID resolutions and signature verifications can add latency; caching and session resumption are recommended. Trust propagation: In multi-hop scenarios, authorization must be carefully designed to prevent privilege escalation or impersonation. Despite these challenges, the combination of service discovery, DID authentication, and VC authorization described in this document enables a wide range of multi-agent collaboration patterns, from simple point-to-point calls to complex decentralized workflows.

Integrating DIDs into OAuth 2.0, especially in the context of MCP Agent interactions, provides several significant advantages over traditional OAuth 2.0 deployments.

Traditional OAuth 2.0 requires clients to be registered with the authorization server in advance, receiving a client_id and client_secret. The authorization server must maintain a database of registered clients and their credentials. With DIDs: Clients can identify themselves using a DID in the iss field of a client_assertion JWT, signed with the corresponding private key. The authorization server dynamically resolves the DID to obtain the public key and verifies the signature, eliminating the need for pre-registration. The reliance on shared secrets (client_secret) is removed, avoiding the complexity of distributing, storing, and rotating these secrets across multiple parties. In the open and dynamic MCP Agent ecosystem, this allows new Agents to connect to tool servers without manual registration, supporting plug-and-play interoperability.

Traditional OAuth 2.0 relies on shared secrets for client authentication, a mechanism that is widely recognized as weak and operationally inconvenient from a security standpoint. With DIDs: Asymmetric keys replace shared secrets: Even if Client credentials are compromised, an attacker cannot forge signatures without access to the private key. Key rotation is simplified: DID Documents (especially did:web) can be updated to reflect new verification methods. The authorization server automatically obtains the latest public key at each DID resolution, with no need for re-registration or manual key updates. Hardware security module support: DID private keys can be stored in HSMs, providing stronger protection than typical shared secrets, which are often stored as plaintext or weakly encrypted strings.

In traditional OAuth 2.0, a resource server often needs to call the authorization server's introspection endpoint to validate an access token. With Verifiable Credentials: The authorization server can embed VCs directly into JWT-formatted access tokens. Resource servers can locally validate the VC claims contained in the token (e.g., allowed tools, quotas) without real-time callback to the authorization server. This reduces latency, avoids single points of failure, and supports offline validation, which is beneficial in high-throughput or network-constrained MCP scenarios.

Traditional OAuth 2.0 usually operates within a single security domain, and cross-organization integration requires pre-established bilateral trust (e.g., exchanging client credentials, configuring signing keys). With DIDs: Clients and resource servers can rely on the DID of a trusted issuer as a trust anchor. As long as a verifier trusts an issuer (e.g., an organization's DID), it can accept VCs issued by that issuer without additional per-service configuration. This allows MCP Agents to securely carry authorization across multiple organizations and tool servers, promoting an open ecosystem.

The authorization Server is no longer the sole trust source; trust can be distributed along DID and VC chains: issuer DID -> VC -> Client DID. In multi-Agent MCP collaboration scenarios, this enables more flexible and distributed trust relationships, rather than routing all requests through a central OAuth server.

Traditional OAuth 2.0's broad scopes and correlatable client identities create privacy risks; DIDs mitigate these via pairwise identifiers and selective disclosure: Pairwise DIDs: Clients can generate different DIDs for different resource servers, preventing cross-service correlation of their behavior. Note that the ability to create multiple MCP clients per Host does not automatically solve cross-service correlation if all clients share the same identity; pairwise DIDs provide this privacy property. Selective disclosure: VCs can reveal only necessary attributes (e.g., proof of email access without exposing the specific email address or organizational details). This is more fine-grained than traditional OAuth scopes and tokens, aligning with data minimization principles.

Traditional OAuth 2.0 provides limited support for identity portability and bidirectional interaction. DIDs address these gaps while also strengthening auditability: Identity portability: An Agent's DID and private key can be securely migrated to a new device, and its VCs remain valid without re-authorizing all services. Service discovery integration: Authorization or resource servers can resolve a client's DID to discover its service endpoints, supporting bidirectional interactions (e.g., server-initiated sampling requests). Auditability and non-repudiation: DID signatures provide strong cryptographic evidence, facilitating auditing of Agent behavior and compliance.

Clients supporting DIDs can use client_assertion with VCs, while traditional clients can continue using client_secret. Resource servers can be incrementally upgraded to accept both modes, enabling smooth migration without disrupting existing integrations.

The MCP specification plans to support OAuth 2.0. This mechanism can coexist with OAuth 2.0: DID as client identity: In OAuth 2.0's client_assertion, the JWT's iss field is set to the DID and signed with the corresponding private key. The authorization server verifies the client by resolving the DID, without pre-registering shared keys. VC as authorization ticket: Embed the VC into the access token (JWT format). The resource server can locally validate the VC claims within the token, reducing callbacks to the authorization server. Fallback mechanism: Clients that do not support DID can continue using the standard OAuth 2.0 flow.

The following security considerations apply to the mechanisms described in this document: Key protection: Private keys MUST be stored securely; hardware security modules (HSMs) or operating system key stores are recommended. DID resolution security: did:web resolution depends on TLS; certificate chains and domain name matching MUST be validated. did:key has no network dependency and poses lower risk. Service discovery security: Use DNSSEC to protect DNS queries. Directory service responses SHOULD be signed, and the identity of the directory service itself MUST be verified. Clients SHOULD NOT fully trust unverified discovery results. Replay attacks: Challenge nonces MUST have an expiration time and SHOULD be recorded on the Server to prevent replay. Directory service signed responses SHOULD include a timestamp or nonce. Time synchronization: Signature verification depends on timestamps; both parties SHOULD use a reliable time source (e.g., NTP). DID Document updates: If a Server uses did:web, when keys are rotated, old public keys SHOULD remain valid for a transition period to avoid authentication failures. Privacy: DIDs may be correlated with specific entities. Pairwise DIDs can reduce linkability. Directory queries may leak Client intent; privacy protection mechanisms (such as obfuscated queries) SHOULD be considered. Denial of Service: Directory services may become attack targets; rate limiting and redundancy SHOULD be deployed. Local key isolation on the same host: When MCP Client and Server run on the same machine, especially under the same OS user, absolute isolation of private keys cannot be guaranteed. Default OS permissions do not prevent one process from reading another's memory or files if they share the same user. HSM authentication: When using an HSM to protect a private key, the HSM must authenticate the requesting process before allowing signature operations.

TBD