Comprehensive Explanation

nested-cooperative-delegated-identifiers

Process Definition

Nested cooperative delegated identifiers represent a fundamental delegation mechanism in KERI that enables hierarchical key management through bilateral cryptographic commitments. Unlike traditional unilateral delegation models found in conventional PKI systems, KERI's cooperative delegation requires active participation from both parties:

• The delegator creates a cryptographic commitment in either a rotation event or interaction event via a seal that references the delegated establishment event
• The delegate creates a corresponding cryptographic commitment in its establishment event via a seal pointing back to the delegating event
• Each party signs their respective commitments, creating a bidirectional cryptographic binding

This process accomplishes several critical objectives:

1. Mutual consent enforcement: Neither party can unilaterally establish or modify the delegation relationship
2. Verifiable delegation chains: All commitments are cryptographically verifiable through the KEL
3. Hierarchical security inheritance: Lower-level identifiers benefit from the security posture of their delegating ancestors
4. Compromise recovery: Higher-level keys can rotate out compromised lower-level keys through superseding rotations

The "nested" aspect refers to the recursive application of this cooperative delegation pattern across multiple hierarchical levels, creating arbitrarily deep delegation trees. The "cooperative" aspect emphasizes the bilateral nature of the commitment process, distinguishing it from traditional top-down delegation models.

Process Flow

Step 1: Delegator Initiates Delegation

The delegation process begins when a delegator AID (Autonomic Identifier) decides to delegate authority to a new delegate identifier:

1. Delegator creates delegation seal: The delegator constructs a seal containing a cryptographic commitment to the delegate's inception event
2. Seal anchoring: This seal is embedded in either:
   • A rotation event if the delegator is simultaneously rotating keys
   • An interaction event if only anchoring the delegation without key changes
3. Event signing: The delegator signs this event with its current authoritative keypairs
4. KEL appending: The signed event is appended to the delegator's KEL
5. Witness confirmation: The delegator's witnesses verify and sign receipts for this event

Step 2: Delegate Establishes Identity

The delegate must now create its own identifier with reciprocal commitment:

1. Inception event creation: The delegate constructs an inception event that includes:
   • Its initial key state (current keys and pre-rotated next key digests)
   • A seal referencing the delegator's event that contains the delegation commitment
   • Configuration including witness list and thresholds
2. Delegation seal inclusion: The inception event contains a seal pointing to the specific delegator event (by SAID) that authorized this delegation
3. Event signing: The delegate signs the inception event with its initial keypairs
4. KEL initialization: This inception event becomes the first entry in the delegate's KEL
5. Witness confirmation: The delegate's witnesses verify and sign receipts

Step 3: Bilateral Verification

Validators can now verify the complete delegation relationship:

1. Delegator KEL verification: Retrieve and verify the delegator's KEL up to the event containing the delegation seal
2. Delegation seal extraction: Extract the seal from the delegator's event and verify it commits to the delegate's inception event SAID
3. Delegate KEL verification: Retrieve and verify the delegate's KEL starting from inception
4. Reciprocal seal verification: Verify the delegate's inception event contains a seal referencing the delegator's authorizing event
5. Cryptographic binding confirmation: Confirm both seals create a bidirectional cryptographic linkage

Step 4: Recursive Nesting (Optional)

The delegate can now act as a delegator for its own delegates:

1. Role transition: The delegate becomes a delegator for a new sub-delegate
2. Process repetition: Steps 1-3 repeat with the delegate as delegator
3. Chain extension: This creates a delegation chain: Root → Delegate₁ → Delegate₂ → ... → Delegateₙ
4. Security cascade: Each level inherits recovery capabilities from its parent

Step 5: Superseding Recovery (When Needed)

When a lower-level key is compromised, higher-level recovery activates:

1. Compromise detection: A compromised key at level N is detected
2. Parent rotation: The delegator at level N-1 issues a superseding rotation event
3. Delegation override: This rotation includes a new delegation seal that:
   • References a new inception event for the compromised delegate
   • Effectively "resets" the delegate's key state
   • Supersedes all previous events in the compromised delegate's KEL
