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

4.1. did:web

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.¶

4.2. did:key

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.¶

4.3. Method Negotiation

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.¶

4.4. Local Transport Considerations

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.¶

5.1. Service Endpoint Types

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:¶

  "serviceEndpoint": {
    "type": "sse",
    "url": "https://mcp.example.com/sse",
    "headers": { "Authorization": "Bearer ..." }
  }
  

  ¶

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

  "serviceEndpoint": {
    "type": "stdio",
    "command": "node",
    "args": ["server.js"]
  }
  

  ¶

• 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):¶

{
  "id": "did:web:mcp.example.com",
  "verificationMethod": [{
    "id": "did:web:mcp.example.com#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:web:mcp.example.com",
    "publicKeyMultibase": "z6Mk..."
  }],
  "authentication": ["#key-1"],
  "service": [{
    "id": "did:web:mcp.example.com#mcp",
    "type": "MCPEndpoint",
    "serviceEndpoint": "https://mcp.example.com/sse"
  }]
}

5.2. Capability Declaration

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": [{
  "id": "did:web:mcp.example.com#mcp",
  "type": "MCPEndpoint",
  "serviceEndpoint": "https://mcp.example.com/sse",
  "capability": ["medical-llm", "diagnosis"]
}]

6.1. Deriving Server DID from Known URL

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.¶

6.2. DNS-Based Service Discovery

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:¶

  _mcp._tcp.medical.example.  IN SRV 10 60 443 mcp.medical.example.

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).¶

6.3. Directory Service Discovery

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.¶

GET /discover?capability=medical-llm
Accept: application/json

{
  "candidates": [
    {
      "did": "did:web:mcp.medical.example",
      "endpoint": "https://mcp.medical.example/sse",
      "capabilities": ["medical-llm", "diagnosis"],
      "reputation": 4.8
    },
    {
      "did": "did:key:z6Mk...",
      "endpoint": "https://mcp.medical.example/sse",
      "capabilities": ["medical-llm"],
      "reputation": 4.2
    }
  ]
}

6.4. Security and Trust of Service Discovery

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.¶

7.1. Initialize Extensions

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

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {},
    "clientInfo": { "name": "claude", "version": "1.0" },
    "identity": {
      "did": "did:key:z6Mk...",
      "authScheme": "did-auth-v1"
    }
  }
}

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.¶

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": { "auth": { "schemes": ["did-auth-v1"] } },
    "serverInfo": { "name": "mcp-server", "version": "1.0" },
    "identity": {
      "did": "did:web:mcp.example.com"
    }
  }
}

7.2. Authentication Challenge-Response

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:¶

  {
    "nonce": "base64url...",
    "serverDID": "did:web:mcp.example.com",
    "expires": "2026-08-14T12:00:00Z"
  }
  

  ¶

• 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.¶

7.3. Session Key Agreement (Optional)

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.¶

9.1. Point-to-Point Collaboration

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.¶

9.2. Orchestrator-Based Collaboration

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.¶

9.3. Agent Mesh and Decentralized Collaboration

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.¶

9.4. Shared Blackboard Coordination

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.¶

9.5. Challenges and Future Extensions

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.¶

10.1. Elimination of Client Pre-Registration and Shared Secrets

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.¶

10.3. Tokens with Built-in Verifiable Claims Reduce Authorization Server Callbacks

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.¶

10.4. Cross-Domain Interoperability and Federated Trust

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.¶

10.5. Decentralized Trust Model

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.¶

10.6. Privacy Enhancements and Minimal Disclosure

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.¶

10.7. Natural Synergy with MCP Agent Ecosystem

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.¶

10.8. Progressive Enhancement and Fallback Compatibility

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.¶