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.

Performance Optimization

Caching delegation chains:

• Cache verified delegation chains to avoid repeated verification
• Invalidate cache when any event in the chain is superseded
• Use SAID-based cache keys for efficient lookup

Parallel verification:

• Verify different branches of delegation trees in parallel
• Use worker pools for KEL verification at each level
• Aggregate results to determine overall chain validity

Lazy loading:

• Don't load entire KELs for deep delegation chains
• Load only the events necessary for delegation verification
• Use SAID references to minimize data transfer

Security Hardening

Delegation depth limits:

• Enforce maximum delegation depth (recommend 5 levels) to prevent abuse
• Reject delegation chains exceeding the configured limit
• Document depth limits in system governance

Seal validation:

• Always verify both directions of the bilateral seal commitment
• Reject delegations with missing or mismatched seals
• Validate that seal SAIDs match the actual event digests

Witness threshold enforcement:

• Require TOAD threshold to be met before accepting delegation events as stable
• Implement timeout mechanisms for witness confirmation
• Alert on threshold failures that may indicate attacks

Integration with KERIA Agents

When implementing nested delegation in KERIA cloud agents:

1. Multi-tenant isolation: Ensure delegation relationships don't leak between tenants
2. Delegation APIs: Provide REST endpoints for creating and verifying delegations
3. Notification system: Alert controllers when delegation events occur
4. Backup and recovery: Ensure delegation relationships are preserved in backups
5. Audit logging: Log all delegation operations for compliance and debugging

Testing Strategies

Unit tests:

• Test seal construction and verification
• Test bilateral commitment validation
• Test superseding rotation logic
• Test escrow and out-of-order event handling

Integration tests:

• Test multi-level delegation chains (3-5 levels)
• Test recovery scenarios at each level
• Test witness confirmation across delegation levels
• Test performance with large delegation trees

Security tests:

• Test unauthorized superseding attempts
• Test seal tampering detection
• Test delegation depth limit enforcement
• Test witness threshold bypass attempts

Common Pitfalls

1. Forgetting reciprocal seals: Both delegator and delegate must include seals; missing either breaks the delegation
2. Incorrect SAID computation: Seals must reference the exact SAID of the target event; mismatches cause validation failures
3. Insufficient witness thresholds: Low TOAD values compromise security; use appropriate thresholds for each level
4. Ignoring event ordering: Out-of-order events must be escrowed; processing them immediately causes validation errors
5. Not implementing superseding: Recovery is a critical feature; implementations without superseding support are incomplete
6. Excessive delegation depth: Very deep trees (>5 levels) become difficult to manage and verify; limit depth appropriately