Visual RFC.
ALL RFCs / RFC 7638
Read the RFC ↗
RFC 7638 / JWK THUMBPRINTS

Construct the exact bytes

02

Semantically similar JSON can have different bytes. Thumbprints require the specified member order and representation before hashing.

RFC 7638 · § 3.3EXAMPLE
3 / 3
Construct the exact bytesA deliberately insecure public toy symmetric key AQID demonstrates a complete short hash input. Incoming kty then k with spaces is replaced by k then kty with no extra whitespace. The complete compact JSON string is 24 UTF-8 bytes; the final state maps its initial characters to hexadecimal byte values. Captions, row breaks and hex annotations are never included in the hashed JSON.A precise spelling before hashingPublic toy key · not for real cryptographic use{"k":"AQID","kty":"oct"}UTF-8 encodingFirst six characters{ " k " : "7b 22 6b 22 3a 22Then the remaining 18 bytesHash JSON octets, not this printed hex
03
Encode the exact string as bytes.

All characters in this example are ASCII, so each is one UTF-8 byte. The initial bytes 7b 22 6b 22 3a 22 encode {, quote, k, quote, colon, quote. Hash these JSON bytes, not a hex dump.

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

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.

Terms in this drawing
Canonical representation
A precisely specified spelling of the selected data.
UTF-8
The encoding that turns the serialized Unicode string into octets for hashing.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Order member names lexicographically by Unicode code points and omit whitespace before or after syntactic elements. The oct key type selects k then kty.

  • Order member names lexicographically by Unicode code points and omit whitespace before or after syntactic elements. The oct key type selects k then kty.
  • Represent characters in member names and values without escapes (MUST). Thumbprints needing characters that JSON requires to be escaped are not defined by this RFC.
  • If a key type defines object-valued required members, recursively order their members (MUST). Integer-valued members MUST omit fraction and exponent parts; noninteger cases are not defined here.
  • UTF-8 encoding follows serialization. JSON.stringify does not itself guarantee sorting; Unicode code point ordering must not be replaced by locale-sensitive collation.
DETAILS

This chapter uses the deliberately insecure public toy octet key AQID, meaning bytes 01 02 03, only to show an entire short serialization. Do not use it as a real secret. The exact JSON string contains 24 ASCII characters/UTF-8 bytes; display quotes belong to JSON, while the diagram captions and byte annotations do not. RFC 7638 is not a general JSON canonicalization scheme. Future key-type representations must follow their own definitions and this RFC’s Unicode restrictions.

Read the RFC section ↗

All chapters in RFC 7638

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 ↗