Sender-constrain the token Whether to send a DPoP proof on the Token Request. With it, the authorization server binds the access token (and the refresh token) to this wallet's key and answers token_type: DPoP; without it the token comes back as a Bearer token, which is what the rest of this workflow demonstrates by default.
Use DPoP (RFC 9449) instead of a Bearer access token Credential key binding Which key the CREDENTIAL is bound to, which is a different question from whether the TOKEN is bound. Either way the Credential Request carries an openid4vci-proof+jwt key proof — this only decides whose key signs it. Holder of Key reuses the DPoP key, so one key is both the token's cnf.jkt and the credential's cnf.jwk. Unchecked, the credential is bound to a holder key of its own, with a lifetime independent of the token's.
Holder of Key — bind the credential to the DPoP key (unchecked: a holder key of its own) Proof algorithm The JWS algorithm the DPoP proofs are signed with. RFC 9449 requires an asymmetric algorithm and forbids none and any MAC. Which ones the authorization server accepts is in its dpop_signing_alg_values_supported metadata, shown below.
RS256 RS384 RS512 ES256 ES384 ES512 PS256 PS384 PS512 EdDSA-Ed25519 EdDSA-Ed448 ES256K Server accepts dpop_signing_alg_values_supported from the authorization server's RFC 8414 metadata. Its presence is the only signal that DPoP is on offer at all, so an absent value means the server has not said it supports DPoP.
—DPoP public key The public half, which travels in the jwk header of every proof. It is not secret: the point is not to hide the key but to make the token useless without the private half.
jkt (RFC 7638) The JWK Thumbprint of the public key: the SHA-256 of its required members in lexicographic order with no whitespace. This is the value the access token carries as cnf.jkt.
—Bind the authorization code RFC 9449 section 10: sending dpop_jkt on the AUTHORIZATION request binds the code itself to this key, so a stolen code cannot be redeemed even by someone who also has the PKCE code_verifier. It has to be set before step 1 runs, which is why this only says whether it happened.
—Token binding What the token endpoint actually answered: token_type and the cnf.jkt inside the access token. Asking for a binding does not create one — a server that ignores the proof would answer Bearer, and this row is how you would notice.
Server-supplied nonce RFC 9449 sections 8 and 9: a server may require a nonce of its own choosing in every proof, asking for it with use_dpop_nonce and supplying it in a DPoP-Nonce header. The wallet retries once and remembers the nonce, so later calls carry it without being asked again.
—Proof sent The most recent DPoP proof this page sent, decoded. htm and htu tie it to one method and one endpoint; ath is the hash of the access token it accompanied; jti makes it single use.
