Summary

Adds a draft SEP proposing RFC 9421 HTTP Message Signatures as an optional, additive proof-of-possession client-authentication mechanism for MCP. It supersedes the dormant SEP-1415 with the technical-feedback fixes from that thread, and is complementary to (not in competition with) SEP-1932 (DPoP).

Why this proposal

MCP currently authenticates clients with bearer tokens (OAuth access tokens, API keys, MCP-Session-Id). That model has well-known structural weaknesses that the rest of the web has been migrating away from:

1. Secrets are re-exposed to the server on every request. A signed request, by contrast, never sends the private key — the server sees only signatures it cannot replay or repurpose.
2. No protection against TLS-terminating intermediaries. CDNs, reverse proxies, and corporate egress inspection see bearers in plaintext. A signed request is verifiable end-to-end above TLS termination.
3. No request integrity. Bearer auth says nothing about the body; a signature over (@method, @target-uri, content-digest, mcp-protocol-version, mcp-session-id) binds the credential to this specific request.
4. No replay protection. Captured bearers are valid until rotation; created + nonce collapse that window to single-digit minutes.
5. No verifiable client identity. The signature tag provides a stable, unforgeable client identifier across key rotations.
6. Principle of least exposure. Stops handing clients access tokens really intended for server↔resource-server communication.

The acute use case is wallet-based and high-stakes authentication — MCP servers brokering on-chain transactions, payments, secret stores, or production database writes. A leaked bearer in those settings drains a wallet or exfiltrates secrets with no recovery. Proof-of-possession lets the wallet key itself become the natural MCP client credential.

What's different from SEP-1415

The 1415 thread surfaced a series of RFC-compliance issues that this draft addresses explicitly, with citations:

Relationship to in-flight work

• Supersedes dormant #1415.
• Complementary to #1932 (DPoP): DPoP for OAuth-bound flows, RFC 9421 for non-OAuth / wallet / API-key servers. Most wallet use cases fall in the latter bucket.
• Orthogonal to #1036 (URL elicitation).
• Compatible with #1372 (init-less MCP) via Signature-Agent.

Status

• Filed without a sponsor; seeking sponsor per the PR-based SEP workflow.
• Reference implementations (server-side Rust middleware on rmcp; client-side TypeScript fetch wrapper on the official SDK) planned and will be linked once a sponsor advances this to In-Review.

Checklist

• I have read the MCP Documentation
• SEP follows the format defined in SEP-1850
• Sponsor assigned (seeking)
• Reference implementation linked (planned, see §Reference implementation)

cc: potential reviewers from the closed 1415 thread who provided technical feedback: @dickhardt @jricher @dadrus @fsiyavud @spacewander @covia-dev — your input shaped this draft.