Cryptographic key pairs - are they always controlled by the client or also by the operating environment (e.g., via TPM-bound processes)?

@localden the client can use key pairs stored in hardware (like TPMs), or otherwise. The DPoP spec does not specify how key pairs should be managed or stored.

"Control" here means it is able to generate a DPoP proof through access to the keys (even on the OS, that is often only through a handle to the key, not the actual key - depending on the cryptographic sub-system your using).

I keep referring to the RFC and I am not sure why we need to do things differently for MCP here. The RFC does leave room for extensibility, I am trying to see what we'd be gaining here in terms of attack prevention that is not covered by baseline DPoP.

@localden - It think this is 100% the right question. The idea was to bind the proof not only to the access token (ath claim) and the HTTP target URI (htu claim) but the actual request message content so that a stolen proof+access token cannot be re-used with different requests that may be sending vastly different messages to the MCP server.

The alternative is to use the nonce capabilities to always force a freshness check - there is some discussion on that further down.

Theoretically, yes, but how frequently is this a risk and in what environments? I generally try to err on the side of simplicity.

@localden Token theft has proven to be a popular attack vector. This may be something that is only relevant to enterprises, hence making it part of the auth extensions rather than the core spec.

Do you think it should be part of the core spec as "vanilla" DPoP as well?

I am still not entirely sure why this needs to be MCP-specific rather than generic DPoP that prevents token exfiltration?

Sure, but let's say that's all we use - I still have a token that cannot be exfiltrated off the device (which is the core benefit of DPoP). Replay attacks on the same device seem like a risk, but a significantly lower one, because it implies another level of compromise.

My main worry here is that we'd be adding a bunch of overhead to generate content digests with every request, for little gain.

Sure, but let's say that's all we use - I still have a token that cannot be exfiltrated off the device (which is the core benefit of DPoP). Replay attacks on the same device seem like a risk, but a significantly lower one, because it implies another level of compromise.

@localden - I expect that if you can move the access token off device, you can move the proof as well (both could also be lifted from other sources, like log files or when transiting break and inspect proxies). If we go for a stateless implementation the jti of the proof will not be checked, so you could replay both, with a different message, which I understood to be undesirable.

If we are willing to accept state (jti checking) perhaps we can make the argument that even if you steal both, the proof replay becomes detectable, so we can stick wit vanilla DPoP.

Server supplied nonces would also do the trick as it would force the proofs to be unique per message, so replay of proofs is not viable. I highlighted some options in the "Open questions" section which would rely on server supplied nonces. Repeating here for convenience:

1. Server supplied nonces: A server-supplied nonce mechanism is generally not recommended because it often requires servers to maintain state (e.g., tracking which nonces have been issued and used). An alternative is a stateless nonce design, where the server provides a nonce constructed from predictable values such as the current time prefixed to a salted hash of the current time and a client_id. This provides a freshness guarantee without requiring nonce storage. The server simply accepts any nonce within a defined time window. This could provide a significant improvement in replay protection because the nonce’s validity is tied to its short lifetime while potentially cryptographically bound to the client (or other information). This approach avoids the need for additional content-hashing requirements and would eliminate the need for MCP-specific modifications to DPoP implementations, at the cost of an extra round-trip at the start of an MCP client/server interaction. We invite discussion on whether this stateless-nonce approach could serve as a viable alternative to introducing content digests.

My main worry here is that we'd be adding a bunch of overhead to generate content digests with every request, for little gain.

Agreed ther eare lots of upsides to "vanilla" DPoP. How do you feel about keeping state (jti) or nonces (maybe without state, but an extra pass to get the initial nonce) to get the per message proof characteristic?