Extension: Server Identity and Tool Attestation

[thebenignhacker]

Summary

• Defines an optional extension for cryptographic server identity and tool attestation in MCP
• Ed25519 key pairs for server identity, self/publisher/DNS attestation types, tool definition signing via _meta, challenge-response verification, and key revocation
• Complements existing auth extensions (Client Credentials, Enterprise-Managed Authorization) by addressing server-to-client identity verification

Motivation

MCP has no mechanism for clients to verify server identity or detect tool definition tampering. The OWASP MCP Top 10 identifies related risks:

• MCP03 — Tool Poisoning (tool definition tampering)
• MCP04 — Supply Chain Attacks (no provenance chain)
• MCP07 — Insufficient Authentication (no mutual auth)
• MCP09 — Shadow MCP Servers (server impersonation)

Existing auth extensions solve client-to-server authorization. This extension solves the complementary problem: server-to-client identity.

Context

This was originally submitted as SEP-2267 to the core spec repository. Per maintainer guidance from @localden, this extension belongs in ext-auth rather than the core spec.

The document has been reformatted to follow the ext-auth extension conventions (MDX format, numbered sections, parameter tables, RFC keyword styling).

What's Included

• specification/draft/server-identity-attestation.mdx — Full extension specification

Extension capabilities:

1. Server Identity — Ed25519 key pairs in JWK format, identity metadata
2. Attestation Types — Self (TOFU/key pinning), publisher (third-party signing), DNS (domain binding)
3. Tool Attestation — Cryptographic signatures over tool definitions via _meta
4. Challenge-Response — identity/get and identity/challenge JSON-RPC methods
5. Key Revocation — Revocation attestations and key rotation

Backward Compatibility

All new fields and methods are additive. Servers that do not implement this extension are unaffected. Clients that do not support it ignore the identity metadata. Existing OAuth mechanisms continue to work unchanged.

References

• OWASP MCP Top 10
• Invariant Labs: MCP Tool Poisoning Attacks
• RFC 7517: JSON Web Key
• RFC 8785: JSON Canonicalization Scheme
• RFC 8032: EdDSA

[thebenignhacker]

Hello maintainers, any feedback?

[thebenignhacker]

@pcarleton @localden: a process question, following up on the redirect that brought this here.

This extension was filed per the guidance closing SEP-2267 (core spec to ext-auth). Reading the Governance section of this repo's README, authorization extensions follow the same SEP / community-discussion / consensus process as the core spec. So the direct question: what is the right form for a new extension to enter triage? An ext-auth-scoped SEP, a discussion thread first, or review on this PR as filed? I would rather restructure it to fit the process than have it sit in the wrong shape.

Since filing, the surrounding ecosystem work this extension composes with has firmed up:

• did:opena2a is registered in the W3C DID method registry (Register did:opena2a method w3c/did-extensions#717). That provides a resolvable identifier layer with key-rotation history and revocation status that the extension's key-revocation model can anchor to.
• Agent authorization observability is active in the OpenTelemetry GenAI semantic conventions (feat(gen-ai): add agent authorization observability attributes (#180) open-telemetry/semantic-conventions-genai#291), with a production implementation emitting identity and attestation signals (feat(fga): emit gen_ai.agent.* authorization attributes on the fga.authorize span opena2a-org/agent-identity-management#324, merged).
• A parallel identity-verification discussion in A2A (Proposal: Agent Identity Verification and Trust Framework a2aproject/A2A#1497) is converging on the same layering this extension uses: identity proof, attestation, and revocation state as separate concerns.

The problem statement has not moved: clients still cannot verify server identity or detect tool-definition tampering (OWASP MCP03/04/07/09). Happy to bring this to a WG call if that is the faster route.