クライアントは鍵ペア（通常は ES256）を生成し、DPoP ヘッダーを送ります。このヘッダーに入る JWT は、typ が dpop+jwt で、jwk ヘッダーに公開鍵を含み、クレームとして jti、htm（HTTP メソッド）、htu（クエリとフラグメントを除いた URL）、iat、さらにアクセストークンを提示する場合は ath（アクセストークンの SHA-256 ハッシュ値）を持ちます。認可サーバーは発行するトークンを鍵のサムプリント（cnf.jkt）に紐付け、リソースサーバーは呼び出しのたびにプルーフを検証します。サーバーは、事前に計算されたプルーフを制限するために、サーバーが発行する nonce を要求できます。
DPoP はアプリケーション層で動作するため、mTLS に紐付いたトークン（RFC 8705）とは異なり、TLS を終端するプロキシを経由しても機能し、ブラウザーやモバイルアプリにも適しています。リソースサーバーは、短い時間枠での jti の一意性、メソッドと URL、プルーフの鍵がトークンと一致することを確認しなければなりません。DPoP プルーフインスペクターで、プルーフとそのトークンへの紐付けを検証できます。