Summary
Reviving the discussion from the now-closed SEP-1415: HTTP Message Signing for MCP Client Authentication, which was marked dormant in January 2026 after failing to find a sponsor. The underlying problem — MCP's reliance on bearer tokens with no cryptographic client binding — remains unaddressed, and the in-flight SEP-1932: DPoP Profile for MCP is the closest proposal that would close the gap.
This issue re-surfaces the requirement with (a) a general argument for why cryptographic client authentication should be a first-class part of the MCP spec, not an optional extension, and (b) a concrete production use case that motivates urgency.
Why MCP needs cryptographic client authentication
Today MCP authenticates clients with bearer tokens (OAuth access tokens, API keys, MCP-Session-Id). A bearer is, by definition, whoever holds the string is the client. That model has well-understood structural weaknesses that the rest of the web stack has been quietly migrating away from for the last decade:
-
Secrets are continuously re-exposed to the server. Every request hands the full credential back to the server. A compromised, malicious, or merely curious server endpoint sees the same material the client uses to authenticate everywhere it presents that token. Cryptographic authentication inverts this: the private key never leaves the client. The server only ever sees signatures over specific requests — values that cannot be replayed or repurposed.
-
No protection against man-in-the-middle / intermediary trust. Bearer tokens rely entirely on TLS for confidentiality in transit. Anything that legitimately terminates TLS along the path — CDNs, reverse proxies, corporate egress inspection, logging middleware — sees the bearer in plaintext and can act as the client until rotation. A signed request, by contrast, is verifiable end-to-end: an intermediary can see the request but cannot mint a new signed request without the private key. This is the same property mTLS provides at the transport layer, but achievable above TLS termination, which is where most production deployments actually need it.
-
No request integrity. Bearer auth says nothing about the body. A signature over (@method, @target-uri, content-digest, ...) binds the credential to this specific request: changing the body, the method, the URI, or the session ID invalidates the signature. Tampering by a compromised proxy or malicious tool is detectable rather than silent.
-
No replay protection. A captured bearer can be replayed indefinitely until rotation, against any endpoint, with any payload. Signatures with a created timestamp + nonce (RFC 9421) or jti (DPoP / RFC 9449) constrain each signed request to a short freshness window and a single use, collapsing the leak blast radius from "until rotated" to single-digit minutes.
-
No verifiable client identity. The bearer model gives the server no cryptographic way to answer "is this the same client instance I talked to last time?" The keyid / jkt thumbprint from a public key gives a stable, unforgeable client identifier without requiring a heavyweight OAuth dance. This matters for any server that wants to make per-client policy decisions: rate limits, scoped permissions, audit logs, anomaly detection.
-
Principle of least exposure. OAuth flows currently leave MCP clients in possession of access tokens that were really intended for server↔resource-server communication. Proof-of-possession lets the spec stop handing clients credentials they didn't need in the first place.
None of these are theoretical. The same arguments drove the web's adoption of WebAuthn over passwords, DPoP over bare bearer tokens in OAuth 2.1, and HTTP Message Signatures (RFC 9421) in payment and federation protocols. MCP is currently the outlier.
Where this matters most: wallet-based and high-stakes authentication
A growing class of MCP servers brokers access to wallets and other high-value credentials on behalf of agents — signing EVM/Solana transactions, executing swaps, retrieving API keys, performing on-chain transfers, writing to production databases. For these servers the gaps above stop being theoretical and become unacceptable:
- A leaked bearer drains a wallet or exfiltrates secrets up to whatever policy limit exists. There is no recovery — the operation is on-chain or the data is out.
- Without request-body binding, an intercepted approval for
swap 100 USDC → ETH is indistinguishable from an attacker minting a fresh transfer everything → attacker against the same token.
- Per-client policies (code or LLM-based) are predicated on "this is client X" — which today reduces to "whoever holds the bearer."
Proof-of-possession solves all three: the request body is signed, the client is the keyholder, the bearer becomes worthless on its own. As a corollary, the wallet key itself becomes the natural MCP client credential — the agent's authenticator is the same key material it already uses to sign on-chain, eliminating an entire layer of out-of-band token provisioning.
This generalizes. Any MCP server fronting non-revocable or non-reversible side effects — payments, on-chain operations, production writes, secret stores — has the same threat profile. The bearer-only baseline is fine for read-mostly tools; it is not safe for anything where a single replayed request causes irreversible harm. As more financial and agentic infrastructure integrates over MCP (e.g. via Grok and Claude.ai connectors), the spec needs a proof-of-possession story that ships.
Proposed solution
I have filed #2752 — SEP-2752: HTTP Message Signing for MCP Client Authentication, which addresses all the technical feedback from the closed SEP-1415 thread (incorrect signed-component list, alg parameter risk, custom error envelopes, missing init-less / SEP-1372 story, no stable identity across key rotation) and is complementary to SEP-1932 (DPoP for the OAuth-bound case; this SEP for the broader non-OAuth case).
Ask
- Sponsor #2752, or alternatively prioritize merging SEP-1932 (DPoP). Both can ship; they cover different deployment shapes.
- Confirm the working group's stance so implementers can stop hand-rolling per-request HMAC schemes as interim mitigation.
References
Summary
Reviving the discussion from the now-closed SEP-1415: HTTP Message Signing for MCP Client Authentication, which was marked dormant in January 2026 after failing to find a sponsor. The underlying problem — MCP's reliance on bearer tokens with no cryptographic client binding — remains unaddressed, and the in-flight SEP-1932: DPoP Profile for MCP is the closest proposal that would close the gap.
This issue re-surfaces the requirement with (a) a general argument for why cryptographic client authentication should be a first-class part of the MCP spec, not an optional extension, and (b) a concrete production use case that motivates urgency.
Why MCP needs cryptographic client authentication
Today MCP authenticates clients with bearer tokens (OAuth access tokens, API keys,
MCP-Session-Id). A bearer is, by definition, whoever holds the string is the client. That model has well-understood structural weaknesses that the rest of the web stack has been quietly migrating away from for the last decade:Secrets are continuously re-exposed to the server. Every request hands the full credential back to the server. A compromised, malicious, or merely curious server endpoint sees the same material the client uses to authenticate everywhere it presents that token. Cryptographic authentication inverts this: the private key never leaves the client. The server only ever sees signatures over specific requests — values that cannot be replayed or repurposed.
No protection against man-in-the-middle / intermediary trust. Bearer tokens rely entirely on TLS for confidentiality in transit. Anything that legitimately terminates TLS along the path — CDNs, reverse proxies, corporate egress inspection, logging middleware — sees the bearer in plaintext and can act as the client until rotation. A signed request, by contrast, is verifiable end-to-end: an intermediary can see the request but cannot mint a new signed request without the private key. This is the same property mTLS provides at the transport layer, but achievable above TLS termination, which is where most production deployments actually need it.
No request integrity. Bearer auth says nothing about the body. A signature over
(@method, @target-uri, content-digest, ...)binds the credential to this specific request: changing the body, the method, the URI, or the session ID invalidates the signature. Tampering by a compromised proxy or malicious tool is detectable rather than silent.No replay protection. A captured bearer can be replayed indefinitely until rotation, against any endpoint, with any payload. Signatures with a
createdtimestamp + nonce (RFC 9421) orjti(DPoP / RFC 9449) constrain each signed request to a short freshness window and a single use, collapsing the leak blast radius from "until rotated" to single-digit minutes.No verifiable client identity. The bearer model gives the server no cryptographic way to answer "is this the same client instance I talked to last time?" The
keyid/jktthumbprint from a public key gives a stable, unforgeable client identifier without requiring a heavyweight OAuth dance. This matters for any server that wants to make per-client policy decisions: rate limits, scoped permissions, audit logs, anomaly detection.Principle of least exposure. OAuth flows currently leave MCP clients in possession of access tokens that were really intended for server↔resource-server communication. Proof-of-possession lets the spec stop handing clients credentials they didn't need in the first place.
None of these are theoretical. The same arguments drove the web's adoption of WebAuthn over passwords, DPoP over bare bearer tokens in OAuth 2.1, and HTTP Message Signatures (RFC 9421) in payment and federation protocols. MCP is currently the outlier.
Where this matters most: wallet-based and high-stakes authentication
A growing class of MCP servers brokers access to wallets and other high-value credentials on behalf of agents — signing EVM/Solana transactions, executing swaps, retrieving API keys, performing on-chain transfers, writing to production databases. For these servers the gaps above stop being theoretical and become unacceptable:
swap 100 USDC → ETHis indistinguishable from an attacker minting a freshtransfer everything → attackeragainst the same token.Proof-of-possession solves all three: the request body is signed, the client is the keyholder, the bearer becomes worthless on its own. As a corollary, the wallet key itself becomes the natural MCP client credential — the agent's authenticator is the same key material it already uses to sign on-chain, eliminating an entire layer of out-of-band token provisioning.
This generalizes. Any MCP server fronting non-revocable or non-reversible side effects — payments, on-chain operations, production writes, secret stores — has the same threat profile. The bearer-only baseline is fine for read-mostly tools; it is not safe for anything where a single replayed request causes irreversible harm. As more financial and agentic infrastructure integrates over MCP (e.g. via Grok and Claude.ai connectors), the spec needs a proof-of-possession story that ships.
Proposed solution
I have filed #2752 — SEP-2752: HTTP Message Signing for MCP Client Authentication, which addresses all the technical feedback from the closed SEP-1415 thread (incorrect signed-component list,
algparameter risk, custom error envelopes, missing init-less / SEP-1372 story, no stable identity across key rotation) and is complementary to SEP-1932 (DPoP for the OAuth-bound case; this SEP for the broader non-OAuth case).Ask
References