Summary

  • RFC 9741’s sloppy Base64 operators omit the unused-bit zero check; its JSON operator describes a decoded value rather than a unique serialization. Neither is a universal cleanup rule.
  • A text alias affects approval, caching or billing only through the system’s actual identity rules and joins. Equal bytes alone establish neither a bypass nor an incorrect charge.
  • Compatibility needs an owner beyond the decoder: accepted representations, business identity and cryptographic input must be defined separately, with costs assigned to the unit the service actually sells.

The saving on one side of an interface

Compatibility is often presented as a reduction in friction. An old client need not change its output. A request that would otherwise fail now reaches the next stage. A support ticket disappears. Those are real benefits, but they do not establish that the work disappeared rather than moved.

Consider a hypothetical service operated by separate intake, approval and resource-accounting teams. Intake examines a text reference by decoding it to bytes. Approval records the spelling supplied in a request. A cache or quota counter uses another identifier, and finance builds charges from one of those records. No named implementation or incident is being reported here.

If intake regards two spellings as the same permitted value while the other teams distinguish their strings, the interface has admitted a difference the business must interpret. Is the customer submitting one resource twice, making two separately chargeable requests, or asking to repeat an action that was approved only once? A decoder can tell those teams what it decoded. It cannot choose their contract.

This is not an argument for making every identifier content-addressed. A resource and an action are different objects of accounting. Two tenants can submit identical content without sharing rights to each other’s approvals. Two requests can consume work even when a cache avoids storing a second copy. The useful question is not simply whether the data are equal. It is which equality each decision requires, and who pays when those equalities diverge.

Four bits, more than one label

Carsten Bormann’s March 2025 Standards Track RFC 9741 adds CDDL controls for text conversion and processing. Section 2.1 distinguishes unpadded Base64url .b64u and .b64u-sloppy from padded classic Base64 .b64c and .b64c-sloppy. The sloppy variants omit validation that additional unused bits are zero. They do not thereby waive alphabet or padding rules. Section 2.4’s .json constrains the decoded value, not insignificant whitespace or map-entry serialization order. These are descriptions of accepted representations, not adoption or deployment evidence.

The small Base64 example matters because it needs no change to the meaningful byte. In the unpadded strings Zg and Zh, the first eight bits are 01100110, or 0x66. The last four bits of the second six-bit group are respectively 0000 and 0001. This is a manual bit derivation, not a conformance test run against a CDDL implementation. With the same allowed byte value as controller, the relevant strict/sloppy distinction falls on those otherwise unused bits. The padded classic counterparts are Zg== and Zh==.

RFC 4648, Section 3.5, requires conforming encoders to set pad bits to zero and explains the decoder’s rejection choice in relation to the referring specification. Four variable unused bits give this one-byte layout sixteen possible spellings with the same meaningful bits. That count is not a universal property of every token length. A longer reference should not be assigned sixteen aliases by analogy.

This also explains why “sloppy” is a poor substitute for an interface specification. A team reading it as permission to ignore arbitrary whitespace, accept mixed alphabets or recover truncated input would be enlarging the rule. Compatibility needs a bounded profile, not a general mood of tolerance.

A form can preserve value without preserving its text key

The same administrative problem appears in a less unusual format. Compare these JSON texts:

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

They use the same fixed strings and small integer, without duplicate member names. Only object-member order and insignificant whitespace change. RFC 8259 supplies the JSON syntax background. I-JSON, RFC 7493, narrows interoperability hazards, including duplicate names, and says member order does not change a message’s meaning.

The conversion underpinning .json is the default JSON-to-CBOR mapping in RFC 8949, Section 6.2. Representation and numeric precision still deserve attention. A string data model used for numbers beyond interoperable precision must be reflected in the application’s constraints. Nothing in this example licenses treating duplicate keys, reordered arrays or every apparently equivalent number as the same value.

Suppose a form validator accepts both texts while an approval database stores the complete text as its lookup key. The form’s value check has not issued a stable approval identifier. If the resource layer later selects a decoded-value key, a mapping is required between those identities. Whether that mapping exists, includes tenant and purpose, and is checked before execution determines the business consequence.

The choices are deliberately field-specific. Other controls distinguish case-flexible hex from fixed-case forms, or restrict decimal spelling rather than accepting arbitrary leading zeros. A validation vocabulary can offer both narrow and permissive relationships. It does not command the business to pick one relationship for everything.

A second charge may be right; a second resource may be wrong

The temptation is to call any additional spelling a duplication defect. That skips the most important economic distinction.

A per-request service can reasonably charge for two submissions of the same content. Admission, decoding, queueing and audit work may occur twice. A per-logical-resource service may instead promise that a second label does not create another stored resource. A service charging for a business action must identify the action and its state transition, not merely count different input strings or equal payload hashes.

These arrangements can coexist. A cache can collapse storage while a request counter still measures intake work. An approval can authorize one operation without covering a different operation on the same data. A bill can contain two valid request charges even though only one content object exists. Conversely, an unexpected resource count can reveal an identity mismatch without proving that the customer was overcharged under the actual contract.

Evidence must therefore connect the declared charging unit to the records used to measure it. A dispute needs the relevant request, resource or action identity, the scope of the counter and the resulting charge. Equal decoded bytes are only one observation. They are not a financial verdict.

The same caution applies to security language. To claim an approval bypass, one must show the rule that should have prevented an action and how the alias changed its decision or join. To claim replay, one must identify the action whose repetition was prohibited and the state that allowed it. A pair of accepted texts does not demonstrate either. The hypothetical service illustrates where to investigate, not what investigators will find.

Do not lend the cache’s equality to a signature

A storage key may deliberately ignore a spelling difference that authentication deliberately binds. Ordinary Base64url-encoded JWS makes that boundary concrete. RFC 7515 defines the signing input using the encoded protected header and encoded payload, separated by a period. Parsing two JSON payload texts to an equal value does not authorize substituting a newly serialized input for the one the envelope requires verification to cover.

An application may explicitly choose a data-model canonicalization scheme instead. RFC 8785’s JCS supplies deterministic representation within its input constraints; it is an Informational RFC from the Independent Submission stream, not an implicit part of .json. Its input requirements and verification conditions remain part of the chosen design. This article does not extend ordinary JWS rules to unencoded-payload extensions or every other envelope.

“Normalize before use” is consequently an incomplete instruction. Before which use, and under whose definition? Intake can map a permitted representation for a resource index after preserving the evidence authentication needs. It cannot infer from the desired cache behavior that the cryptographic layer permits rewriting its input. The original representation may be exactly what the sender authenticated.

Thin common rules, explicit local decisions

Lu Heng’s discussion of minimum common specification offers an analytical lens: separate deterministic shared validity from business arrangements and later operating choices. Applied here, that suggests defining the representation profile tightly while leaving the pricing and approval decision explicit. It is not a statement that he reviewed this RFC, nor an IETF requirement for accounting.

His Running-Code Primacy argument points to a second distinction: publication of a rule is not proof that running participants apply it. For the hypothetical service, the evidence is the identity actually used at each join, not a compliance label in documentation. His discussion of reality and symbolic layers is similarly a perspective, not an incident source: a successful validation receipt stands for one check, not the complete business outcome.

RFC 8610’s security considerations already caution against relying solely on CDDL specification and matcher correctness without further defenses. CDDL can make the value relationship legible. Approval authority, tenant separation, charging units and execution evidence still have to be supplied elsewhere.

The practical conclusion is modest but demanding. Accepting extra spellings can be a sound compatibility choice. It becomes an unowned liability when the decision is treated as complete at the decoder and the remaining interpretation is left to whoever receives the next ticket.