FAQ

Common questions and answers about MCP-I implementation, security, and best practices

Frequently Asked Questions

General Questions

What is MCP-Identity (MCP-I)?

MCP-I (Model Context Protocol - Identity) is an extension to the Model Context Protocol that provides a standardized framework for secure, verifiable identity and delegation for AI agents. It enables cryptographically verifiable proof that an agent is acting with appropriate authorization from a human or organization.

How does MCP-I relate to the core Model Context Protocol?

MCP-I extends the core Model Context Protocol by adding identity, delegation, and verification layers. While the core MCP defines how agents interact with services, MCP-I ensures that these interactions have proper identity verification and authorization.

What problem does MCP-I solve?

MCP-I addresses the "Know Your Agent" (KYA) problem by providing a standardized way to:

  1. Verify the identity of AI agents
  2. Validate their delegation authority from users
  3. Enforce scope-limited permissions
  4. Create auditable records of agent actions
  5. Manage agent reputation and trustworthiness

What are the conformance levels in MCP-I?

MCP-I defines three conformance levels:

Level 1 (Agent):

  • The agent has a stable DID, registered during initialization.
  • It may include a verifiable credential, but no user identity is required.
  • Delegation is optional and can use legacy identifiers (e.g., OAuth JWTs).

Suitable for: lightweight integrations, non-sensitive workflows, local MCP Servers.

Level 2 (Agent + User):

  • Both agent and user have DIDs, and the user issues a Verifiable Credential to the agent.
  • The credential is verified at the edge per request.
  • Supports revocation, expiration, and scoped access.
  • Audit logs, delegation chain resolution, and credential verification are enforced.

Suitable for: real-world apps, sensitive data access, identity-backed transactions, regulatory compliance for Agentic services.

Level 3 (Agent + User + Service):

  • All parties (agent, user, and recipient service) have DIDs and are MCP-I aware.
  • Full VC lifecycle management, including issuance, revocation, and selective disclosure.
  • Recipient services may enforce fine-grained policies based on delegation metadata.
  • Supports credential-to-token bridging for OAuth 2.1 compatibility.
  • Immutable audit trails, providing anomaly detection and reputation-aware access control.

Suitable for: regulated sectors (finance, healthcare), zero-trust architectures, interoperable agent ecosystems, service providers.

Who should implement MCP-I?

MCP-I is relevant for:

  • Developers building AI agent systems
  • Service providers offering resources to AI agents
  • Organizations deploying or integrating with AI agents
  • Security teams responsible for AI governance
  • Anyone concerned with the security and accountability of autonomous AI systems

Implementation Questions

What technical components do I need to implement MCP-I?

A complete MCP-I implementation typically includes:

  1. DID management system
  2. Credential issuance and verification components
  3. Delegation flow handling
  4. Verification service or edge proxy
  5. Audit logging system
  6. Revocation management

Which DID methods should I use?

The recommended DID methods depend on your use case:

  • For ephemeral agents: did:key (simple, self-contained)
  • For persistent agents: did:web (domain-bound, easy to manage)
  • For high-security applications: did:ion or similar (blockchain-anchored)

How do I integrate MCP-I with existing identity systems?

MCP-I can integrate with existing identity systems through:

  1. Mapping existing identifiers to DIDs
  2. Converting tokens (OAuth, SAML) to verifiable credentials
  3. Implementing an Edge Proxy for credential verification
  4. Using credential bridges for legacy systems

See the Compatibility & Legacy page for detailed guidance.

What libraries can I use to implement MCP-I?

Several libraries can help implement MCP-I components:

For JavaScript/TypeScript:

  • did-resolver and method-specific resolvers
  • @transmute/vc.js or @digitalbazaar/vc-js
  • @veramo/core and related packages

For Python:

  • didkit
  • pyld for JSON-LD processing
  • py-multibase for DID encoding/decoding

For Java:

  • uniresolver-client
  • verifiable-credentials-java
  • did-auth-java

How do I handle key management?

Key management depends on your conformance level:

  • Level 1: Use standard secure storage with encryption
  • Level 2: Implement hardware-backed key storage when available
  • Level 3: Use HSMs or TEEs for critical keys

In all cases, implement proper key rotation, access controls, and auditing.

Security Questions

