Le client génère une paire de clés (généralement ES256) et envoie un en-tête DPoP contenant un JWT avec typ dpop+jwt, la clé publique dans l’en-tête jwk et les claims jti, htm (méthode HTTP), htu (URL sans chaîne de requête ni fragment), iat et, lorsqu’il présente un jeton d’accès, ath (son condensat SHA-256). Le serveur d’autorisation lie le jeton émis à l’empreinte de la clé (cnf.jkt), et les serveurs de ressources vérifient la preuve à chaque appel ; les serveurs peuvent exiger un nonce fourni par le serveur pour limiter les preuves précalculées.
DPoP fonctionne au niveau de la couche application : il résiste donc aux proxys qui terminent TLS et convient aux navigateurs et aux applications mobiles, contrairement aux jetons liés par mTLS (RFC 8705). Les serveurs de ressources doivent vérifier l’unicité de jti dans une fenêtre courte, la méthode et l’URL, ainsi que la correspondance entre la clé de la preuve et le jeton. L’inspecteur DPoP valide une preuve et sa liaison au jeton.