Der Client erzeugt ein Schlüsselpaar (meist ES256) und sendet einen Header DPoP mit einem JWT: typ ist dpop+jwt, der öffentliche Schlüssel steht im Header jwk, dazu kommen die Claims jti, htm (HTTP-Methode), htu (URL ohne Query und Fragment), iat und, wenn ein Access Token vorgelegt wird, ath (dessen SHA-256-Hash). Der Autorisierungsserver bindet das ausgestellte Token an den Thumbprint des Schlüssels (cnf.jkt), und Ressourcenserver prüfen den Proof bei jedem Aufruf; Server können eine vom Server vorgegebene nonce verlangen, um vorab berechnete Proofs einzuschränken.
DPoP arbeitet auf der Anwendungsschicht, übersteht daher TLS-terminierende Proxys und eignet sich für Browser und mobile Apps – anders als an mTLS gebundene Tokens (RFC 8705). Ressourcenserver müssen prüfen, dass jti innerhalb eines kurzen Zeitfensters eindeutig ist, dass Methode und URL stimmen und dass der Schlüssel des Proofs zum Token passt. Der DPoP-Proof-Inspektor validiert einen Proof und seine Token-Bindung.