A token and a proof do different jobs
01An issuer binds a proof key to a JWT; its presenter must separately demonstrate possession to a recipient.
Separate failure example: a copy holder has the token but cannot prove possession. The illustrated proof-required application rejects this use.
Source for this drawing: RFC 7800 · Read RFC section 1 ↗
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.
Receiving a JWT is not the same as confirming that its presenter holds the bound key.
- Issuer creates and protects the JWT; presenter proves possession; recipient validates the JWT and checks the proof. The issuer’s JWT-protection key and the presenter’s proof key have different jobs.
- The cnf confirmation claim is a JSON object identifying the proof key. At least one of sub (subject) and iss (issuer) MUST be present; presenter identification is ultimately application specific.
- Possession mechanisms and required confirmation members are application dependent. This RFC describes key semantics, not a complete new request or challenge protocol.
The scenes assume a proof-required application profile and established trust in the issuer. They do not claim that all JWTs are proof-of-possession tokens. Signed claims are not necessarily encrypted.
Read the RFC section ↗