2026-09-08 · 6 min read · Rahul Chitturi
- json
- signatures
- debugging
Two JSON documents can parse to equivalent application values while producing different signature bytes. Object member order, whitespace, escape choices, Unicode representation, and number formatting can all change serialization without changing what a developer sees.
Sorting keys in one formatter is not automatically the canonical form required by a signature protocol. The signer and verifier must implement the same named profile over the same input representation.
Capture the complete byte pipeline
Record where text becomes bytes, which character encoding is used, whether JSON is parsed and reserialized, and whether the protocol signs raw content or a canonical representation. Compare harmless fixtures before changing keys.
- Preserve the original payload when the protocol signs raw bytes
- Inspect numeric forms such as exponents and negative zero
- Distinguish escaped characters from their decoded values
- Confirm whether the signature itself uses hex or Base64
Use one specified canonicalizer
If the protocol names RFC 8785 or another canonicalization scheme, use a maintained implementation and reject values outside that profile. Do not compose ad hoc key sorting, whitespace removal, and Unicode normalization.
Apply schema and business validation after signature verification. Canonicalization makes one representation deterministic; it does not prove the data is authorized or safe.
Reproduce locally with Flashman
Use the JSON formatter to expose structure, diff to compare serialized forms, hash to label exact public fixtures, and Base64 to inspect synthetic signature transport. Never paste production signing keys into browser tools.
Test empty objects, nested keys, non-ASCII text, escaped slashes, integer and fractional values, exponent forms, duplicate keys, line endings, and every producer and verifier version.