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

Set one application policy and exclude JWTs

05

Applications choose consistent encoding behavior, multiple signatures must agree, and JWTs cannot use the unencoded option.

DIAGRAMRead RFC section 7 ↗
RFC 7797 · § 7EXAMPLE
3 / 3
Set one application policy and exclude JWTsSeparate application profiles choose consistently whether raw payloads are used; default encoded behavior can omit b64. A separate invalid multi-signature example mixes false and true even though all b64 values on one JWS MUST be the same. A final JWT gate rejects false b64 because JWTs MUST NOT use this option. The option remains available only for suitable non-JWT contexts and does not add encryption.Keep one policy for each application contextJWT context{"b64":false}accept as a JWTJWTs MUST NOT use b64:falseFormal update: RFC7519
03
Reject the unencoded option in a JWT context.

JWTs MUST NOT use b64:false. A generic JWS application’s ability to use the option does not make it legal for JWTs.

Source for this drawing: RFC 7797 · Read RFC section 7 ↗

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

RFC 7515 JWS RFC 4648 Base encodings RFC 7519 JWT

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
JWT
JSON Web Token: a claims format with its own restrictions.
Application profile
Rules defining how a protocol option is used in a particular context.
Multiple signatures
More than one signature or MAC protecting a shared JWS payload.
Related RFCs and changes

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

KEY POINT

An optional JWS feature is not automatically a valid JWT feature.

  • Application profiles should specify whether false b64 is used in each context. Dynamically varying it for different payloads in the same context is NOT RECOMMENDED.
  • Explicit true is legal, but omitting b64 for that default behavior is RECOMMENDED. If the parameter is present, its protection and critical-marker requirements still apply.
  • If a JWS has multiple signatures or MACs, b64 MUST have the same value for all of them.
  • For interoperability, JSON Web Tokens MUST NOT use b64:false. RFC7797 formally Updates RFC7519 for this restriction; it does not formally update RFC7515.
DETAILS

A general JWS is not necessarily a JWT. This guide illustrates the option for a suitable non-JWT application context, not a change to existing token-validation rules. All normal JWS algorithm, key, validation and application-policy requirements still apply. Preserving bytes, parsing correctly and checking critical extensions remain necessary whether the payload is attached or detached.

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 ↗