4. Recursive application: If level N-1 is also compromised, level N-2 can supersede both
5. Security restoration: The delegation chain is restored with new, uncompromised keys

Technical Requirements

Cryptographic Requirements

Seal Construction:

• Seals must contain cryptographically strong commitments using SAID (Self-Addressing Identifier) digests
• The seal digest must be computed over the complete serialized event being referenced
• Hash functions must provide collision resistance (typically Blake3-256 or SHA3-256)
• Seals must be included in the signed portion of events to prevent tampering

Signature Requirements:

• All events must be signed by the current authoritative keypairs of the signing identifier
• Signatures must meet the signing threshold specified in the current key state
• For multi-sig identifiers, sufficient signatures must be collected before event publication
• Signatures must be indexed to indicate which public key was used

Key State Integrity:

• Each establishment event must include pre-rotated next key digests
• The next key digests commit to keys that will be used in the subsequent rotation
• This pre-rotation mechanism enables post-quantum security through key hiding
• Delegated identifiers must maintain their own independent key state

Timing Considerations

Event Ordering:

• The delegator's authorizing event must be created and witnessed before the delegate's inception event
• Validators must verify this temporal ordering through sequence numbers in the KEL
• Out-of-order events must be escrowed until dependencies are resolved
• First-seen policy applies to detect duplicity

Witness Confirmation Windows:

• Delegator events should achieve witness consensus before delegate inception
• The KAACE algorithm ensures witnesses agree on event ordering
• TOAD (Threshold of Accountable Duplicity) determines minimum witness confirmations
• Typical confirmation windows range from seconds to minutes depending on network conditions

Recovery Timing:

• Superseding rotations should be issued promptly upon compromise detection
• The recovery window depends on the depth of the delegation tree
• Deeper trees require more time for recovery events to propagate
• Watchers provide ambient monitoring to detect compromise quickly

Error Handling

Missing Delegation Seals:

• If a delegate's inception event lacks a seal to the delegator, validation fails
• If a delegator's event lacks a seal to the delegate, the delegation is incomplete
• Validators must reject events with malformed or missing seals
• Error: "Delegation seal missing or invalid"

Seal Mismatch:

• If the delegator's seal commits to a different event than the delegate references, validation fails
• The SAID in the delegator's seal must match the SAID of the delegate's inception event
• The delegate's seal must reference the correct delegator event by SAID
• Error: "Delegation seal mismatch - bidirectional commitment failed"

Broken Delegation Chains:

• If any link in a nested delegation chain is invalid, the entire chain fails validation
• Validators must verify each level recursively up to the root
• Missing or corrupted KEL entries break the chain
• Error: "Delegation chain broken at level N"

Unauthorized Superseding:

• Only the immediate parent delegator can issue superseding rotations
• Attempts by non-parent identifiers to supersede must be rejected
• Superseding events must properly reference the delegation relationship
• Error: "Unauthorized superseding rotation - not immediate parent"

Witness Threshold Failures:

• If insufficient witnesses confirm delegation events, the delegation is not stable
• The TOAD threshold must be met for both delegator and delegate events
• Validators should wait for threshold confirmation before accepting delegations
• Error: "Insufficient witness confirmations for delegation"

Usage Patterns

Enterprise Hierarchical Key Management

Scenario: A large corporation needs to manage identifiers for divisions, departments, and individual employees while maintaining centralized security control.

Implementation:

1. Root AID: Corporate root identifier with highest security (HSM-protected keys)
2. Division AIDs: Each division receives a delegated identifier from the root
3. Department AIDs: Departments receive delegated identifiers from their division
4. Employee AIDs: Individual employees receive delegated identifiers from their department

Benefits:

• Centralized recovery: If an employee's keys are compromised, the department can issue a superseding rotation
• Cascading security: Root-level security protects all descendant identifiers
• Flexible revocation: Delegation can be revoked by rotating the parent without the delegate's cooperation
• Audit trail: Complete delegation chain provides verifiable organizational structure

Multi-Tenant Service Provider

Scenario: A KERIA cloud agent service provider hosts identifiers for multiple customers.