How secure is MCP-I compared to traditional authentication?

MCP-I offers several security advantages over traditional authentication:

  1. Cryptographic verification instead of token checking
  2. Explicit delegation with fine-grained scope
  3. Comprehensive audit trails
  4. Delegation chains with transitive verification
  5. Verification without central authorities (in some configurations)

What happens if a private key is compromised?

If a private key is compromised:

  1. Immediately revoke all credentials signed with that key
  2. Generate a new key pair and update the DID Document
  3. Issue new credentials with the new key
  4. Audit all actions performed during the potential compromise period
  5. Notify affected parties as appropriate

How do I securely deploy an MCP-I system?

Secure deployment practices include:

  1. Following the principle of least privilege
  2. Implementing proper network segmentation
  3. Using TLS for all communications
  4. Implementing secure key storage
  5. Regularly auditing and monitoring system activities
  6. Keeping dependencies updated
  7. Conducting regular security assessments

What are the common security pitfalls?

Common security pitfalls include:

  1. Inadequate key protection
  2. Insufficient verification of credential chains
  3. Missing revocation checks
  4. Poor scope validation logic
  5. Inadequate audit logging
  6. Insecure handling of cryptographic material
  7. Vulnerabilities in DID resolution processes

Operational Questions

How do I handle credential revocation?

For credential revocation:

  1. Implement a revocation service using StatusList2021 or a similar mechanism
  2. Ensure verifiers check credential status at appropriate intervals
  3. Consider notification mechanisms for urgent revocations
  4. Implement proper access controls for revocation operations
  5. Maintain audit trails of revocation events

How do I scale an MCP-I implementation?

Scaling strategies include:

  1. Caching DID documents and verification results
  2. Implementing efficient credential verification
  3. Using distributed verification services
  4. Optimizing revocation checking with batching and caching
  5. Implementing asynchronous audit logging
  6. Using load balancing for verification services

What monitoring should I put in place?

Effective monitoring includes:

  1. Credential verification metrics (success/failure rates)
  2. Revocation service availability
  3. Verification latency measurements
  4. Audit logging performance
  5. DID resolution performance
  6. Security-related events (e.g., multiple failed verifications)
  7. System resource utilization

How do I troubleshoot verification failures?

When troubleshooting verification failures:

  1. Check the specific error returned by the verifier
  2. Verify credential structure and format
  3. Confirm the DID can be resolved
  4. Validate the signature using the correct verification method
  5. Check for credential expiration
  6. Verify revocation status
  7. Confirm scope permissions match the requested action

Integration Questions

Can MCP-I work with OAuth/OIDC?

Yes, MCP-I can integrate with OAuth/OIDC in several ways:

  1. Mapping OAuth tokens to MCP-I credentials
  2. Using OAuth for principal authentication while using MCP-I for agent delegation
  3. Implementing credential-to-token bridges for legacy services
  4. Supporting legacy identity in Level 1 implementations

How do I migrate from a traditional system to MCP-I?

Migration typically follows these steps:

  1. Start with a Level 1 implementation alongside existing systems
  2. Map existing identities to DIDs
  3. Convert existing permissions to delegation credentials
  4. Implement an Edge Proxy for credential verification
  5. Gradually transition services to native MCP-I verification
  6. Phase out legacy systems as adoption increases

Does MCP-I work with WebAuthn/FIDO2?

Yes, MCP-I can integrate with WebAuthn/FIDO2:

  1. WebAuthn can be used for secure principal authentication
  2. FIDO2 keys can be used for credential signing
  3. WebAuthn attestations can be incorporated into the identity verification process
  4. FIDO2 can provide the hardware-backed key protection required for Level 2+

Can I use MCP-I in a multi-tenant environment?

Yes, MCP-I works well in multi-tenant environments:

  1. Each tenant can have separate issuer DIDs
  2. Tenant-specific credential schemas can be defined
  3. Verification policies can be tenant-specific
  4. Audit logs can be segregated by tenant
  5. Revocation services can be tenant-aware

Technical Details

How are DIDs resolved in MCP-I?

DIDs are resolved according to their specific method specifications:

  1. did:key resolution is typically done locally by parsing the encoded public key
  2. did:web resolution involves an HTTP(S) request to fetch the DID document
  3. did:ion and other methods may require specialized resolvers
  4. Universal resolvers can be used for multiple method support
  5. Resolution results are often cached for performance

