Require understanding before using the content
04crit makes the encoding extension mandatory to understand, preventing a valid tag from hiding different payload interpretations.
A recipient that does not support critical b64 rejects the JWS. It must not silently fall back to base64url interpretation and use a different payload.
Source for this drawing: RFC 7797 · Read RFC section 6 ↗
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
- crit
- A protected list of critical header extensions that must be understood and supported.
- Interpretation ambiguity
- The same protected bytes being assigned different payload meanings.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A valid MAC is not enough if the payload meaning changed.
- When using b64, the crit header MUST include b64. This applies when b64 is present, not only when its value is false.
- Per JWS critical-header rules, a recipient that does not understand and support a listed critical extension treats the JWS as invalid. crit itself is protected.
- Without the required critical marker, an older implementation can validate a MAC while interpreting received NDA1 as base64url text for 405 rather than as the raw payload NDA1.
The first state is an unsafe noncompliant missing-crit example from RFC7797§8, not a supported downgrade flow. Both interpretations can use the same signing-input bytes while disagreeing about the payload. Adding the critical marker prevents acceptance by an implementation that lacks b64 support; it does not add encryption. Supporting RFC7515§4.1.11 defines critical-extension processing.
Read the RFC section ↗