From 38ea8dcf9672effc9e9072478aaa6aad832c2418 Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Mon, 12 Oct 2026 12:10:10 +0100 Subject: [PATCH 1/2] Add authorization code binding recommendation (dpop_jkt) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a SHOULD for MCP clients to bind the authorization code to their DPoP key per RFC 9449 Section 10. RFC 9449 makes this OPTIONAL; this profile recommends it as defense in depth alongside MCP’s mandatory PKCE. Surfaced by the conformance work in modelcontextprotocol/conformance#523; kept separate from #33 so the two can be discussed and merged independently. --- specification/draft/dpop-extension.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/specification/draft/dpop-extension.mdx b/specification/draft/dpop-extension.mdx index 20fafb1..20fac5b 100644 --- a/specification/draft/dpop-extension.mdx +++ b/specification/draft/dpop-extension.mdx @@ -59,6 +59,10 @@ DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6... ``` +### Authorization Code Binding + +MCP clients using the authorization code grant SHOULD bind the authorization code to their DPoP key, as described in [RFC 9449 Section 10](https://datatracker.ietf.org/doc/html/rfc9449#section-10). + ### MCP Server Validation MCP servers MUST validate DPoP proofs according to [RFC 9449 Section 4.3](https://datatracker.ietf.org/doc/html/rfc9449#section-4.3). Implementations conforming to this specification MUST verify that the `iat` claim is within ±5 minutes of the server's current time. From 145244340698005b64306f13c8a04166a79acded Mon Sep 17 00:00:00 2001 From: Pieter Kasselman Date: Mon, 2 Nov 2026 11:08:06 -0800 Subject: [PATCH 2/2] chore: format dpop-extension.mdx with prettier Fixes the Markdown Format Check failure: blank lines before closing code fences, a trailing comma in a JSON example, and a missing blank line after a heading. No wording changes. Co-Authored-By: Claude Fable 5 --- specification/draft/dpop-extension.mdx | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/specification/draft/dpop-extension.mdx b/specification/draft/dpop-extension.mdx index 20fac5b..50524b7 100644 --- a/specification/draft/dpop-extension.mdx +++ b/specification/draft/dpop-extension.mdx @@ -92,7 +92,6 @@ Example Authorization Server Metadata: "token_endpoint": "https://auth.example.com/token", "dpop_signing_alg_values_supported": ["ES256", "RS256", "PS256"] } - ``` **Note on Algorithm Selection:** While this specification does not mandate specific algorithms, authorization servers and clients SHOULD support modern, secure algorithms such as ES256 (ECDSA using P-256 and SHA-256). Implementations should avoid deprecated or weak algorithms. The security considerations of chosen algorithms are beyond the scope of this specification; implementers should consult current cryptographic best practices. @@ -122,7 +121,6 @@ Below is an example of a decoded DPoP proof JWT suitable for an MCP request: "crv": "P-256" } } - ``` **JWT Payload:** @@ -133,9 +131,8 @@ Below is an example of a decoded DPoP proof JWT suitable for an MCP request: "htm": "POST", "htu": "https://mcp.example.com/mcp", "iat": 1699564218, - "ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo", + "ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo" } - ``` ### Complete Request Example @@ -206,6 +203,7 @@ Only asymmetric signature algorithms MUST be used for DPoP proofs. Symmetric alg Replay protection options for stateless MCP servers are described in {{stateless-replay-protection}}. MCP servers requiring maximum replay protection SHOULD implement `jti` tracking despite the operational complexity. The trade-offs are discussed in detail in [RFC 9449 Section 11.1](https://datatracker.ietf.org/doc/html/rfc9449#section-11.1). ### DPoP Limitations + DPoP does not prevent token theft, but provides a mechanism that allows detection of replay attacks that utilise a stolen token. In addition, DPoP does not address confused deputy vulnerabilities or other authorization-level attacks. Consequently. implementations must maintain defense in depth by implementing all required security controls. ### Integration with MCP Security Model