Visual RFC.
ALL RFCs / RFC 7800
Read the RFC ↗
RFC 7800 / JWT PROOF-OF-POSSESSION KEYS

Encrypt a shared proof key for its recipient

03

A shared proof key needs secrecy as well as token integrity; JSON Web Encryption (JWE) can carry an encrypted JWK to the recipient.

DIAGRAMRead RFC section 3.3 ↗
RFC 7800 · § 3.3EXAMPLE
4 / 4
Encrypt a shared proof key for its recipientFour ordered scenes distinguish prior issuer-recipient K-wrap setup, private issuer-presenter provisioning of K-pop, issuer delivery of an integrity-protected JWT whose cnf.jwe hides a symmetric JWK, and presenter delivery to recipient for JWT validation and nested decryption. K-wrap is not K-pop. Five schematic H.EK.IV.C.T compact fields are labels, not a valid ciphertext. Decryption gives recipient the proof key but does not prove the presenter possesses it; a separate protocol is still needed.Two secrets with different jobsPresenterRecipientpresent protected JWT1. Validate JWT protection and application context2. Decrypt cnf.jwe with K-wrap → K-popthen separate possession protocolDecrypting a key is not proof by the presenter
04
Recover the proof key, then confirm possession.

Recipient validates the JWT and decrypts the nested JWE using K-wrap to obtain K-pop. The presenter must still demonstrate possession in the chosen protocol; decryption alone is not that proof.

Source for this drawing: RFC 7800 · Read RFC section 3.3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 7519 JWT RFC 7517 JWK RFC 7516 JWE

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.

KEY POINT

Keep the proof secret separate from the key that encrypts it.

  • In the introduction’s symmetric example, issuer and recipient first establish a key-encryption key. The proof key is separately shared privately between issuer and presenter; either can generate it.
  • cnf.jwe is a JWE Compact Serialization whose plaintext is the UTF-8 representation of a symmetric JWK. It is encrypted to a key known to the recipient. The JWT also needs data-origin authentication and integrity protection. Encrypted JWK rules require cty jwk+json unless the application knows that content by another means or convention.
  • A symmetric JWK MAY instead appear in cnf.jwk if the JWT is encrypted so the secret is not disclosed. If the JWT is not encrypted, that symmetric key MUST be encrypted as in §3.3.
DETAILS

K-wrap/K-pop are explanatory names, not RFC field names. This sequence follows the simplified Figure1 setup; actual algorithms, secure provisioning and derived-key protocols are outside this guide. No secret bytes or valid encrypted test token are displayed.

Read the RFC section ↗

All chapters in RFC 7800

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