Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 12 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Naive conversion refers to traditional Base64 encoding/decoding that uses standard padding ('=') without pre-padding or alignment strategies, lacking the composability, concatenation support, and properties required for efficient stream processing in .
Naive conversion is a term used in the CESR (Composable Event Streaming Representation) specification to describe conventional Base64 encoding and decoding practices that do not anticipate or support the advanced requirements of composable event streaming architectures. The term "naive" indicates an approach that:
The concept is fundamental to understanding why CESR was developed as a specialized encoding scheme rather than simply adopting standard Base64. By explicitly defining what naive conversion lacks, the IETF CESR specification establishes the technical requirements that CESR fulfills for mission-critical applications in the KERI ecosystem.
Naive conversion exhibits several characteristics that make it unsuitable for KERI's requirements:
Padding Dependency: Standard Base64 adds '=' characters when the input byte length is not divisible by 3 (which corresponds to 4 Base64 characters). This padding creates ambiguity in concatenated streams.
Lack of Self-Framing: Naively encoded data does not contain intrinsic type or length information, requiring external schemas or delimiters to parse.
No Composability Guarantee: Converting between text and binary domains multiple times may not preserve structural boundaries when primitives are concatenated.
Stream Processing Limitations: Without stable framing, parsers cannot reliably extract individual elements from a continuous stream without buffering or lookahead.
Base64 encoding was originally designed for email systems (MIME) to safely transmit binary data through text-only channels. The standard approach, which we now call "naive conversion," was optimized for:
However, Base64 was not designed for:
As cryptographic systems evolved to require streaming of multiple primitives (keys, signatures, digests), the limitations of naive Base64 conversion became apparent. The KERI protocol, with its need to stream key events, receipts, and cryptographic material, required a more sophisticated encoding approach.
CESR was developed specifically to overcome the limitations of naive conversion while maintaining Base64 compatibility where beneficial. The IETF CESR specification extensively discusses naive Base64 conversions to illustrate why CESR's innovations are necessary.
Instead of relying on trailing '=' pad characters, CESR implements pre-padding with leading zero bytes before Base64 conversion. This ensures:
This strategic alignment on 24-bit boundaries (3 bytes = 4 Base64 characters) is fundamental to CESR's composability property.
Every CESR primitive includes a derivation code that specifies:
This self-framing property enables parsers to autonomously extract primitives from a stream without external schemas or delimiters—something naive conversion cannot provide.
CESR guarantees that any set of concatenated primitives can be:
This text-binary concatenation composability is impossible with naive Base64 conversion because padding characters and lack of framing information cause boundary ambiguity.
CESR's stable framing enables pipelined streaming operations where:
Naive conversion requires either complete buffering or complex lookahead mechanisms to achieve similar functionality.
CESR introduces group framing codes and count codes that enable:
These features are entirely absent from naive Base64 conversion.
Developers implementing KERI cannot simply use standard Base64 encode/decode functions because:
CESR's approach provides significant performance advantages over naive conversion:
The precision of CESR encoding has security benefits:
Understanding naive conversion helps implementers recognize why CESR is essential for:
Systems migrating from naive Base64 to CESR must:
The distinction between naive conversion and CESR encoding represents a fundamental architectural decision in KERI. By explicitly avoiding naive conversion, KERI achieves:
This architectural choice enables KERI to function as a truly decentralized, high-performance identity infrastructure that can scale to internet-wide deployment while maintaining cryptographic integrity and verifiability at every layer.
Developers may encounter naive conversion in:
Naive Base64 encoding can be identified by:
To convert from naive Base64 to CESR:
When implementing KERI systems:
CESR implementations should:
When interfacing with non-KERI systems: