Delegated Inception Event (dip): The initial establishment event that creates the delegated identifier contains:

• Standard inception fields (v, t, d, i, s, kt, k, nt, n, bt, b, c, a)
• di field: Contains the delegator's AID prefix, establishing the delegation relationship
• Cryptographic seal referencing the delegating event in the delegator's KEL

Delegator Anchoring Event: The delegator's KEL contains an event (rotation or interaction) with:

• Delegated event seal: A seal structure containing the delegate's AID prefix (i), sequence number (s), and digest (d) of the delegated inception event
• Signatures from the delegator's current authoritative keys
• Proper sequence number and chaining to previous events

Self-Addressing Binding: The delegate's AID prefix is a SAID (Self-Addressing Identifier) derived from its delegated inception event. This SAID includes the di field containing the delegator's AID, creating an immutable cryptographic link between the two identities that cannot be altered without changing the delegate's identifier itself.

Hierarchical Trust Model

Delegated identifiers enable recursive delegation, where delegates can themselves become delegators for their own delegates, forming arbitrarily complex trees of hierarchical key management event streams. This recursive capability provides:

• Organizational Hierarchies: Mapping corporate structures to delegation trees (e.g., corporation → division → department → team)
• Separation of Concerns: Different operational domains managed by different delegates
• Graduated Security Policies: Leaf nodes may use less secure key management while benefiting from root security guarantees
• Scalable Authority Distribution: Fractionalizing signing authority across hierarchical structures without compromising root security

Data Format

Delegated Inception Event Structure

The delegated inception event follows the standard KERI event format with critical additions:

{
  "v": "KERI10JSON00012b_",
  "t": "dip",
  "d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
  "i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
  "s": "0",
  "kt": "1",
  "k": ["DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc"],
  "nt": "1",
  "n": ["EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL"],
  "bt": "2",
  "b": ["BJq7UABlttINuWJh1Xl2lkqZG4NTdUdqnbFJDa6ZyxCC", "BDg1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfP"],
  "c": [],
  "a": [],
  "di": "EABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqr"
}

Field Definitions:

• di (Delegator Identifier): The AID prefix of the delegating identifier, establishing the delegation relationship
• t (Type): Set to "dip" (delegated inception) to distinguish from standard inception ("icp")
• i (Identifier): The delegate's self-addressing identifier, derived from the entire event including the di field
• d (Digest): SAID of the event, matching i for self-addressing identifiers

Delegating Event Seal Structure

The delegator's KEL contains an anchoring event with a seal referencing the delegated inception:

{
  "v": "KERI10JSON000160_",
  "t": "ixn",
  "d": "EXAMPLEdigestOfThisInteractionEvent123456789ABC",
  "i": "EABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqr",
  "s": "3",
  "p": "EPreviousEventDigest123456789ABCDEFGHIJKLMNOPQRst",
  "a": [
    {
      "i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
      "s": "0",
      "d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose"
    }
  ]
}

Seal Components:

• i: Delegate's AID prefix
• s: Sequence number of the delegated event ("0" for inception)
• d: Digest of the delegated event

Encoding and Serialization

Delegated identifiers use CESR (Composable Event Streaming Representation) encoding:

• Version String: Specifies KERI version, serialization type (JSON, CBOR, MGPK), and size
• Qualified Primitives: All cryptographic material uses CESR derivation codes
• Attachment Format: Signatures and receipts attached using CESR group codes
• Stream Composability: Events can be concatenated and parsed without delimiters

Size and Constraints

Cryptographic Strength: Minimum 128 bits of entropy for key generation, as mandated by vLEI governance frameworks

Identifier Length: Variable based on derivation code and cryptographic algorithm:

• Ed25519 public keys: 44 characters in Base64 URL-safe encoding
• Blake3-256 digests: 44 characters
• Secp256k1 public keys: 48 characters

Event Size: Delegated inception events are typically 300-500 bytes in JSON serialization, varying based on:

• Number of current keys (k array)
• Number of next key digests (n array)
• Witness configuration (b array)
• Configuration traits (c array)

Operations

Creation and Initialization

Step 1: Delegator Preparation

The delegator must first establish its own identifier and reach a stable key state. The delegator then prepares to authorize delegation by:

1. Generating Delegation Seal: Creating the seal structure with the delegate's anticipated AID prefix (which will be derived from the delegated inception event)
2. Creating Anchoring Event: Issuing either a rotation or interaction event containing the delegation seal
3. Signing and Witnessing: Obtaining signatures from current authoritative keys and receipts from configured witnesses

Step 2: Delegate Inception

The delegate creates its delegated inception event:

