ext-auth

Problem Definition Concrete Implementation Challenge: We are building a voice-based healthcare agent that needs to authenticate patients over phone calls. The current MCP OAuth specification requires browser-based redirects, which is impossible in a voice channel. Validation: This affects any MCP implementation where: Users interact through voice (IVR systems, voice assistants) CLI tools need authentication without launching browsers Embedded devices without browser capabilities Current Blocker MCP specification mandates OAuth 2.1 with browser redirects: This flow cannot work when: 1. No browser is available (phone calls) 2. Browser interruption breaks user experience (CLI tools) Minimal Proposed Change Allow MCP servers to optionally support programmatic authentication by adopting the OAuth 2.0 for First-Party Applications specification: 1. Add an optional field to Authorization Server Metadata (RFC8414): 2. When is present, clients can use the challenge/response flow as defined in the First-Party Apps draft. Why This Is Minimal 1. Single metadata addition: Just one optional endpoint in server metadata 2. Existing specification: Follows an established IETF draft rather than inventing new patterns 3. Backwards compatible: Only active when server advertises the endpoint 4. No protocol changes: Still uses authorization codes and standard token exchange Security Considerations Per the First-Party Apps specification: MUST only be used by first-party applications Authorization servers SHOULD restrict this endpoint to specific trusted client IDs All security requirements from Section 9 of the draft apply Use Case Example A voice agent could authenticate callers using knowledge-based authentication: Collect identity information (name, DOB, SSN last 4) POST to the challenge endpoint Receive authorization code Exchange for access token using standard flow Access MCP resources with the token Alternative Considered We considered using custom extensions, but that would fragment the ecosystem. Adopting an existing IETF draft enables broad use cases while maintaining compatibility. Prototype tell me which repo(s), if any, you want a protoytype created in, and I can make a PR. References OAuth 2.0 for First-Party Applications Draft MCP Authorization Specification OAuth 2.0 Authorization Server Metadata (RFC8414) Co authored by gregorySDTaylor and claude-sonnet-4

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 , 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 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 — 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 4. Challenge-Response — and 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