Check a public key and a separate proof
02A JSON Web Key (JWK) carries the public verification key; a separate protocol demonstrates possession of its private counterpart.
Separate failure: a token bound to key A is accompanied by a signature using private key B. The recipient cannot verify that proof with public key A.
Source for this drawing: RFC 7800 · Read RFC section 3.2 ↗
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.
Verify the JWT before trusting its confirmation key, then verify the presenter’s proof.
- For an asymmetric proof key, cnf.jwk represents the corresponding public key and MUST contain the required members for that JWK key type. Other members, including kid, MAY appear.
- The private key remains with the presenter. An issuer signature on the JWT is not itself the presenter’s proof of possession.
- A recipient-selected nonce signed by the presenter is one example. This RFC intentionally leaves the nonce format, transport and proof-message format to another protocol or application profile.
The displayed public fixture comes from the intentionally insecure test scalar 1, used only to make regressions reproducible. Never use it in a real system. No nonce/signature encoding is standardized here; no complete JWT or proof implementation is supplied.
Read the RFC section ↗