Which changes does this signed note notice?
05A proof names an action and a destination. Change one part of a request to see what that small note covers, and what HTTPS must still protect.
This selected proof names GET https://photos.example/photos.
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.
This is one isolated check, not a decision to authorize a request. HTTPS must protect the actual message in transit.
Key idea: The standard proof does not sign every request byte.
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
The standard proof does not sign every request byte.
These reference examples may differ from the selected experiment.
- htm must match the HTTP method. htu matches the target URI without query or fragment. A fragment is local URL data and is not sent in an HTTP request.
- Servers SHOULD use RFC3986 syntax- and scheme-based URI normalization before comparison. This experiment uses fixed HTTPS ASCII example URLs, not a general URI normalizer.
- The standard proof does not cover general headers or body data. Matching this isolated method/URI check is not an authorization decision or full message-integrity guarantee; HTTPS remains mandatory.
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.