Identity Layer

Understanding identity for Agents

Identity & did's

Introduction to DIDs in MCP-I

MCP-I uses Decentralized Identifiers (DIDs) to uniquely identify both users and agents. These identifiers form the root of all verifiable authorization flows.

DIDs are globally unique identifiers that are:

  • Decentralized: Not dependent on a central issuing party
  • Persistent: Can remain stable over long periods
  • Cryptographically Verifiable: Enable proof of control without central authority
  • Resolvable: Can be resolved to metadata (DID Documents)

DIDs form the foundation upon which the delegation and verification systems are built. They provide a standardized way to represent identity across different systems and platforms.

What is a DID?

A Decentralized Identifier (DID) is a globally unique, self-describing identifier that can be resolved to a DID Document.

Each DID represents an entity and is associated with:

  • A public key (for verification)
  • Optional service endpoints
  • A verification method (e.g. Ed25519, EcdsaSecp256k1)

Example DID:

did:key:z6MkfY...AxM7

DIDs are encoded URIs and can be used in credential issuance, delegation, and audit.

DID Format and Components

DIDs follow the standard W3C format:

did:METHOD:SPECIFIC-IDENTIFIER

Where:

  • did: The scheme identifier
  • METHOD: The DID method (e.g., key, web, ion)
  • SPECIFIC-IDENTIFIER: Method-specific identifier string

Example DIDs

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
did:web:example.com
did:ion:EiAJVY_...

Supported DID Methods

MCP-I supports multiple DID methods out-of-the-box:

  • did:key — for local, fast, cryptographic identifiers
  • did:web — for domain-anchored identifiers, useful in enterprise systems
  • did:ion (experimental) — scalable and anchored to Bitcoin

DID Lifecycle in MCP-I

  1. Creation
    The DID Service is called to register a new DID. This generates a key pair and returns a DID Document.

  2. Resolution
    DIDs can be resolved at runtime by Edge Verifiers to retrieve public keys and service metadata.

  3. Usage
    DIDs are used:

DID Creation Example

curl -X POST https://your-mcp-server.com/did \
  -H "Content-Type: application/json" \
  -d '{
    "method": "did:key",
    "controller": "user@example.com"
}'

Returns:

{
  "did": "did:key:z6MkfY...AxM7",
  "publicKey": "Base58PublicKey",
  "privateKey": "Base58PrivateKey",
  "controller": "user@example.com"
}

DID Resolution at the Edge

Verifiers resolve DIDs to:

  • Validate credential signatures
  • Check issuing authority
  • Map trust policies to known issuers

For did:web, the verifier fetches:

https://yourdomain.com/.well-known/did.json

For did:key, the key is self-contained.

Details on resolver behavior and caching are covered in the Edge Verification Guide.

Security Considerations

  • DIDs must be bound to valid key material
  • DID rotation should trigger credential re-issuance
  • Services should validate method-specific constraints (e.g. domain ownership for did:web)
  • DID verification and trust policies are covered in Security & Compliance

Next Steps