1. Key Generation: Generating current and pre-rotated key pairs using CSPRNG with sufficient entropy
2. Event Construction: Building the delegated inception event with:
   • di field set to delegator's AID
   • Current keys in k array
   • Next key digests in n array
   • Witness configuration in b array
3. SAID Derivation: Computing the self-addressing identifier from the complete event
4. Signing: Attaching signatures from current keys

Step 3: Cooperative Completion

The delegation becomes effective when:

1. Delegator Event Finalization: The delegator's anchoring event is witnessed and receipted
2. Delegate Event Witnessing: The delegate's inception event is witnessed by its configured witness pool
3. Cross-Verification: Both events are available for third-party verification of the delegation relationship

Updates and Modifications

Delegated Rotation (drt)

Delegated identifiers support key rotation through delegated rotation events (drt), which require cooperative participation:

Delegate Rotation Event:

{
  "v": "KERI10JSON000160_",
  "t": "drt",
  "d": "ERotationEventDigest123456789ABCDEFGHIJKLMNOPQRst",
  "i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
  "s": "1",
  "p": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
  "kt": "1",
  "k": ["DNewCurrentKey123456789ABCDEFGHIJKLMNOPQRstuvwx"],
  "nt": "1",
  "n": ["ENewNextKeyDigest123456789ABCDEFGHIJKLMNOPQRstuv"],
  "bt": "2",
  "br": [],
  "ba": [],
  "a": []
}

Delegator Approval: The delegator must issue an anchoring event (rotation or interaction) containing a seal referencing the delegated rotation event, following the same cooperative pattern as inception.

Superseding Recovery

A critical feature of delegated identifiers is superseding recovery, where the delegator can recover from delegate key compromise:

1. Compromise Detection: If delegate keys are compromised, the delegator detects duplicitous events in the delegate's KEL
2. Superseding Rotation: The delegator issues a rotation event that supersedes the compromised delegate rotation
3. Authority Restoration: The delegate's authority is restored to a pre-compromise state
4. Recursive Application: This recovery mechanism can be applied recursively across multiple delegation levels

Revocation

Delegation can be revoked through:

Explicit Revocation: The delegator issues an interaction event with a seal indicating revocation of the delegation

Implicit Revocation: The delegator rotates keys without re-authorizing the delegation in the new key state

Verification and Validation

Delegation Verification Algorithm

Validators verify delegated identifiers through a multi-step process:

Step 1: Delegate KEL Verification

1. Retrieve the delegate's complete KEL
2. Verify cryptographic chaining (backward and forward)
3. Verify signatures on all events
4. Verify witness receipts meet threshold requirements
5. Extract di field from inception event

Step 2: Delegator KEL Verification

1. Retrieve the delegator's complete KEL
2. Verify cryptographic chaining and signatures
3. Locate the anchoring event containing the delegation seal
4. Verify the seal references the delegate's inception event correctly:
   • Seal's i field matches delegate's AID
   • Seal's s field matches delegate's inception sequence ("0")
   • Seal's d field matches delegate's inception digest

Step 3: Temporal Ordering

1. Verify the delegator's anchoring event precedes or is concurrent with the delegate's inception
2. Ensure no temporal inconsistencies in the delegation relationship

Step 4: Authority Chain Validation

1. For nested delegations, recursively verify each level up to the root
2. Ensure no breaks in the delegation chain
3. Verify all intermediate delegators maintain valid key states

Duplicity Detection

Delegated identifiers benefit from KERI's duplicity detection mechanisms:

Internal Consistency: Each KEL (delegator and delegate) must be internally consistent with proper cryptographic chaining

External Consistency: Multiple copies of the same KEL must be identical, or duplicity is evident

Delegation Consistency: The delegation relationship must be consistent across all copies of both delegator and delegate KELs

