Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 37 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.
A secondary root-of-trust is a verifiable data structure that depends on a primary root-of-trust for its secure attribution, achieving trustability through cryptographic anchoring via seals to the primary root, while maintaining automatic verifiability despite its derivative nature.
A secondary root-of-trust represents a hierarchical trust architecture concept where certain verifiable data structures derive their security guarantees from cryptographic binding to more foundational trust anchors. Unlike primary roots-of-trust which are self-certifying and provide their own cryptographic proof of integrity, secondary roots-of-trust achieve trustability through verifiable linkage to these primary foundations.
The core properties of a secondary root-of-trust include:
The scope of secondary roots-of-trust encompasses any verifiable data structure that extends or builds upon a primary cryptographic foundation while maintaining end-to-end verifiability through the chain of cryptographic commitments.
The concept of hierarchical trust structures has deep roots in cryptographic systems and public key infrastructure (PKI). Traditional PKI systems employ certificate chains where intermediate Certificate Authorities (CAs) derive their authority from root CAs. However, these traditional hierarchies rely on administrative trust rather than purely cryptographic mechanisms.
In blockchain and distributed ledger systems, the concept evolved toward algorithmic trust, where consensus mechanisms provide secondary trust layers built atop cryptographic primitives. However, these systems typically require shared governance and global consensus, creating dependencies on distributed infrastructure.
When implementing systems using secondary roots-of-trust, several architectural decisions must be made:
Anchoring Frequency: Determine how often secondary root events should be anchored to the primary root. More frequent anchoring provides tighter temporal binding but increases KEL size and signing overhead. Less frequent anchoring reduces overhead but may create larger windows of unanchored events.
Seal Placement: Decide which KEL event types will carry seals. Interaction events are typical for anchoring external data, but rotation events can also carry seals when key state changes need to be synchronized with secondary root updates.
Verification Strategy: Implement efficient verification paths that can validate secondary roots without requiring full KEL replay. This may involve caching key states or using witness receipts to shortcut verification.
Primary Root Protection: Since secondary roots inherit security from primary roots, the primary root (KEL) must be protected with the highest security measures. Compromise of the KEL compromises all anchored secondary roots.
Seal Integrity: The seal mechanism must use cryptographically strong hash functions (minimum 128-bit security strength). KERI specifies CESR-compatible algorithms like Blake3-256.
Temporal Binding: Seals create temporal ordering—a secondary root event cannot have occurred before the KEL event that seals it. This property is critical for establishing event chronology and must be preserved in implementation.
TEL Management: For credential lifecycle management, implement TEL creation and anchoring as atomic operations. A credential issuance should create both the ACDC and its TEL entry, with the TEL entry sealed in a KEL interaction event.
Delegation Chains: When implementing delegation hierarchies, ensure that each delegated identifier's KEL is properly anchored to its delegator's KEL. This creates a verifiable chain of authority that can be traversed for validation.
Infrastructure Independence: Design systems to treat secondary roots as portable. Storage locations, witness pools, and verification infrastructure should be replaceable without breaking the cryptographic binding to the primary root.
Batch Anchoring: When multiple secondary root events need anchoring, batch them into a single Merkle tree and anchor only the root. This reduces KEL size while maintaining verifiability of individual events.
The evolution toward autonomic trust represents a paradigm shift where trust hierarchies are established purely through cryptographic proofs without requiring either administrative oversight or shared algorithmic consensus. This evolution recognizes that different trust layers serve different purposes and that not all trust anchors need to be primary—some can be derivative while maintaining verifiability.
KERI formalizes the distinction between primary and secondary roots-of-trust as a fundamental architectural principle. In KERI's trust architecture:
The Key Event Log (KEL) serves as KERI's primary root-of-trust. It is:
The KEL provides what KERI terms a cryptographic root-of-trust rather than an administrative or algorithmic one, meaning trust is established through verifiable cryptographic operations alone.
The Transaction Event Log (TEL) exemplifies KERI's secondary root-of-trust. The TEL:
The connection between secondary and primary roots-of-trust is established through seals—cryptographic commitments in the form of digests or Merkle roots. When a TEL event is created:
This anchoring mechanism provides several critical properties:
KERI's approach to secondary roots-of-trust offers several advantages over traditional hierarchical trust systems:
No Administrative Overhead: Unlike PKI certificate chains that require administrative processes for intermediate CA management, KERI's secondary roots are purely cryptographic. There are no certificate signing requests, no manual verification procedures, and no administrative revocation lists.
No Shared Governance: Unlike blockchain-based systems where secondary layers (like smart contracts) depend on distributed consensus, KERI's secondary roots require no shared governance. Each AID controller independently manages their own TELs anchored to their own KELs.
Cryptographic Continuity: The seal mechanism ensures that even if infrastructure changes (witnesses are rotated, storage locations move, etc.), the cryptographic binding between secondary and primary roots remains verifiable. This enables true portability of trust.
Graduated Security: The architecture allows for different security levels at different layers. The KEL can use the highest security key management practices (HSMs, multi-sig, etc.) while TELs can use more practical approaches, knowing they inherit security from their anchoring.
Scalability: Secondary roots can be created, managed, and verified independently without requiring global coordination. This enables horizontal scaling where each entity manages its own trust structures.
Credential Lifecycle Management: The most prominent use case for secondary roots-of-trust in KERI is managing verifiable credential lifecycles. A TEL tracks the issuance and revocation state of ACDCs, with each state change anchored to the issuer's KEL. This enables:
Delegation Hierarchies: In KERI's delegation model, delegated identifiers form secondary roots-of-trust anchored to their delegator's KEL. This enables:
Multi-Signature Coordination: When multiple parties must coordinate on shared decisions, secondary roots can track the coordination state while each party maintains their own primary root (KEL). This enables:
Separation of Concerns: Secondary roots-of-trust enable clean architectural separation between different trust layers. Key management (KEL) is separated from credential management (TEL), allowing each to be optimized independently.
Flexible Infrastructure: Because secondary roots are replaceable, infrastructure can evolve without breaking trust. TEL storage can move between systems, witness pools can be reconfigured, and verification infrastructure can be upgraded—all while maintaining cryptographic continuity.
Reduced Complexity: Not every trust decision requires the full security apparatus of a primary root. Secondary roots allow for graduated security where appropriate, reducing operational complexity and cost.
Enhanced Privacy: Secondary roots can be selectively disclosed. A controller might share a TEL proving credential revocation status without revealing their entire KEL history, enabling privacy-preserving verification.
Dependency Risk: Secondary roots depend on the integrity of their primary roots. If a KEL is compromised, all anchored TELs inherit that compromise. This creates a single point of failure at the primary root level.
Verification Overhead: Verifying a secondary root requires also verifying its anchoring to the primary root. This adds computational overhead compared to verifying a self-contained data structure.
Complexity of Understanding: The hierarchical trust model requires understanding both the primary and secondary layers and their relationship. This conceptual complexity can be a barrier to adoption.
Anchoring Latency: Creating a secondary root event requires anchoring it to the primary root, which may introduce latency if the primary root is not immediately available for signing.
Despite these trade-offs, KERI's secondary root-of-trust architecture provides a powerful mechanism for building scalable, verifiable trust systems that maintain cryptographic integrity while enabling practical operational flexibility. The key insight is that not all trust must be primary—derivative trust can be equally verifiable when properly anchored through cryptographic commitments.
Lazy Verification: Implement verification strategies that defer secondary root verification until needed. Not every operation requires full verification of the anchoring chain.
Caching Strategies: Cache verified secondary root states to avoid repeated verification overhead. Invalidate caches when the primary root (KEL) changes state.