Visual RFC.
ALL RFCs / RFC 9449
Read the RFC ↗
RFC 9449 / PROOFS AND PERMISSION

Tie the permission note to a public key

03

The issuer attaches a short fingerprint of the app’s public key to its token. Changing an optional key label should not change the key’s identity.

RFC 9449 · § 6.1EXAMPLE
1 / 4 · Start with the app’s public key

Assume the issuer has checked the request proof and ordinary grant permission.

Public key A → key fingerprintShareable key A
Public key AShareable key, not a secret

Offline worked example. Signature fixtures and key/token hashes can be checked locally; ordinary OAuth, TLS and deployment policy checks remain separate. This is not a production validator.

What happens if you change this?

Predict whether the request will pass. Change one choice to see why; use Restart to restore the original example.

4 / 4
04
Attach it to trusted token facts

The key’s required public members determine its fingerprint. An optional kid label does not change that fingerprint.

Tie the permission note to a public keyThe key’s required public members determine its fingerprint. An optional kid label does not change that fingerprint.Public key A → key fingerprintShareable key ARequired fieldscrv · kty · x · ySHA-256 → base64url43-character fingerprintToken factscnf.jkt

Key idea: Hash the required public-key members, not a certificate or the whole decorated key object.

Terms
DPoP
A separately signed note proving use of a key for a particular request. It accompanies, rather than replaces, the access token.
Public key and private key
The shareable key checks signatures. The matching secret key makes them. A public key is not a registered app identity by itself.

Look up a term in the glossary ↗

Rules & examples

These reference examples may differ from the selected experiment.

  • cnf.jkt is the base64url-encoded SHA-256 JWK thumbprint defined by RFC7638. For the EC examples, canonical input contains crv, kty, x, y in that order.
  • The thumbprint uses UTF-8 canonical JSON of the required public members, with no whitespace. Optional kid labels are excluded. This differs from RFC8705’s complete-certificate x5t#S256 binding.

Bounded offline worked example, not a production OAuth, TLS or general JWT validator. Cryptographic signature fixtures and public-key/token hashes are independently checked.

Sources
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

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.

All chapters in RFC 9449

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 ↗