Notice an old note or a repeated identifier
06The server checks when a proof was made. It can also remember identifiers it has already accepted, so a copied proof cannot simply be used twice.
The proof has an iat creation time. The server chooses its allowed tolerance.
Offline worked example. Signature fixtures and key/token hashes can be checked locally; ordinary OAuth, TLS and deployment policy checks remain separate. This is not a production validator.
What happens if you change this?
Predict whether the request will pass. Change one choice to see why; use Restart to restore the original example.
Time is acceptable and no enforced identifier-reuse check fails. Reusing a permitted server nonce is distinct from reusing a proof identifier.
Key idea: A short acceptance window and optional identifier memory do different jobs.
Terms
- DPoP
- A separately signed note proving use of a key for a particular request. It accompanies, rather than replaces, the access token.
- Public key and private key
- The shareable key checks signatures. The matching secret key makes them. A public key is not a registered app identity by itself.
Rules & examples
A short acceptance window and optional identifier memory do different jobs.
These reference examples may differ from the selected experiment.
- Servers MUST limit the time after creation during which proofs are accepted. This example chooses at most 60 seconds old and at most 5 seconds ahead; these numbers and inclusive boundaries are local policy, not RFC constants.
- jti must be assigned with negligible collision probability in its validity context. Examples of suitable construction include at least 96 pseudorandom bits or UUIDv4.
- Tracking accepted jti values at the target URI can reject reuse; this replay-memory check is not always feasible. Nonces can provide server-managed time. A server nonce may be reused across fresh proofs under the server’s policy; it is not automatically single-use.
Bounded offline worked example, not a production OAuth, TLS or general JWT validator. Cryptographic signature fixtures and public-key/token hashes are independently checked.
Sources
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.