Implementation:

1. Provider root AID: Service provider's root identifier
2. Customer AIDs: Each customer receives a delegated identifier from the provider
3. Customer sub-identifiers: Customers can further delegate to their own sub-identifiers

Benefits:

• Service provider recovery: Provider can recover customer identifiers if customers lose keys
• Customer autonomy: Customers control their own sub-delegations
• Liability separation: Clear delegation chain establishes responsibility boundaries
• Scalability: Horizontal scaling through multiple customer delegations

IoT Device Management

Scenario: Managing identifiers for IoT devices with limited security capabilities.

Implementation:

1. Gateway AID: Secure gateway with robust key management
2. Device AIDs: Each IoT device receives a delegated identifier from the gateway
3. Sensor AIDs: Individual sensors may receive further delegated identifiers

Benefits:

• Device compromise recovery: Gateway can rotate compromised device keys
• Reduced device complexity: Devices don't need full KERI implementation
• Centralized monitoring: Gateway tracks all device key states
• Lifecycle management: Easy device decommissioning through delegation revocation

Best Practices

Security Tier Separation:

• Use higher security for root delegators (HSMs, air-gapped systems)
• Allow lower security for leaf delegates (software keys, mobile devices)
• The recursive recovery mechanism protects lower tiers through higher tier security
• Document security requirements for each delegation level

Witness Configuration:

• Root delegators should use more witnesses with higher TOAD thresholds
• Lower-level delegates can use fewer witnesses for performance
• Consider using different witness pools for different delegation levels
• Ensure witness availability matches the criticality of the identifier

Key Rotation Policies:

• Establish regular rotation schedules for each delegation level
• Root identifiers should rotate less frequently but with higher ceremony
• Leaf identifiers can rotate more frequently with automated processes
• Pre-rotate keys to enable quantum-resistant security

Delegation Depth Limits:

• Limit delegation tree depth to manageable levels (typically 3-5 levels)
• Deeper trees increase validation complexity and recovery time
• Consider flattening hierarchies where possible
• Document maximum delegation depth in governance policies

Monitoring and Auditing:

• Deploy watchers to monitor all delegation levels
• Implement automated alerts for unexpected delegation events
• Maintain audit logs of all delegation operations
• Regularly verify delegation chain integrity

Integration Considerations

With ACDC Credentials:

• ACDCs can use delegated identifiers as issuers
• The I2I (Issuer-to-Issuee) edge operator requires the issuer to be the issuee of a parent credential
• The DI2I (Delegated-Issuer-to-Issuee) operator extends this to include delegated identifiers
• This enables credential chains that follow organizational delegation structures

With IPEX Protocol:

• IPEX exchanges can leverage delegation chains for authorization
• Delegated identifiers can present credentials on behalf of their delegators
• The delegation chain provides verifiable proof of authorization
• Graduated disclosure can reveal delegation relationships progressively

With vLEI Ecosystem:

• GLEIF uses nested cooperative delegation for QVI authorization
• GLEIF's root AID delegates to GEDA (GLEIF External Delegated AID)
• GEDA delegates to individual QVIs
• QVIs issue vLEI credentials to legal entities
• This creates a verifiable chain of trust from GLEIF to end entities

With DID Methods:

• Delegated KERI identifiers can be expressed as did:keri or did:webs
• The delegation relationship is encoded in the DID document metadata
• DID resolution must verify the complete delegation chain
• Interoperability with other DID methods requires delegation chain translation

Conclusion

Nested cooperative delegated identifiers represent a powerful mechanism for building scalable, secure, and recoverable hierarchical identity systems. By requiring bilateral cryptographic commitments and enabling recursive superseding recovery, KERI's delegation model provides unique security properties not found in traditional PKI systems. The cooperative nature ensures mutual consent while the nested structure enables organizational hierarchies to be directly represented in the cryptographic infrastructure. This makes nested cooperative delegation particularly well-suited for enterprise identity management, multi-tenant services, IoT deployments, and any scenario requiring verifiable delegation chains with built-in compromise recovery capabilities.