What is the structure of a delegation credential?

A delegation credential follows the W3C Verifiable Credential format with these key components:

  1. @context array with required context URLs
  2. type array including "VerifiableCredential" and a delegation-specific type
  3. issuer field with the principal's DID
  4. credentialSubject object with:
    • id field containing the agent's DID
    • scope array defining permitted actions
    • Optional constraints object with additional limitations
  5. issuanceDate and expirationDate fields
  6. credentialStatus object for revocation information
  7. proof object containing cryptographic proof of authenticity

How do I define appropriate scopes?

Effective scope definition follows these principles:

  1. Use the action:resource format (e.g., read:email)
  2. Follow the principle of least privilege
  3. Be as specific as possible while remaining manageable
  4. Consider resource hierarchies (e.g., read:calendar/events)
  5. Use wildcards sparingly and only when appropriate
  6. Include constraints for additional limitations

How does verification performance impact my system?

Verification performance considerations include:

  1. DID resolution can be computationally expensive
  2. Signature verification requires cryptographic operations
  3. Revocation checking may involve network requests
  4. Caching strategies are essential for production systems
  5. Hardware acceleration can help with cryptographic operations
  6. Performance requirements increase with request volume

Regulatory and Compliance

How does MCP-I help with regulatory compliance?

MCP-I supports regulatory compliance through:

  1. Identity Verification: Meeting KYC/KYB requirements for AI systems
  2. Audit Trails: Supporting accountability requirements
  3. Access Controls: Enforcing data protection guidelines
  4. Delegation Records: Establishing clear responsibility chains
  5. Revocation Mechanisms: Enabling prompt termination of access

Is MCP-I compliant with the EU AI Act?

MCP-I is designed to support EU AI Act compliance:

  1. It enables transparent identification of AI systems
  2. It provides clear delegation chains showing human oversight
  3. It supports comprehensive logging for accountability
  4. It enables proper risk management through scope limitations
  5. It facilitates technical documentation requirements

How does MCP-I handle privacy considerations?

MCP-I addresses privacy considerations through:

  1. Minimizing personally identifiable information in credentials
  2. Supporting selective disclosure in Level 3 implementations
  3. Enabling privacy-preserving verification
  4. Providing fine-grained control over delegation scope
  5. Supporting privacy-friendly DID methods

Can MCP-I help with GDPR compliance?

Yes, MCP-I can support GDPR compliance:

  1. It enables clear data processing authorization
  2. It provides audit trails of data access
  3. It supports revocation for withdrawing consent
  4. It enforces purpose limitation through explicit scopes
  5. It enables data minimization through selective disclosure

Miscellaneous

Where can I find reference implementations?

Reference implementations and resources are available at:

  1. KnowThat.ai MCP-I Reference
  2. The KYA-OS SDK coming soon.
  3. Community implementations listed in the MCP-I GitHub repository

How can I contribute to the MCP-I specification?

You can contribute to MCP-I development by:

  1. Providing feedback on the specification
  2. Participating in the working group discussions
  3. Contributing to reference implementations
  4. Sharing implementation experiences and challenges
  5. Proposing extensions or improvements

Who is behind the MCP-I specification?

MCP-I is developed by a community of organizations and individuals focused on AI agent security, including:

  1. Contributors from leading AI research organizations
  2. Identity and security experts
  3. Practitioners from various industries
  4. Standards organization representatives
  5. Open-source contributors

Where can I get support for MCP-I implementation?

Support resources include:

  1. The MCP-I community forum
  2. The MCP-I GitHub issue tracker
  3. Commercial support from implementing organizations
  4. Community chat channels (Discord, Matrix)
  5. The KnowThat.ai knowledge base

How is MCP-I versioned and how will it evolve?

MCP-I follows semantic versioning:

  1. Major versions indicate breaking changes
  2. Minor versions add features in a backward-compatible manner
  3. Patch versions include backward-compatible fixes

The specification is expected to evolve based on:

  1. Implementation feedback
  2. Emerging security requirements
  3. Advancements in decentralized identity standards
  4. Regulatory developments
  5. New AI agent capabilities and use cases