A nested hierarchical delegation architecture in KERI where each layer of delegated identifiers wraps the next higher layer with compromise recovery protection, maintaining root-layer security properties throughout the entire delegation tree even when leaf nodes employ less secure key management methods.
Related Concepts
No related concepts available
Comprehensive Explanation
Bivalent Key Management Infrastructure
Conceptual Definition
Bivalent describes a sophisticated delegation architecture pattern in KERI where nested sets of layered delegations form a tree structure with built-in compromise recovery protection at each hierarchical layer. The term "bivalent" (meaning "having two values" or "two-fold") refers to the dual nature of this architecture: it maintains two independent key management infrastructures—one for the delegator and one for the delegate—that cooperate at the protocol level while remaining completely isolated at the implementation level.
The core principle is that each layer in the delegation tree wraps the next layer with compromise recovery protection from the higher layer. This architectural design maintains the security properties of the root layer for compromise recovery all the way out to the leaf nodes, even when those leaves employ less secure key management methods than the root. This creates a security gradient where the most critical root identifiers can use high-security key management (such as hardware security modules or air-gapped systems) while operational leaf identifiers can use more convenient software-based key management without compromising the overall system's recoverability.
Key Properties
Hierarchical Protection: Each delegation layer adds an additional security boundary that protects all layers below it
Complete Infrastructure Isolation: Delegator and maintain entirely separate key generation, storage, and signing infrastructures
Cascading Recovery: Compromise at lower layers can be recovered through the security of higher layers
Heterogeneous Security: Different security levels can coexist in the same delegation tree without compromising overall system security
Scope and Boundaries
Bivalent architecture applies specifically to cooperative delegation scenarios in KERI where both delegator and delegate must contribute cryptographic commitments to establish the delegation relationship. It does not apply to simple single-identifier scenarios or to delegation models where the delegator has complete unilateral control. The bivalent pattern is most relevant for organizational hierarchies, enterprise deployments, and scenarios where different parts of a system require different security postures while maintaining verifiable trust relationships.
Historical Context
The concept of bivalent key management emerges from the broader challenge of the security-cost-performance architecture trade-off in cryptographic systems. Traditionally, key management systems faced a fundamental tension:
High-security key management (hardware security modules, air-gapped systems, multi-party computation) provides strong protection but is expensive, slow, and operationally complex
Convenient key management (software wallets, cloud-based key storage) enables rapid operations and user-friendly experiences but exposes keys to greater compromise risk
Organizational hierarchies naturally have different security requirements at different levels (executive vs. operational, strategic vs. tactical)
Historically, organizations addressed this through various approaches:
Traditional PKI Hierarchies
In traditional Public Key Infrastructure (PKI) systems, Certificate Authorities (CAs) maintain root certificates in highly secure environments while issuing intermediate and end-entity certificates with progressively lower security requirements. However, these systems suffer from:
Administrative trust dependencies: The entire system relies on the CA's operational security
Revocation challenges: Certificate revocation is notoriously difficult and often ineffective
No cryptographic recovery: Compromise of intermediate keys cannot be cryptographically recovered
Blockchain Delegation Models
Blockchain-based identity systems attempted to address some PKI limitations through on-chain delegation records. However, these approaches introduced new problems:
Infrastructure lock-in: Identifiers become bound to specific ledgers
Performance constraints: On-chain operations are slow and expensive
Privacy concerns: Delegation relationships are publicly visible
Consensus dependencies: System security depends on blockchain consensus mechanisms
The Need for Autonomic Delegation
The bivalent concept emerged from recognizing that truly self-sovereign identity requires delegation mechanisms that:
Maintain cryptographic verifiability without trusted intermediaries
Enable hierarchical security gradients appropriate to organizational needs
Provide cryptographic recovery mechanisms for compromised keys
Preserve identifier portability across infrastructures
Support complete independence of key management systems
Samuel Smith's Universal Identifier Theory formalized these requirements and introduced the bivalent pattern as a solution that achieves all these properties simultaneously through KERI's cooperative delegation mechanism.
KERI's Approach
Cooperative Delegation Foundation
KERI's bivalent architecture builds on its fundamental cooperative delegation mechanism, where both delegator and delegate must contribute cryptographic commitments to establish a delegation relationship. This cooperation occurs through:
Delegate Commitment: The delegate creates a cryptographic commitment in its establishment event via a seal to the delegating event
Mutual Verification: Both parties can independently verify the delegation relationship through their respective Key Event Logs (KELs)
Complete Key Management Isolation
The bivalent model achieves security through complete isolation of key management functions between delegator and delegate:
Independent Key Generation
Each party generates their controlling private keys using completely separate systems:
Delegator: May use high-security key generation (HSMs, air-gapped systems, multi-party computation)
Delegate: May use standard software-based key generation appropriate to operational needs
No Shared Entropy: No common randomness or seed material is required between parties
No Key Exchange: Private keys never move between the two infrastructures
This independence means that compromise of the delegate's key generation system cannot affect the delegator's keys, and vice versa. Each party maintains complete control over their own cryptographic material.
Isolated Key Storage
Private keys are stored in completely separate infrastructures:
Delegator Storage: May use cold storage, hardware security modules, or distributed key shares
Delegate Storage: May use hot wallets, cloud key management services, or local encrypted storage
No Shared Access: Neither party requires access to the other's key storage
Independent Security Policies: Each party can implement security policies appropriate to their risk profile
The storage isolation ensures that even if an attacker compromises the delegate's storage infrastructure, the delegator's keys remain protected in their separate infrastructure.
Separate Event Signing
Each party signs their own key events independently:
Delegator Events: Signed using delegator's current signing keys
Delegate Events: Signed using delegate's current signing keys
No Co-signing Required: Neither party needs to participate in the other's signing operations
Asynchronous Operations: Signing can occur at different times and locations
This separation means that operational signing by delegates does not expose the delegator's signing keys to operational risks.
Nested Delegation Trees
The bivalent architecture supports recursive delegation where each delegate can become a delegator for its own delegates:
Bivalent architecture enables enterprises to map their organizational structure to their identity infrastructure:
Corporate Root Identity:
Board-controlled root AID with maximum security
Stored in HSM with multi-signature requirements
Only used for delegating to division-level identifiers
Rotated annually or when board composition changes
Division-Level Identities:
Delegated from corporate root
Managed by division leadership
Medium security (hardware wallets, dual signatures)
Used for delegating to department-level identifiers
Department-Level Identities:
Delegated from division identifiers
Managed by department heads
Standard security (encrypted software wallets)
Used for delegating to employee identifiers
Employee Operational Identities:
Delegated from department identifiers
Managed by individual employees
Optimized for convenience (mobile wallets)
Used for daily operational signing
Recovery Scenario: If an employee's device is compromised, the department can revoke that delegation and issue a new employee identifier without affecting any other part of the hierarchy.
Used for tracking individual products through supply chain
Benefit: Complete provenance chain from manufacturer root to individual item, with ability to revoke compromised batch identifiers without affecting other batches.
Personal Identity Management
Individuals can use bivalent architecture for personal identity management:
Master Identity:
High-security root stored in hardware wallet or paper backup
Rarely used (only for delegation)
Kept in safe or safety deposit box
Device Identities:
Delegated from master identity
One per device (phone, laptop, tablet)
Medium security (device secure enclaves)
Application Identities:
Delegated from device identities
One per application or service
Optimized for convenience
Recovery Scenario: If phone is lost, master identity can revoke phone's delegation and create new delegation to replacement phone, without affecting laptop or tablet identities.
Use Cases
Enterprise Access Control: Hierarchical delegation of access rights matching organizational structure
IoT Device Management: Root device identity delegates to sensor identities with operational security
Government Services: National identity delegates to regional, then local service identifiers
Healthcare Systems: Hospital root delegates to department, then provider identifiers
Financial Services: Bank root delegates to branch, then account manager identifiers
Educational Institutions: University root delegates to college, then department, then faculty identifiers
Multi-National Corporations: Global root delegates to regional, then country, then local identifiers
Trade-offs
Complexity vs. Security
Benefit: Hierarchical delegation provides strong security through layered protection
Cost: More complex to implement and manage than flat identifier structures
Cost: Requires maintaining parent infrastructure even for operational identifiers
Mitigation: Parent operations are infrequent (only for delegation/revocation)
Privacy vs. Verifiability
Benefit: Complete delegation chain is cryptographically verifiable
Cost: Verifiers can see delegation relationships
Mitigation: Selective disclosure - only share delegation chain with verifiers who need it
Flexibility vs. Governance
Benefit: Each level can choose appropriate security measures
Cost: Requires governance policies for security requirements at each level
Mitigation: Clear organizational policies and automated compliance checking
Performance Considerations
Verification Overhead: Verifying a deeply nested delegation requires validating the entire chain of KELs from root to leaf. However:
KELs are compact and efficient to verify
Verification can be cached
Only needs to be done once per delegation relationship
Parallel verification of multiple branches is possible
Delegation Latency: Creating a new delegation requires coordination between parent and child. However:
Delegation is infrequent compared to operational signing
Can be done asynchronously
No consensus or blockchain confirmation required
Typically completes in seconds
Storage Requirements: Each level maintains its own KEL. However:
KELs are append-only and compress well
Only active delegation paths need to be stored
Historical KELs can be archived
Total storage is typically kilobytes per identifier
Relationship to Other KERI Concepts
Bivalent architecture relates to and builds upon several other KERI concepts:
Univalent vs. Bivalent vs. Multivalent
Univalent: Single key management infrastructure where key generation and signing are co-located
Bivalent: Two independent key management infrastructures (delegator and delegate) that cooperate
Multivalent: Multiple delegates from single delegator, enabling horizontal scalability
Bivalent focuses on the vertical delegation relationship (parent-child), while multivalent focuses on horizontal scalability (one parent, many children). Both can be combined: a bivalent hierarchy can have multivalent branching at each level.
Cooperative Delegation
Bivalent architecture is only possible because of KERI's cooperative delegation mechanism, where both parties must contribute cryptographic commitments. This cooperation enables:
Independent key management
Mutual verification
Cryptographic binding without shared secrets
Revocable delegation
Pre-Rotation and Recovery
The security of bivalent architecture depends on KERI's pre-rotation mechanism:
Each level pre-commits to next rotation keys
Compromise of current keys doesn't compromise pre-rotated keys
Parent can rotate to revoke compromised child delegation
Post-quantum security through digest-based commitments
Each level is a self-certifying, self-managing identifier
No external authority required at any level
Complete portability of entire hierarchy
Universal verifiability through KEL chains
Conclusion
Bivalent key management infrastructure represents a fundamental advancement in hierarchical identity systems. By combining KERI's cooperative delegation with complete key management isolation, it enables organizations to create security gradients that match their operational needs while maintaining cryptographic recoverability throughout the hierarchy. This architecture solves the long-standing tension between security and convenience in key management, enabling truly self-sovereign identity at organizational scale.
Recovery Drills: Regularly test delegation revocation and re-establishment procedures