Keep validation, replay and privacy checks separate
05One confirmation key does not replace application rules, freshness, audience restriction or privacy precautions.
Example party-A uses K-A and party-B uses K-B. Reusing K-A with both could link interactions; other identifying claims can still correlate them.
Source for this drawing: RFC 7800 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A key is different from permission.
An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Proof of possession answers a narrower question than authorization.
- cnf MUST represent only a single proof key: at most one of jwk, jwe and jku may be present. kid can accompany jku to select that same key; it is not a second key.
- Absent application-specific requirements, unrecognized confirmation members MUST be ignored. A profile requiring possession must ensure its needed confirmation behavior is implemented; ignoring an unknown member does not establish proof.
- Audience restriction protects a different boundary from possession. Encrypted symmetric-secret proofs can be replayed; distinct challenges or instance-specific derived subkeys are possible defenses, with protocol details outside this RFC.
- Reusing a proof key across parties can create a correlation handle. For privacy, different keys with different parties are recommended; this is not a guarantee of anonymity.
Application profiles define required claims and proof processing. Audience guidance and different-party key use are recommendations here, not invented universal uppercase MUSTs. RFC7800 does not standardize a complete anti-replay protocol or grant authorization.
Read the RFC section ↗