Match both the key and the permission note
04The picture service receives a token and a signed proof. Check which key signed it and exactly which token the proof names.
Assume the proof signature, method, URI, time and any required nonce have passed.
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.
The token is trusted and allowed; its key matches this proof, and ath names exactly the presented token.
Key idea: cnf.jkt ties the token to a key; ath ties this proof to the exact token value.
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
cnf.jkt ties the token to a key; ath ties this proof to the exact token value.
These reference examples may differ from the selected experiment.
- A protected request includes Authorization: DPoP <access-token> and a separate DPoP: <proof-JWT> header. All proof and token checks must succeed before access.
- ath is unpadded base64url of SHA-256 over the ASCII access-token value. Replacing the token needs a new proof even if the key is unchanged.
- Validate and trust token facts first, locally or through authenticated introspection. The API, not the introspection endpoint, checks the request proof and key binding. An introspection token_type, if included, must be DPoP.
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.