AI Meets Digital ID: Credential Issuance and Verification using MCP [Video and Takeaways]

AI agents are quickly moving from experimentation to real-world deployment, but one critical question remains: how do you establish trust when agents start acting on behalf of users?

In a recent webinar, Mike Parkhill (Head of Engineering at Dock Labs) and Agne Caunt (Product Owner at Dock Labs) explored this challenge and demonstrated how identity infrastructure can play a central role in solving it.

The session focused on Truvera’s MCP (Model Context Protocol) server, showing how agents can issue, verify, and eventually hold digital ID credentials, and how this enables more secure, auditable, and constrained agent behavior. Along the way, they walked through a live demo of credential issuance and verification, and shared their perspective on where agent identity, delegation, and agentic commerce are heading next.

Below are the key insights and takeaways from the session.

Why the Truvera MCP server was built

• AI agents are moving from experimentation into real deployment, creating a new problem: how an agent can prove something about itself or the person it represents.
  
  • This is fundamentally an identity problem that existing tools were not designed to solve.
• Model Context Protocol (MCP) is positioned as a standard way for agents to connect to external tools and services.
  
  • It enables actions like issuing digital ID credentials, verifying proofs, and managing decentralized identifiers (DIDs).
  • A useful analogy is a browser extension that gives an LLM capabilities it does not have natively.
• The goal is not simply enabling chat-based interaction with APIs.
  
  • The direction is toward identity infrastructure that agents can use directly in workflows based on human-delegated authority.

What the MCP server does today

• Two MCP components are being developed:
  
  • A digital ID issuance and verification server (available today)
  • A future wallet MCP server (not yet available)
• The current MCP server wraps existing Truvera REST APIs.
  
  • Only a subset of functionality is exposed:
    
    • Some capabilities are unnecessary for agents
    • Some are intentionally restricted for security
    • Some are more complex and not yet included
• The demo shows a full digital ID credential issuance flow:
  
  • Retrieve schema (e.g., proof of employment)
  • Use an issuer profile
  • Create an OpenID for VC issuance flow
  • Generate a credential offer
  • Import it into a wallet
  • The credential is assigned to a DID and becomes the holder’s credential
• The demo also shows a verification flow:
  
  • Use a proof template to define what needs to be verified
  • Create a proof request
  • Submit the credential from the wallet
  • Retrieve the result from the API
  • Verification succeeds and returns the relevant data
  • (In practice, the issuer and verifier would be separate entities. They were combined here for simplicity)
• Credentials follow standard formats:
  
  • W3C Verifiable Credentials (JSON-LD)
  • Support for other formats (e.g., SD-JWT)
  • Selective disclosure is supported, though not deeply shown in the demo

Where this is going next

• A wallet MCP server is planned:
  
  • Agents will be able to:
    
    • Store credentials
    • Expose their own DID
    • Respond to proof requests with credential presentations
  • This is part of the intended architecture, not yet implemented
• Movement toward agent-to-agent ecosystems:
  
  • Exploration of A2A (agent-to-agent protocol) for discovery and interaction
  • Use of DIDComm for encrypted communication between agents
  • These are forward-looking integrations
• Introduction of the Agentic Payment Protocol (AP2):
  
  • Designed to solve trust in agent-driven transactions
  • Core problem: proving that a human authorized an action and defining constraints
• Three key AP2 mandate types:
  
  • Cart mandate:
    
    • A specific purchase request (item, price, retailer, timing)
  • Intent mandate:
    
    • Constraints (budget, preferences) with more agent autonomy
  • Payment mandate:
    
    • Defines how the transaction is paid and links back to intent/cart
• Experimental AP2 flow demonstrated:
  
  • A cart mandate (e.g., Nike shoes, $145, Amazon) is issued as a credential to a wallet
  • This is an early-stage implementation, not a fully complete flow

How agent identity and delegation are framed

• Agent identity is still an open question, but likely core elements include:
  
  • Who published the agent
  • Who built the agent
  • A unique identifier per instance (e.g., a DID)
• Additional considerations:
  
  • Reputation may become relevant for long-lived agents
  • AI agent identity may be closely tied to human identity when acting on behalf of a person
• Human-to-agent delegation model (example discussed):
  
  • The human issues a credential to the agent
  • The agent holds that credential
  • The credential is signed by the human’s DID
• When interacting with other systems:
  
  • The agent presents the credential
  • This proves:
    
    • Who the agent is
    • Who authorized it
    • What it is allowed to do
• Delegation can include constraints:
  
  • Spending limits
  • Scope restrictions
  • Rules preventing re-delegation
• Strong emphasis on:
  
  • Traceability
  • Accountability
  • Ability to resolve disputes

Security and privacy model

• MCP introduces separation between agents and sensitive data:
  
  • Secrets (API keys, payment details, etc.) remain in the MCP server
  • Agents do not directly access this data
  • Reduces risks like prompt injection or data leakage
• Tool-based access control:
  
  • Agents can only use explicitly exposed tools
  • Prevents access to unnecessary or dangerous functionality
• Privacy vs auditability trade-off:
  
  • Systems must provide traceability for actions and delegation
  • While still preserving user privacy
  • Especially relevant in regulated environments like Europe

Standards, schemas, and DID methods

• The system is schema-agnostic:
  
  • Any credential schema available via MCP can be used
  • New protocols or schema versions can be adopted without redesigning the system
• Current DID approach:
  
  • did:cheqd is used because it supports:
    
    • Identity-specific features
    • Revocation management
    • Multiple signing key types
• Additional DID support:
  
  • did:key is supported (especially for holders)
  • Works for basic W3C credential flows
  • More advanced features (e.g., selective disclosure, multiple key types) require cheqd in the current setup
• Future direction:
  
  • Open to supporting additional DID methods (e.g., did:web)
  • Alignment with emerging standards and regulations (e.g., EUDI)

‍