2026-09-13 · 6 min read · Rahul Chitturi
- jws
- jwt
- cryptography
RFC 7797 allows a JWS payload to remain unencoded when the protected header sets b64 to false. The signing input then contains the exact payload bytes rather than a Base64url representation, so invisible byte changes break verification.
This is a specialized JWS feature, not a shortcut to apply to ordinary JWTs. Interoperability requires an explicit profile and libraries that implement the extension correctly.
Validate protected header semantics
The b64 parameter must be integrity-protected and false must be listed in crit so implementations that do not understand it reject the object. Constrain allowed algorithms, serialization, content type, and payload transport before verification.
- Reject b64 outside the protected header.
- Reject unsupported critical parameters.
- Do not infer detached payloads from an empty segment alone.
- Keep key selection under a trusted policy.
Preserve the original payload bytes
Pass the exact application payload bytes to the verifier. JSON reserialization, newline conversion, Unicode normalization, decompression, or text decoding can change the signed input even when a display looks equivalent.
Compact serialization imposes restrictions when an unencoded payload contains a period. Detached transport avoids embedding the payload but requires the caller to bind the correct external bytes to the JWS.
Use public conformance fixtures
Use Base64 for protected-header inspection, hash and diff for public payload byte comparisons, and the JWT tool only to inspect synthetic compact parts. Flashman does not verify this specialized profile.
Test attached and detached forms, periods, empty payloads, UTF-8, CRLF and LF, missing crit, unprotected b64, altered bytes, wrong keys, unsupported algorithms, and library upgrades.