Visual RFC.
ALL RFCs / RFC 7800
Read the RFC ↗

RFC 7800 / START HERE

JWT proof keys, before the details

JWT means JSON Web Token; proof of possession means showing cryptographically that you hold a particular private or shared key.

RFC 7800 defines the cnf confirmation claim, a JSON object that binds a JWT to one proof key. The recipient must validate the token and separately check possession using the application’s chosen protocol.

The idea in one picture

  1. Issuer binds one key

  2. Presenter proves possession

  3. Recipient checks context

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

A copied token should not be enough in a proof-required application. This companion to JWT explains how to carry or identify its bound key; it does not define a complete challenge or request protocol.

A familiar example

A document app presents a token bound to its key, then answers a fresh challenge. A copy holder without that key fails; audience, replay and permission checks still matter.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. A token and a proof do different jobsAn issuer binds a proof key to a JWT; its presenter must separately demonstrate possession to a recipient.
  2. Check a public key and a separate proofA JSON Web Key (JWK) carries the public verification key; a separate protocol demonstrates possession of its private counterpart.
  3. Encrypt a shared proof key for its recipientA shared proof key needs secrecy as well as token integrity; JSON Web Encryption (JWE) can carry an encrypted JWK to the recipient.
  4. Resolve a key identifier or a key-set URLkid names a key in an application context; jku locates a public JWK Set and may need a matching kid.
  5. Keep validation, replay and privacy checks separateOne confirmation key does not replace application rules, freshness, audience restriction or privacy precautions.
Start with chapter one →

This introduction explains RFC 7800 (2016). Read the original RFC ↗