Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 39 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

@PieterKas @D-McAdams confirming directly in the SEP - this is ready for review, right?

@PieterKas @D-McAdams confirming directly in the SEP - this is ready for review, right?

Yes, this SEP is ready for review.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 18 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Will connect with Den on next steps. Not sure of the current process for broader review.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 20 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

The DPoP specification was renamed from "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer" to "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" when it was published as RFC 9449. (cf. the diff between draft 16 and RFC 9449)

Therefore, occurrences of the old name in this PR should be updated.

Is the intent to sign the entire payload? There was some discussion at one point about only signing part of the payload, which I think is a very bad idea. Also, my understanding of DPoP might be flawed, but this only prevents replay attacks for idempotent requests, right? One could replay an intercepted, signed, message and thus perform a tool call with the same payload?

My worry about this is that the semantics of HTTP and MCP are at different levels of abstraction and what is not a replay in HTTP (accessing the same resource) could be a replayed in MCP (calling the same tool with the same parameters). The short life time of tokens creates some protection, but we're already dealing with a compromised HTTPS connection for this to even be possible, right?

I would also suggest not using the verbiage "Accessing MCP server resources". This is a very HTTP-ish way to put it and may cause confusion as an MCP resource is something very specific and unrelated to this SEP. Changing this to reference "MCP requests" instead would be good, I think.

Thanks for the feedbacck @PederHP

Is the intent to sign the entire payload? There was some discussion at one point about only signing part of the payload, which I think is a very bad idea. Also, my understanding of DPoP might be flawed, but this only prevents replay attacks for idempotent requests, right? One could replay an intercepted, signed, message and thus perform a tool call with the same payload?

Under what conditions do you foresee an adversary being able to intercept an access token and a DPoP proof (e.g. for remote MCP servers the MCP client/server traffic is expected to be protected by TLS)?

This proposal uses DPoP as defined in RFC 9449 to maximize compatibility with existing infrastructure and speed deployment. DPoP sender-constrains access tokens so that only the client that obtained a token can use it. If an attacker steals an access token, for example from an MCP server log, they still cannot use it without also being able to generate a valid DPoP proof.

Even if a proof is exposed alongside the token, DPoP proofs are short-lived, which greatly limits replay risk. Deployments that need stronger replay protection can require a fresh proof via the nonce mechanism described in the PR. This can be implemented statelessly and provides a per-request proof without the overhead or retooling of existing infrastructure of signing full messages. Depending on deployment needs, fresh proofs can be required for every call or only when triggered by risk-based policy.

I would also suggest not using the verbiage "Accessing MCP server resources". This is a very HTTP-ish way to put it and may cause confusion as an MCP resource is something very specific and unrelated to this SEP. Changing this to reference "MCP requests" instead would be good, I think.

Thanks for pointing that out, please feel free to suggest alternative text.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

Hey @PieterKas looking into this, would you mind adding an optional definition for body-signing for stateless cases that aren't willing to accept time window based replay prevention? ala the earlier suggestion

My proposal would OAuth Protected Resource Metadata can be extended to claim dpop support and also potentially body-signing as a requirement. If absent it can default to the RFC behaviour with no extra cost. In a nutshell offering flexibility.

The use-case is essentially for a multiplexing gateway that is untrusted itself and may permit replay attacks- a client could "trust" this gateway if the onwards MCP required & enforced dpop. Timing is insufficient as the gateway by definition is on the request flow so can seamlessly modify contents.

Maintainer Activity Check

Hi @D-McAdams!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.