MCP-I Verification Handshake

To be considered MCP-I Conformance Level 2, recipient services MAY opt into receiving verifiable identity information about the agent and user making the request. At this level, services participate actively in the verification process rather than relying solely on an edge proxy.

This identity propagation is governed by the following logic:

By default, the Edge Proxy can validate the VC and forward the requests without retaining identity headers (Level 1 behavior).

If the downstream service declares MCP-I support (via domain config or headers), the edge MAY include:

• X-Agent-DID
• X-User-DID
• X-Agent-Reputation-Score (optional)
• X-Verified-Delegation (a signed payload or VC hash reference)

The agent MAY directly present a VC to the downstream service if the service supports a handshake flow (e.g., signed challenge-response).

Note: To qualify for MCP-I Level 3, both the Agent and MCP-I Aware service that supports Direct credential challenge-handling must implement the full JSON-RPC challenge-response protocol with cryptographic verification as described in this section.

MCP-I Identity Handshake Protocol

The Discovery Phase

Before the handshake begins, the agent must discover if a service is aware of it (MCP-I):

1. DID Discovery: Attempt to resolve the service's DID Document. Agents SHOULD first attempt to resolve the service's did document.

   1. Parse the service’s DID (e.g. did:web:awesome-airlines.com).
   2. Perform a DID resolution (per the W3C DID Core spec), which for did:web means an HTTP GET to: https://awesome-airlines.com/.well-known/did.json.
   3. From the resolved did, read any serviceEndpoint, entries whose type is mcp-i or JSON-RPC. These URIs become the default handshakeand verify endpoints.
   4. Also pull the service's public key(s) from the verificationMethod section to know which signature algorithms it supports.

2. Well-Known Discovery: Agents SHOULD perform an HTTP GET on: https://{service.host}/.well-known/mcp-i.json.

   • If the file exists (200 OK + valid JSON), parse its mcp_i block and pull endpoints & supportedMethods.
   • If it's missing or invalid (404 or parse error), fall back to DID Discovery or edge-proxy only (Level 1).

3. Explicit Configuration: Use pre-configured endpoints

{
  "mcp_i": {
    "version": "2.0.0",
    "endpoints": {
      "handshake": "/api/mcp/handshake",
      "verify": "/api/mcp/verify",
      "reputation": "/api/mcp/reputation"
    },
    "supportedMethods": ["Ed25519", "secp256k1"]
  }
}

Handshake Process

Identifying an agent

Technical Implementation

The MCP-I identity handshake uses standard JSON-RPC 2.0 messages as defined by the MCP transport specification:

...
Agent: I am Helpful Travel Agent, here to book travel.
My public reputation key is [public key]
...
Airline: Perfect. Here's a challenge. [nonce]
Agent: Reply: [signed data]
...
Airline: Looks good. What account are we dealing with today?
Agent: Jordan Morgan. Frequent flyer number 123456789
...
Airline: It looks like I don't have you authorized to work on that account.
Please redirect Jordan to [url] for authorization

Handshake Protocol Messages

Initial Handshake Request

{
  "agentDid": "did:example:agent456",
  "supportedMethods": ["Ed25519", "secp256k1"],
  "version": "1.0"
}

Challenge Response

{
  "challenge": "a0b1c2d3e4f5...",
  "nonce": "6789012345...",
  "supportedMethods": ["Ed25519"],
  "expiresIn": 300
}

Authentication Response

{
  "signedChallenge": {
    "challenge": "a0b1c2d3e4f5...",
    "nonce": "6789012345...",
    "timestamp": "2025-06-15T18:30:45Z",
    "agentDid": "did:example:agent456",
    "proofValue": "z6MkhaXgBZD..."
  },
  "credential": {
    // Full delegation credential
  }
}