A novel delegation mechanism in KERI where both the delegator and delegate must actively participate through cryptographic commitments to establish and maintain the delegation relationship, enabling secure key management hierarchies with built-in compromise recovery.
Related Concepts
No related concepts available
Comprehensive Explanation
cooperative-delegation
Conceptual Definition
Cooperative delegation represents a fundamental architectural pattern in KERI that addresses the inherent trade-offs between security, cost, and performance in key management systems. Unlike traditional delegation models where authority is unilaterally transferred, KERI's cooperative delegation requires active cryptographic participation from both parties:
The delegator maintains ultimate control authority and creates cryptographic commitments in their key event log
The delegate receives derived authority but must also create corresponding cryptographic commitments
Both parties must cooperate for delegation establishment, rotation, and recovery operations
This bilateral cooperation creates a mutually dependent relationship that enhances security through layered protection. The delegator's key management infrastructure serves as a protective layer for the delegate's keys, enabling recovery from compromise scenarios that would be catastrophic in traditional delegation models.
Key Properties:
Bilateral Cryptographic Commitment: Both delegator and delegate sign events that reference each other, creating verifiable proof of mutual agreement
Hierarchical Security: The delegator's key management protects the delegate's keys through recovery mechanisms
Compromise Recovery: If delegate keys are compromised, the delegator retains ability to recover control
Recursive Application: Delegates can themselves become delegators, enabling arbitrarily deep delegation trees
Non-Repudiable Authorization: All delegation relationships are cryptographically verifiable through key event logs
Scope and Boundaries:
Cooperative delegation operates on within KERI, not on individual operations or permissions. It establishes a persistent hierarchical relationship between autonomic identifiers (AIDs) that affects all subsequent key management operations. The delegation relationship continues until explicitly revoked or the delegator rotates keys to exclude the delegate.
Implementation Notes
Delegation Event Coordination
Implementing cooperative delegation requires careful coordination of event creation and signing:
Delegator Workflow:
Delegate provides their delegated inception event to delegator
Delegator verifies the event structure and key configuration
Delegator creates rotation or interaction event with seal referencing delegate event
Delegator signs and publishes their event to witnesses
Delegator provides confirmation to delegate
Delegate Workflow:
Delegate creates delegated inception event with di field set to delegator AID
Delegate waits for delegator's sealing event
Delegate verifies delegator's seal matches their inception event
Delegate signs and publishes their inception event
Delegation is now established and verifiable
Validation Requirements
Validators must verify delegation chains by:
Retrieving both delegator and delegate KELs
Locating the delegator's sealing event
Extracting the seal and verifying it references the delegate's event
Verifying the delegate's event references the delegator
Checking all signatures on both events
Confirming the delegation chain is unbroken through any rotations
Recovery Procedures
Implementing superseding recovery requires:
Detecting compromise of delegate keys (through duplicity detection or other means)
Delegator creates rotation event for delegate with new keys
Delegator seals this rotation in their own KEL
Delegate (with recovered keys) signs the rotation event
The superseding rotation invalidates any malicious rotations
Performance Optimization
For deep delegation hierarchies:
Cache validated delegation chains to avoid repeated KEL retrieval
Use witness pools to ensure high availability of delegation events
Implement parallel validation of independent delegation branches
Consider delegation depth limits based on performance requirements
Security Considerations
Delegator Key Management:
Delegators must use high-security key management since they protect all descendants. Consider:
Hardware security modules (HSMs) for root delegators
identifier prefixes
Historical Context
Traditional Delegation Models
Traditional PKI and identity systems typically implement unilateral delegation where:
A certificate authority issues certificates to subordinate entities
The subordinate has full authority within their scope
Compromise of subordinate keys results in permanent loss of control
Recovery requires out-of-band intervention and certificate revocation
No cryptographic mechanism exists for the delegator to recover the delegate's identifier
Blockchain-based delegation improved on this by:
Recording delegation relationships on-chain for transparency
Enabling programmatic revocation through smart contracts
Providing immutable audit trails of delegation events
However, blockchain approaches still suffered from:
Infrastructure lock-in: Delegation tied to specific ledgers
Unilateral control: Delegates operate independently once authorized
No compromise recovery: Compromised delegate keys cannot be recovered by delegator
Performance costs: On-chain operations required for all delegation changes
Evolution to Cooperative Models
The concept of cooperative delegation emerged from recognizing that security and operational efficiency are not zero-sum. By requiring bilateral participation:
Security increases through layered protection
Operational costs can be distributed across the hierarchy
Performance can be optimized at different levels
Recovery mechanisms become cryptographically enforceable
KERI's implementation represents the first protocol to make cooperative delegation a first-class primitive with formal cryptographic guarantees, rather than an add-on feature.
KERI's Approach
Delegation Event Structure
KERI implements cooperative delegation through delegated establishment events that require coordination between both parties:
Delegator's Commitment:
The delegator creates a rotation event or interaction event in their KEL
The sequence number of the delegated event (s field)
A cryptographic digest of the delegated event (d field)
The delegator signs this event with their current authoritative keys
Delegate's Commitment:
The delegate creates a delegated inception event (dip) or delegated rotation event (drt)
This event includes:
The di field containing the delegator's AID prefix
The delegate's own key configuration
Pre-rotated key commitments for future rotations
The delegate signs this event with their keys
Mutual Verification:
Validators can verify the delegation by:
Retrieving both the delegator's KEL and delegate's KEL
Confirming the delegator's seal references the delegate's inception event
Confirming the delegate's inception event references the delegator
Verifying all cryptographic signatures
Checking that the delegation chain is unbroken
This bilateral structure ensures that neither party can unilaterally assert a delegation relationship. The cryptographic commitments in both KELs provide non-repudiable proof of the cooperative agreement.
Security Through Superseding Recovery
The most significant security innovation in cooperative delegation is the superseding recovery mechanism:
Compromise Scenario:
An attacker compromises a delegate's current signing keys
The attacker attempts to rotate the delegate's keys to gain permanent control
However, the delegate's rotation event requires a seal from the delegator
The legitimate delegator refuses to seal the malicious rotation
The delegator can issue a superseding rotation that:
Rotates the delegate's keys to new, secure keys
Invalidates the attacker's attempted rotation
Restores control to the legitimate delegate
Recursive Protection:
This recovery mechanism applies recursively through delegation trees:
A root delegator can recover any descendant delegate
Intermediate delegates can recover their own delegates
The security of higher levels protects lower levels
Leaf nodes can use less expensive key management while benefiting from root security
Key Management Isolation:
Crucially, cooperative delegation enables complete isolation between delegator and delegate key management:
Each party generates their own keys independently
No shared secrets or key material exchange required
Each party maintains their own key storage infrastructure
No trust assumptions about the other party's key handling
This isolation is fundamental to KERI's security model, preventing the "shared secret" vulnerabilities that plague traditional delegation systems.
Differences from Traditional Approaches
Cryptographic vs. Administrative:
Traditional delegation relies on administrative policies and certificate chains. KERI's cooperative delegation is purely cryptographic—the delegation relationship is proven through verifiable data structures (KELs) without requiring trust in certificate authorities or policy enforcement mechanisms.
Portable vs. Infrastructure-Locked:
Blockchain-based delegation locks identifiers to specific ledgers. KERI's delegation is infrastructure-independent—the KELs can be witnessed by any infrastructure (witnesses, ledgers, file systems) without changing the delegation relationship.
Recoverable vs. Permanent:
Traditional delegation treats key compromise as catastrophic, requiring complete identifier abandonment. KERI's cooperative delegation provides cryptographic recovery paths that restore control without changing identifiers.
Bilateral vs. Unilateral:
Most delegation systems allow unilateral assertion of delegation. KERI requires mutual cryptographic commitment, preventing unauthorized delegation claims and providing non-repudiable proof of agreement.
Benefits
Security Benefits:
Compromise Recovery: Delegators can recover delegates from key compromise
Layered Protection: Multiple security boundaries in delegation hierarchies
No Shared Secrets: Complete key management isolation between parties
Cryptographic Proof: Non-repudiable evidence of delegation relationships
Duplicity Detection: KERI's ambient verifiability applies to delegation events
Performance Optimization: Different security/performance trade-offs at different hierarchy levels
Cost Distribution: Expensive key management at root, cheaper operations at leaves
Flexible Governance: Delegation trees can mirror organizational structures
Infrastructure Independence: No lock-in to specific platforms or ledgers
Architectural Benefits:
Separation of Concerns: Signing authority can be separated from rotation authority
Custodial Arrangements: Enables secure delegation to service providers
Multi-Valent Structures: Single delegator can have multiple delegates
Bivalent Security: Nested delegations wrap each layer with compromise recovery
Composability: Delegation primitives combine with other KERI features
Practical Implications
Use Cases
Enterprise Key Management:
Large organizations can implement hierarchical delegation structures that mirror their organizational chart:
Root AID controlled by board of directors with maximum security
Department AIDs delegated from root with moderate security
Project AIDs delegated from departments with operational security
Individual employee AIDs delegated from projects with convenience-focused security
If any lower-level AID is compromised, the parent can recover it without disrupting the entire hierarchy.
Custodial Services:
Service providers can offer custodial key management while users retain ultimate control:
User creates root AID with high-security key management
User delegates operational AID to custodial service
Service performs day-to-day signing operations
User retains rotation authority and can "fire" the custodian at any time
If service is compromised, user can recover the delegated AID
This enables convenient cloud services without sacrificing self-sovereignty.
Supply Chain Management:
Manufacturers can delegate authority to distributors and retailers:
Manufacturer creates root AID for product line
Distributors receive delegated AIDs for regional operations
Retailers receive delegated AIDs for point-of-sale operations
Each level can issue credentials within their scope
Manufacturer can revoke or recover any downstream AID if needed
This creates verifiable chain-of-custody while enabling distributed operations.
IoT Device Management:
Device manufacturers can implement scalable device identity:
Manufacturer root AID with maximum security
Product line AIDs delegated from root
Individual device AIDs delegated from product line
Devices use lightweight key management
Manufacturer can recover compromised devices remotely
Security of root protects entire device fleet
Credential Issuance Hierarchies:
The vLEI ecosystem demonstrates cooperative delegation at scale:
GLEIF root AID as ultimate trust anchor
QVI (Qualified vLEI Issuer) AIDs delegated from GLEIF
Legal Entity AIDs receive credentials from QVIs
Role credentials delegated from Legal Entity AIDs
Each level can be recovered by its parent
Benefits
Security Without Centralization:
Cooperative delegation provides enterprise-grade security without requiring centralized infrastructure. The cryptographic recovery mechanisms work across any infrastructure that can store and serve KELs.
Operational Flexibility:
Organizations can optimize the security-cost-performance trade-off at each hierarchy level. High-value root identifiers use expensive HSMs, while operational identifiers use convenient software wallets, all protected by the root's recovery capability.
Regulatory Compliance:
The non-repudiable audit trail of delegation events provides compliance evidence for regulations requiring proof of authorization and chain-of-custody.
Disaster Recovery:
The superseding recovery mechanism provides cryptographic disaster recovery that doesn't require out-of-band coordination or trust in third parties.
Trade-offs
Coordination Overhead:
Cooperative delegation requires coordination between parties for establishment and rotation events. This adds complexity compared to unilateral delegation, though the security benefits typically justify the overhead.
Delegator Availability:
Delegates depend on delegators for certain operations, particularly recovery. If a delegator's keys are lost, delegates cannot be recovered. This requires careful key management at higher hierarchy levels.
Complexity:
Implementing cooperative delegation correctly requires understanding KERI's event structure, seal mechanisms, and validation rules. The bilateral nature adds implementation complexity compared to simpler delegation models.
Performance Considerations:
Validating delegation chains requires retrieving and verifying multiple KELs. For deep hierarchies, this can impact performance, though caching and optimization strategies can mitigate this.
Governance Challenges:
Organizations must establish clear policies for when and how delegators should approve delegate operations. The cryptographic mechanisms enforce cooperation but don't define the governance rules for that cooperation.
Multi-signature schemes for organizational delegators
Geographically distributed key storage
Regular key rotation schedules
Delegation Policies:
Establish clear governance for:
When delegators should approve delegate operations
Conditions for superseding recovery
Delegation depth limits
Key management requirements at each hierarchy level