diff --git a/specification/draft/dpop-extension.mdx b/specification/draft/dpop-extension.mdx
index 20fafb1..50524b7 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.
@@ -88,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.
@@ -118,7 +121,6 @@ Below is an example of a decoded DPoP proof JWT suitable for an MCP request:
     "crv": "P-256"
   }
 }
-
 ```
 
 **JWT Payload:**
@@ -129,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
@@ -202,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