Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 184 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.
End-to-end (E2E) in KERI refers to cryptographic security and provenance properties that span from data origination to final verification without requiring trust in intermediary infrastructure, encompassing both E2E security (signed/encrypted data in motion and at rest) and E2E provenance (verifiable tracking of all data transformations).
End-to-end (E2E) represents a fundamental architectural principle in KERI that establishes cryptographic guarantees spanning the entire lifecycle of data and communications—from origination through transmission, storage, transformation, and final verification. The concept encompasses two distinct but complementary properties:
The defining characteristic of E2E in KERI is independence from intermediary trust. Unlike traditional security models that rely on trusted infrastructure (certificate authorities, secure networks, trusted servers), KERI's E2E approach enables any party to cryptographically verify data authenticity and integrity using only the data itself and publicly available key event logs, without requiring trust in the communication path or storage infrastructure.
The term "end-to-end" has roots in network architecture, notably articulated in Saltzer, Reed, and Clark's 1984 paper "End-to-End Arguments in System Design," which established that certain functions (like reliability and security) can only be completely implemented at the application endpoints, not in intermediate network layers. This principle influenced internet protocol design, where IP provides best-effort delivery while TCP provides end-to-end reliability.
In cryptography and security, end-to-end encryption emerged as a response to vulnerabilities in traditional communication security models. Early encrypted communications often relied on trusted intermediaries (like email servers or messaging platforms) that could decrypt, read, and re-encrypt messages. True E2E encryption, popularized by tools like PGP (Pretty Good Privacy) in the 1990s and later by Signal Protocol, ensures only the communicating endpoints can decrypt messages.
Message Signing: All KERI messages must include attached signatures from the sender's current authoritative keys. Implementations should verify signatures against the sender's KEL before processing message content.
KEL Verification: E2E verification requires processing the complete KEL from inception to current state. Implementations should cache verified key states to optimize repeated verifications while maintaining the ability to detect duplicity.
Witness Configuration: While witnesses don't require trust, they provide availability and duplicity detection. Configure witness pools with appropriate thresholds (typically requiring supermajority agreement) and geographic/organizational diversity.
ACDC Chaining: When creating credential chains, ensure each ACDC includes proper edge references with SAIDs of parent credentials. Verify the complete chain during presentation.
TEL Anchoring: Anchor TEL events to the issuer's KEL through seals in establishment or interaction events. This creates verifiable timestamps and attribution for credential lifecycle events.
Seal Mechanism: When anchoring external data, include cryptographic digests in KEL events. Store the mapping between seals and external data to enable verification.
Incremental Verification: For long-lived identifiers, implement incremental KEL verification that caches verified states and only processes new events.
Parallel Processing: KEL verification for different identifiers can occur in parallel, enabling horizontal scaling.
Witness Optimization: Use witness receipts to avoid re-verifying events that have achieved witness consensus.
Key Protection: E2E security depends on protecting private keys. Use hardware security modules (HSMs), trusted execution environments (TEEs), or secure enclaves for key storage.
Duplicity Monitoring: Implement watcher networks to continuously monitor for duplicitous KELs. Configure alerts for detected duplicity.
Replay Protection: Use monotonic sequence numbers and timestamps to prevent replay attacks while maintaining E2E verifiability.
However, traditional E2E approaches still suffered from key management challenges. Public Key Infrastructure (PKI) systems using X.509 certificates depend on Certificate Authorities as trusted third parties. Web of Trust models like PGP require manual key verification and trust decisions. Blockchain-based systems achieve decentralization but lock identifiers to specific ledgers and lack efficient key rotation mechanisms.
KERI extends and strengthens the E2E principle through its autonomic identifier architecture and key event receipt infrastructure. The protocol implements E2E properties at multiple layers:
KERI's E2E security model requires that all communications between KERI components (controllers, agents, witnesses, watchers) be cryptographically signed and encrypted. This is achieved through:
Signed-Everything Model: Every message in KERI carries cryptographic signatures from the sender's authoritative keys. The signature creates a non-repudiable commitment to both the message content and the sender's identifier. This differs from traditional systems where only certain messages (like authentication requests) are signed.
Key Event Log (KEL) Foundation: The KEL provides the cryptographic root-of-trust for all E2E security. Each KEL entry is signed by the controller's current authoritative keys and includes cryptographic digests linking to previous events (backward chaining) and commitments to future keys (forward chaining through pre-rotation). This creates an immutable, verifiable chain of key state changes.
Ambient Verifiability: Because KELs are self-contained verifiable data structures, any party can verify the authenticity of signed messages by processing the KEL from inception to the current event. This verification requires no trust in DNS, certificate authorities, or network infrastructure—only access to the KEL itself.
Encryption Independence: While KERI mandates signing for authenticity, encryption for confidentiality is handled through complementary protocols like SPAC (Secure Privacy, Authenticity, and Confidentiality). This separation allows KERI to focus on its core competency (authenticity and key management) while enabling flexible confidentiality solutions.
KERI's E2E provenance extends beyond simple message authentication to track the complete lifecycle of data transformations:
Verifiable Data Chains: Using ACDCs (Authentic Chained Data Containers), KERI creates cryptographically linked chains of credentials and data transformations. Each ACDC includes SAIDs (Self-Addressing Identifiers) that cryptographically bind the container to its content. When ACDCs reference other ACDCs through edges, they create verifiable provenance chains.
Transaction Event Logs (TELs): For credential lifecycle management, TELs provide E2E provenance of issuance, revocation, and status changes. Each TEL event is anchored to the issuer's KEL, creating a verifiable audit trail that spans from credential creation through all state changes.
Seal Mechanism: KERI's seal mechanism enables anchoring arbitrary data to specific key states. A seal is a cryptographic digest included in a KEL event, creating a verifiable timestamp and attribution for external data. This allows E2E provenance tracking for data that exists outside the KEL itself.
Monotonic Updates: KERI implements the RUN (Read, Update, Nullify) model rather than traditional CRUD (Create, Read, Update, Delete). This ensures that all data transformations are append-only and verifiable, preventing deletion attacks that could break provenance chains.
Several KERI innovations are essential to achieving true E2E properties:
Pre-Rotation: By including cryptographic commitments to next keys in current events, KERI enables secure key rotation without breaking the E2E verification chain. Even if current signing keys are compromised, the pre-rotated keys (which were never exposed) can be used to rotate to new keys, maintaining E2E security across the identifier's lifetime.
Duplicity Detection: KERI's witness and watcher infrastructure enables ambient duplicity detection—any party can detect if a controller creates conflicting versions of their KEL. This property is essential for E2E security because it prevents controllers from presenting different key states to different parties.
Portability: Unlike blockchain-based identifiers that are locked to specific ledgers, KERI identifiers are portable across any infrastructure. This portability is crucial for E2E properties because it ensures verification doesn't depend on the availability or trustworthiness of any particular platform.
CESR Encoding: The Composable Event Streaming Representation provides efficient, self-framing encoding for all KERI primitives. This enables E2E streaming of verifiable data across diverse transport mechanisms (HTTP, TCP, QUIC) while maintaining cryptographic integrity.
The E2E properties in KERI have significant practical implications for system design and deployment:
KERI's E2E approach enables true zero-trust computing where no infrastructure component requires trust. Applications can verify all data cryptographically without assuming network security, server integrity, or intermediary honesty. This is particularly valuable in:
Because E2E verification doesn't require centralized infrastructure, KERI systems can scale horizontally. Each identifier's KEL can be verified independently, enabling:
E2E properties enable sophisticated privacy mechanisms:
Achieving true E2E properties requires careful implementation:
Key Management: Controllers must protect private keys throughout the identifier lifecycle. KERI's pre-rotation provides recovery mechanisms, but initial key generation and storage remain critical.
Witness Coordination: While witnesses don't require trust for security, they provide availability and duplicity detection. Configuring appropriate witness pools and thresholds requires understanding the threat model.
Performance Considerations: E2E verification requires processing KELs from inception. For long-lived identifiers with many events, this can impact performance. Implementations must balance verification thoroughness with responsiveness.
Interoperability: E2E properties are only valuable if all parties in a workflow implement compatible verification. Establishing common schemas, protocols, and verification policies requires coordination.
KERI's E2E properties are particularly valuable in:
The E2E principle in KERI represents a fundamental shift from infrastructure-dependent security to cryptographically-grounded verification, enabling truly decentralized, verifiable, and portable digital identity systems.