Identity Layer

Introduction to DIDs in MCP-I

MCP-I uses Decentralized Identifiers (DIDs) to uniquely identify both users and agents. A DID is a globally unique, self-describing identifier that can be resolved to a DID Document. These identifiers form the root of all verifiable authorization flows.

Each DID represents an entity and is associated with:

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

DIDs 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 standardize identity representation in credential issuance, delegation, and audit, forming the foundation upon which delegation and verification systems are built.

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

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

Example DIDs

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

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:

   • As issuer or subject in Verifiable Credentials
   • In Delegation Chains
   • In audit logs (see Audit Layer)

4. Change in Key
   If keys are rotated or compromised, the DID document must be updated:

   • For did:web, update the .json file where the document is hosted
   • For did:key, generate a new DID (as did:key is immutable)

5. End of Life
   Keys either expire or are revoked by user:

   • did:web supports explicit deactivation, done by deleting the .json document where it is hosted
   • did:key must be replaced by a new did:key

DID Creation Example

Call DID Service to register a new DID:

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

Service returns a DID Document:

{
  "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
• Log verification outcomes
• Forward request to API

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

• Learn about the Delegation Layer to understand how identity is used for delegation
• Explore Credential Models to see how DIDs are incorporated into credentials
• Check Security & Compliance for best practices in identity management