Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 24 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.
In identifier systems, univalent means having a unique and non-ambiguous identifier for each entity, establishing a one-to-one correspondence. In KERI key management, it refers to an infrastructure where key-pair generation/storage and event signing facilities are co-located and share protection mechanisms.
Univalent is a term with two distinct but related meanings in the KERI ecosystem, both emphasizing uniqueness and singular correspondence:
General Identifier Systems Context: Univalent describes the property of having a unique and non-ambiguous identifier for each entity or resource, establishing a one-to-one correspondence between identifiers and entities. No two different entities share the same identifier, and each identifier maps to exactly one entity.
KERI Key Management Architecture: Univalent refers to a specific infrastructure pattern where key-pair generation/storage facilities and key event signing facilities are co-located within a single combined infrastructure that shares protection mechanisms.
The term "univalent" derives from mathematical and logical usage meaning "single-valued" or "having one value," emphasizing the unified, singular nature of the relationship or infrastructure.
In the identifier systems sense, univalent identifiers exhibit:
In the key management sense, univalent infrastructure exhibits:
When designing KERI-based systems, evaluate whether univalent infrastructure is appropriate:
Security Requirements:
Operational Constraints:
Cost Considerations:
For univalent infrastructure implementations:
Organizations should establish policies defining:
The concept of univalent identifiers relates to fundamental requirements in distributed systems and cryptographic identity:
Traditional identifier systems have long struggled with ensuring uniqueness:
The challenge has been achieving uniqueness without centralized coordination while maintaining security and usability.
Historically, cryptographic key management has evolved through several paradigms:
The univalent pattern represents a specific architectural choice within this evolution, prioritizing security through co-location while accepting trade-offs in convenience and performance.
KERI's Autonomic Identifiers (AIDs) are inherently univalent in the identifier systems sense. Each AID is:
This univalent property is fundamental to KERI's security model. The Key Event Log (KEL) for each AID provides a verifiable history proving continuous control authority, and the univalent nature ensures that each KEL corresponds to exactly one identifier and controller.
In Samuel Smith's Universal Identifier Theory, univalent key management infrastructure is defined as a system where:
Key Management Components:
Univalent Architecture: These two infrastructures are co-located, meaning they share facilities and protection mechanisms. As stated in the source documents:
"To protect both the key generation and storage and the event signing infrastructures... a given protection mechanism may co-locate both infrastructures. This means facilities are shared. This combined infrastructure is referred to as a univalent key management infrastructure."
A univalent key management infrastructure in KERI:
Advantages:
Trade-offs:
As explicitly noted in source documents: univalent infrastructure is "more secure albeit less convenient or performant."
KERI's theoretical framework includes three key management patterns:
The univalent pattern represents the foundational approach, while bivalent and multi-valent introduce additional complexity to address specific scalability or security requirements. Organizations choose among these patterns based on their security-cost-performance trade-off requirements.
In KERI implementations, the univalent pattern is most appropriate when:
For example, a root AID controlling a critical delegation hierarchy might employ univalent infrastructure with hardware security modules, accepting performance trade-offs for maximum security.
The univalent property of KERI identifiers has critical practical implications:
Trust and Verification: Because each AID is univalent (one-to-one with its controller), validators can trust that:
This eliminates ambiguity in secure attribution - the fundamental problem KERI solves.
Collision Resistance: The cryptographic derivation of AIDs provides practical collision resistance. With 128+ bits of entropy, the probability of two different controllers generating the same AID is negligible (approximately 2^-128), making univalent identifiers practically guaranteed in real-world deployments.
Namespace Management: The univalent property enables Autonomic Namespaces (ANs) where:
Choosing a univalent key management infrastructure involves specific trade-offs:
When to Use Univalent:
When to Consider Alternatives:
The univalent pattern represents a specific point on the security-cost-performance architecture trade-off spectrum:
Security: Highest - unified protection, potential for specialized hardware, concentrated security controls
Cost: Moderate to High - may require specialized hardware (HSMs), but simpler operational model reduces ongoing costs
Performance: Lower - co-located infrastructure may not optimize for signing throughput, single facility limits parallelization
Organizations must evaluate their specific requirements against these trade-offs. A Legal Entity issuing vLEI Credentials might use univalent infrastructure for its root AID while delegating to multi-valent infrastructure for high-volume credential issuance operations.
Practical univalent implementations in KERI might include:
Hardware-Based Univalent:
Software-Based Univalent:
Air-Gapped Univalent:
The univalent property affects governance frameworks:
vLEI Ecosystem: The GLEIF root AID likely employs univalent infrastructure given its critical role as the trust root for the entire ecosystem. This architectural choice reflects the security-first priority for root governance.
Delegation Policies: Organizations must define policies for when univalent infrastructure is required versus when multi-valent or bivalent patterns are acceptable. These policies balance security requirements against operational needs.
Audit and Compliance: Univalent infrastructure simplifies audit trails since all key operations occur in a single, controlled facility. This can be advantageous for regulatory compliance in financial services or government applications.