Skip to main content

DPoP-aware transport

Creating a valid proof is only half of DPoP safety. The HTTP transport must create a new proof for the exact method and URL of every attempt—including a nonce retry or redirect—and must never let caller-controlled headers override the Session Token or proof.

Enforced boundaries​

  • Only HTTPS resource URLs without embedded credentials are accepted.
  • Authorization and DPoP are host-owned; callers cannot supply or replace them.
  • Every attempt receives a fresh proof bound to its method, normalized target, and Session Token hash.
  • A use_dpop_nonce challenge is retried once with the company's nonce.
  • Same-origin redirects receive a new target-bound proof. Cross-origin redirects fail before a credential reaches the new origin.
  • Redirects are bounded and handled manually; the underlying HTTP client never forwards authorization automatically.
  • Request bodies are replayable values rather than unbounded streams. A 303 changes the redirected request to GET and discards the body.

Python exposes DpopHttpClient; TypeScript exposes DpopFetchClient. Both resolve proof generation through Reactor and keep Session Tokens, proofs, nonces, and pairwise identity outside model-visible inputs and results.

MCP remains a separate milestone

MCP uses a resource-bound Bearer Session Token rather than DPoP. Issuing that token safely depends on the Account Token exchange lifecycle, so the generic DPoP transport does not accept Bearer tokens or silently downgrade. The plan keeps MCP acquisition and enforcement open until that lifecycle exists.

Run the Pydantic AI example or the Agent Runtimes example. See upstream Using Session Tokens.