Witness Agreement: Witnesses must agree on the delegation events through KAACE (KERI's Agreement Algorithm for Control Establishment)

Usage Context

Protocol Integration

Delegated identifiers are used extensively across KERI-based protocols:

ACDC Credential Issuance

ACDCs (Authentic Chained Data Containers) leverage delegated identifiers for credential issuance hierarchies:

vLEI Ecosystem Example:

1. GLEIF Root AID: The apex identifier with maximum security
2. GLEIF External Delegated AID (GEDA): Delegated from root, manages QVI relationships
3. QVI Delegated AIDs: Qualified vLEI Issuers delegated from GEDA
4. Legal Entity AIDs: May be delegated from QVIs or self-managed
5. Role Credential AIDs: Delegated from Legal Entity AIDs for organizational roles

This delegation tree enables:

• Graduated Security: Root maintains highest security, operational identifiers use practical key management
• Scalable Issuance: QVIs can issue credentials without exposing GLEIF root keys
• Compromise Recovery: GLEIF can recover from QVI compromise through superseding rotation

KERIA Agent Architecture

KERIA (KERI Agent) uses delegated identifiers for client-agent relationships:

Client AID → Agent AID Delegation:

1. Client AID: Controlled by user via passcode-derived keys
2. Agent AID: Delegated from Client AID, managed by KERIA service
3. Signing Authority: Agent AID has signing authority for operations
4. Rotation Authority: Client AID retains rotation authority

This enables:

• Cloud Operations: Agent can perform operations without exposing client keys
• User Control: Client can revoke agent authority by rotating keys
• Security Balance: Operational convenience with ultimate user control

Lifecycle Management

Inception Phase

Planning: Determining delegation hierarchy, security requirements, and key management strategies

Coordination: Establishing communication channels between delegator and delegate for cooperative operations

Execution: Performing the multi-step inception process with proper sequencing

Verification: Confirming successful delegation through third-party validation

Operational Phase

Key Rotation: Coordinating delegated rotations between delegator and delegate

Monitoring: Watching for duplicitous events or compromise indicators

Maintenance: Updating witness configurations, managing key lifecycles

Termination Phase

Revocation: Explicitly revoking delegation through delegator action

Abandonment: Rotating to empty next key digest list to make identifier non-transferable

Archival: Preserving KELs for historical verification and audit trails

Related Structures

Transferable Identifiers

Delegated identifiers are a specialized form of transferable identifiers that add delegation semantics. All delegated identifiers are transferable (support key rotation), but not all transferable identifiers are delegated.

Multi-Signature Identifiers

Delegated identifiers can be combined with multi-signature control:

Delegated Multi-Sig: A delegated identifier controlled by multiple key pairs with threshold requirements

Multi-Sig Delegator: A multi-signature identifier serving as delegator for other identifiers

Group Delegation: Multiple identifiers cooperatively delegating to a single delegate

Witness Pools

Delegated identifiers use witness pools for event confirmation:

Independent Witnesses: Delegate may use different witnesses than delegator

Shared Witnesses: Delegator and delegate may share witness infrastructure

Witness Rotation: Both delegator and delegate can rotate witness configurations independently

Transaction Event Logs

TELs (Transaction Event Logs) for credential registries are anchored to delegated identifiers:

Registry Inception: TEL inception event references the controlling delegated AID

Credential Issuance: Credentials issued by delegated identifiers are tracked in TELs

Revocation Management: TEL events are anchored to the delegated identifier's KEL

Enterprise Use Cases

Organizational Hierarchies

Corporate Structure Mapping:

• Root: Corporate entity with maximum security key management
• Divisions: Delegated identifiers for major business units
• Departments: Further delegated from divisions
• Teams/Projects: Leaf-level delegated identifiers for operational use

Benefits:

• Security flows down from root
• Operational flexibility at leaves
• Centralized compromise recovery
• Audit trails through delegation chains

Custodial Arrangements

Service Provider Delegation:

• Customer AID: Retains rotation authority
• Provider AID: Delegated with signing authority
• Service Operations: Provider performs day-to-day operations
• Customer Control: Customer can revoke provider access unilaterally

Supply Chain Management

Multi-Tier Supply Chains:

• Manufacturer Root: Top-level identifier
• Tier 1 Suppliers: Delegated from manufacturer
• Tier 2 Suppliers: Delegated from Tier 1
• Component Tracking: Each tier issues credentials for components

Traceability: Complete provenance chain through delegation hierarchy

Security Considerations

Bivalent Key Management

Delegated identifiers enable bivalent key management infrastructure:

Concept: Nested delegations wrap each layer with compromise recovery protection from the next higher layer

Implementation:

1. Root uses maximum security (HSM, multi-sig, air-gapped)
2. Intermediate delegates use strong security (cloud HSM, multi-party)
3. Leaf delegates use practical security (mobile wallets, single-sig)

Security Property: Root security protects all descendants through superseding recovery, even if leaves use weaker key management

Attack Resistance

Live Attack Protection: Compromise of delegate signing keys cannot capture control authority because delegator retains rotation authority

Dead Attack Protection: Historical compromise attempts are evident through duplicity detection in KELs

Quantum Resistance: Pre-rotation mechanism provides post-quantum security through one-way hash functions

Trust Boundaries

Delegation as Trust Boundary: Each delegation represents a trust decision by the delegator

Verification Requirements: Validators must verify the entire delegation chain to root

Revocation Propagation: Revoking a delegator's authority cascades to all descendants

Performance and Scalability

Horizontal Scalability

Multi-Valent Delegation: A single delegator can have multiple delegates, enabling elastic horizontal scaling

Parallel Operations: Delegates can operate independently without coordinating with siblings

Load Distribution: Signing operations distributed across delegation tree

Vertical Scalability

Arbitrary Depth: Delegation trees can be nested to any depth required

Recursive Verification: Verification complexity grows linearly with delegation depth

Caching Strategies: Intermediate verification results can be cached to improve performance

Governance and Policy

vLEI Governance Framework

The vLEI Ecosystem Governance Framework mandates specific delegation patterns:

GLEIF Root Requirements:

• Minimum 3 notaries as witnesses
• Highest duty of care for key management
• Public documentation of root AID

QVI Delegation Requirements:

• Multi-signature control (minimum 2 QARs)
• Specific witness pool configurations
• Annual qualification procedures

Legal Entity Delegation:

• Optional delegation from QVIs
• Self-managed or custodial arrangements
• Role-based delegation for representatives

Policy Enforcement

Delegation Policies: Encoded in ACDC rules sections

Automated Verification: Validators check delegation chains against policy requirements

Audit Trails: Complete delegation history preserved in KELs for compliance

Conclusion

Delegated identifiers represent a powerful primitive in KERI's composable architecture, enabling hierarchical trust structures with built-in compromise recovery. Through cooperative delegation, superseding recovery, and recursive application, delegated identifiers provide the foundation for scalable, secure, and flexible identity systems that balance operational efficiency with cryptographic security. The mechanism is fundamental to enterprise deployments, credential ecosystems like vLEI, and any scenario requiring distributed authority with centralized oversight.

• Delegate signing authority to custodian
• Retain rotation authority with original controller
• Use partial rotation to enable this split

Verification Implementation

Complete Chain Verification: Validators MUST verify the entire delegation chain to root:

def verify_delegation_chain(delegate_aid, validator):
    current = delegate_aid
    while True:
        # Get delegate's KEL
        kel = validator.get_kel(current)
        inception = kel.get_inception()
        
        # Check if delegated
        if 'di' not in inception:
            # Reached root (non-delegated identifier)
            return True
            
        delegator = inception['di']
        
        # Verify delegator's anchoring event
        delegator_kel = validator.get_kel(delegator)
        if not delegator_kel.has_delegation_seal(current, inception['s'], inception['d']):
            return False
            
        # Move up the chain
        current = delegator

Caching Strategy: Cache intermediate verification results:

• Cache delegator KEL verification results
• Cache delegation seal lookups
• Invalidate cache on delegator rotation events

Error Handling

Delegation Failures: Common failure modes:

1. Missing Delegator Event: Delegate inception exists but delegator has no anchoring event

   • Recovery: Wait for delegator to issue anchoring event
   • Timeout: Reject delegation after reasonable timeout (e.g., 24 hours)

2. Seal Mismatch: Delegator's seal doesn't match delegate's inception

   • Recovery: Delegate must create new inception with correct parameters
   • Prevention: Verify seal before finalizing inception

3. Temporal Inconsistency: Delegate inception precedes delegator authorization

   • Recovery: Not recoverable, must restart delegation process
   • Prevention: Ensure proper sequencing in implementation

Performance Optimization

Parallel Verification: When verifying multiple delegated identifiers:

• Verify delegator KELs in parallel
• Cache common delegator verifications
• Use witness pool queries efficiently

Lazy Delegation Verification: For performance-critical paths:

• Verify delegate's KEL immediately
• Defer delegator chain verification to background process
• Mark as "pending delegation verification" until complete

Multi-Signature Delegated Identifiers

When combining delegation with multi-sig:

Inception Coordination: All multi-sig participants must:

1. Agree on delegator AID
2. Coordinate on inception event parameters
3. Each sign the inception event
4. Collect threshold-satisfying signatures

Rotation Coordination: Delegated rotations require:

1. Multi-sig participants coordinate on new keys
2. Delegator approves rotation
3. All participants sign rotation event

vLEI-Specific Implementation

QVI Delegation Requirements:

• QVI AID MUST be delegated from GEDA
• Multi-sig with minimum 2 QARs
• Specific witness pool configuration
• Annual re-qualification procedures

Legal Entity Delegation:

• Optional delegation from QVI
• If delegated, QVI can revoke through rotation
• If self-managed, no delegation constraints

Testing Strategies

Unit Tests:

• Test delegation seal creation and verification
• Test SAID derivation with di field
• Test cooperative delegation sequencing

Integration Tests:

• Test complete delegation workflow
• Test multi-level delegation chains
• Test superseding recovery scenarios

Security Tests:

• Test unauthorized delegation attempts
• Test seal tampering detection
• Test temporal ordering violations

Monitoring and Operations

Delegation Health Monitoring:

• Monitor delegator KEL availability
• Alert on delegation seal mismatches
• Track delegation chain verification latency

Operational Procedures:

• Document delegation approval workflows
• Establish key rotation coordination procedures
• Define incident response for delegation compromise