Visual RFC.
ALL RFCs / RFC 7797
Read the RFC ↗
RFC 7797 / UNENCODED JWS PAYLOADS

Choose which payload bytes enter the MAC

01

The protected b64 header chooses whether signing uses base64url text or the payload octets themselves.

RFC 7797 · § 3EXAMPLE
3 / 3
Choose which payload bytes enter the MACThe default protected header omits b64 and uses base64url payload JC4wMg. The protected false example includes critical b64 and uses raw $.02 payload bytes. A separate invalid placement puts b64 in an unprotected header and stops at the integrity-protection gate. The protected header remains encoded in both valid forms; encoding is not encryption.Choose payload encoding inside the protected headerSeparate invalid placementUnprotected header{"b64":false}accept encoding choiceb64 MUST be integrity protectedMUST occur only in the Protected Header
03
Do not put the encoding choice in an unprotected header.

Separate invalid placement example: b64:false appears outside the protected header. This violates the integrity-protection requirement; the choice cannot be accepted from mutable metadata.

Source for this drawing: RFC 7797 · Read RFC section 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
JWS
JSON Web Signature: a format for integrity-protected payloads.
MAC
Message Authentication Code: a tag computed using a shared key.
Protected header
Header parameters included in the integrity-protected input.
Base64url
A URL-safe binary-to-text encoding, not a secrecy mechanism.
Related RFCs and changes

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

KEY POINT

The header stays encoded; the payload encoding is the choice.

  • b64 is an optional JSON boolean, defaulting to true. False uses the original JWS payload bytes; true uses their base64url encoding.
  • When used, b64 MUST be integrity protected and occur only in the JWS Protected Header. That header still uses UTF-8 and base64url; false does not make every JWS part unencoded.
  • The signing input is encoded protected-header text, one period byte, then either encoded payload text or raw payload bytes. Encoding is not encryption.
DETAILS

This guide uses the RFC’s small public HS256 examples for a Message Authentication Code (MAC), not a claim of encryption or a unique public-key signer identity. The option can avoid encoding and copying a large detached payload, but applications must preserve the exact payload bytes. RFC7797§6 also requires crit when b64 is used; the complete false example includes it.

Read the RFC section ↗

All chapters in RFC 7797

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 ↗