Process Flow

Step 1: Entropy Generation and Key Derivation

The inception process begins with cryptographically secure entropy generation:

1. Generate a random seed (bran) with minimum 128 bits of cryptographic strength
2. Derive the initial signing keypair from this seed using a deterministic algorithm
3. Generate the next (pre-rotated) keypair for future rotation
4. Create cryptographic digests of the next public keys

The derivation code specifies the cryptographic algorithm used (e.g., Ed25519, ECDSA secp256k1), which is prepended to the public key material to create a qualified cryptographic primitive in CESR format.

Step 2: Identifier Prefix Generation

The identifier prefix is generated through one of several methods:

Basic Self-Certifying Identifier:

• Prefix = derivation_code + base64(public_key)
• Example: BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0

Self-Addressing Identifier:

• Prefix = derivation_code + base64(digest(inception_event))
• Requires two-pass generation: create event with placeholder, compute digest, replace placeholder
• Example: EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M

Multi-Signature Self-Addressing:

• Combines multiple public keys with threshold specifications
• Prefix derived from digest of the complete multi-sig configuration

Step 3: Inception Event Construction

The inception event is constructed as a field map (ordered key-value structure) containing:

Required Fields:

• v: Version string (e.g., KERI10JSON000160_)
• t: Event type (icp for inception)
• d: Event digest (SAID - Self-Addressing Identifier)
• i: Identifier prefix
• s: Sequence number (always 0 for inception)
• kt: Current signing threshold
• k: Array of current public keys
• nt: Next signing threshold
• n: Array of next key digests (pre-rotation commitments)
• bt: Witness threshold (backer threshold)
• b: Array of witness identifiers
• c: Configuration traits array
• a: Anchoring seals array (typically empty for inception)

Example Inception Event Structure:

{
  "v": "KERI10JSON000160_",
  "t": "icp",
  "d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "0",
  "kt": "1",
  "k": ["DKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0"],
  "nt": "1",
  "n": ["EJ4Ngh0jDrlkD774TdNbkhzVYnf-MwpHGAnqKmsCAB8A"],
  "bt": "2",
  "b": [
    "BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha",
    "BLskRTInXnMxWaGqcpSyMgo0nYbalW99cGZESrz3zapM"
  ],
  "c": [],
  "a": []
}

Step 4: Event Signing

The controller signs the serialized inception event:

1. Serialize the event to canonical form (preserving field order)
2. Generate signature using the current private key
3. Attach signature as CESR-encoded indexed signature
4. For multi-sig, collect threshold-satisfying signatures from all participants

Signature Attachment Format:

-AABAAxxx...  (CESR-encoded signature)

The signature creates a non-repudiable cryptographic commitment to both the identifier and its initial configuration.

Step 5: Witness Propagation

The signed inception event is transmitted to designated witnesses:

1. Controller sends inception event to each witness via OOBI endpoints
2. Witnesses verify:
   • Event structure and field validity
   • Signature authenticity against public key in event
   • Identifier derivation correctness
3. Witnesses create receipt messages (key event receipts)
4. Witnesses return receipts to controller
5. Controller collects receipts meeting the witness threshold

Receipt Message Structure:

{
  "v": "KERI10JSON00011c_",
  "t": "rct",
  "d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "0"
}

Witness signatures are attached to receipts, creating the Key Event Receipt Log (KERL).

Step 6: KEL Initialization

The inception event becomes the genesis entry in the KEL:

1. Store inception event in local database
2. Initialize key state with current keys and thresholds
3. Record pre-rotation commitments for future verification
4. Store witness receipts as validation evidence
5. Make KEL available for future event appending

The KEL is now established and ready for subsequent rotation events and interaction events.

Technical Requirements

Cryptographic Requirements

Entropy Strength:

• Minimum 128 bits of cryptographic strength for seed generation
• Use cryptographically secure pseudo-random number generator (CSPRNG)
• Recommended: 256 bits for post-quantum security considerations

Key Generation:

• Support for multiple signature schemes (Ed25519, ECDSA secp256k1, etc.)
• Deterministic key derivation from seed
• Secure storage of private keys (never transmitted)
• Generation of both current and next keypairs

Digest Algorithms:

• Blake3-256 for next key commitments (default)
• SHA-256 support for compatibility
• Collision-resistant hash functions only

Signature Schemes:

• Non-repudiable digital signatures
• Support for threshold multi-signature schemes
• Indexed signatures for multi-sig scenarios

Timing Considerations

Witness Timeout:

• Default timeout for witness receipt collection: 30 seconds
• Configurable based on network conditions
• Partial receipts acceptable if threshold met

Event Ordering:

• Inception must be sequence number 0
• No events can precede inception in the KEL
• Timestamp in inception event establishes temporal reference

Pre-rotation Commitment:

• Next keys must be generated before inception event creation
• Digests computed and included in inception event
• Next keys kept secure until rotation event

Error Handling

Insufficient Witness Receipts:

• If witness threshold not met, inception is not considered established
• Controller may retry witness propagation
• Alternative: adjust witness configuration and re-incept with new identifier

Signature Verification Failure:

• Invalid signatures cause event rejection
• Multi-sig requires all threshold signatures to be valid
• Malformed events are discarded without processing

Identifier Collision:

• Cryptographic strength makes collisions computationally infeasible
• Self-addressing identifiers have collision resistance of hash function
• Basic identifiers have collision resistance of key generation

Configuration Errors:

• Invalid threshold specifications (e.g., threshold > key count)
• Malformed witness identifiers
• Unsupported configuration traits
• All cause inception event rejection

Usage Patterns

Single-Signature Identifier Inception

Scenario: Individual creating personal identifier

Pattern:

1. Generate single keypair with pre-rotation
2. Configure 3-5 witnesses with threshold of 2-3
3. Create basic or self-addressing identifier
4. Sign and propagate to witnesses
5. Collect receipts and establish KEL

Best Practices:

• Use self-addressing identifiers for enhanced security
• Select geographically distributed witnesses
• Store seed securely (encrypted, backed up)
• Document witness OOBIs for recovery

Multi-Signature Group Identifier Inception

Scenario: Organization creating shared governance identifier

Pattern:

1. All participants generate individual keypairs
2. Agree on threshold (e.g., 3-of-5 for signing, 4-of-5 for rotation)
3. One participant constructs inception event with all public keys
4. All participants sign the inception event
5. Lead participant collects signatures and propagates to witnesses
6. All participants store the established KEL

Best Practices:

• Use weighted thresholds for complex governance
• Separate signing and rotation thresholds
• Establish clear signing coordination protocol
• Use secure channels for signature collection

Delegated Identifier Inception

Scenario: Creating identifier under existing authority

Pattern:

1. Delegate generates keypairs and constructs inception event
2. Inception event includes di field with delegator's identifier
3. Delegate signs inception event
4. Delegator creates interaction or rotation event with seal of delegate's inception
5. Delegator signs and propagates their event
6. Delegate propagates inception event with reference to delegator's seal
7. Witnesses verify delegation chain

Best Practices:

• Ensure delegator's KEL is established first
• Use interaction events for delegation seals when possible
• Verify delegation authorization before accepting delegate events
• Maintain delegation tree documentation

Witness Identifier Inception

Scenario: Establishing witness infrastructure

Pattern:

1. Witness generates keypairs (typically non-transferable)
2. Creates inception event with no witnesses (self-witnessing)
3. Publishes OOBI for discovery
4. Makes KEL publicly accessible

Best Practices:

• Use non-transferable identifiers for witnesses (simpler)
• Publish witness OOBIs via well-known URIs
• Maintain high availability infrastructure
• Implement receipt storage and retrieval APIs

Integration Considerations

With ACDC Credentials:

• Issuer AID must be established before credential issuance
• Inception event establishes issuer's root-of-trust
• Credential registry requires separate inception

With DID Methods:

• KERI inception maps to DID creation
• DID document generated from inception event and key state
• did:keri and did:webs methods use inception as foundation

With Key Management Systems:

• HSM integration for key generation and signing
• Secure enclave support for mobile implementations
• Key derivation from hardware-backed seeds

With Witness Networks:

• Discovery via OOBI resolution
• Load balancing across witness pools
• Failover and redundancy strategies

• Validate threshold <= key count
• Support weighted thresholds for complex governance
• Separate signing threshold (kt) from rotation threshold (nt)
• Document threshold rationale for governance

Error Recovery

Failed Inception:

• If witness threshold not met, inception is not established
• Cannot retry with same identifier (would create duplicity)
• Must generate new identifier and re-incept
• Log failed attempts for debugging

Witness Unavailability:

• Implement retry logic with exponential backoff
• Consider partial establishment if some witnesses respond
• Document witness SLA requirements
• Plan for witness replacement procedures

Performance Optimization

Parallel Witness Propagation:

• Send inception event to all witnesses concurrently
• Use connection pooling for efficiency
• Implement timeout per witness, not total timeout
• Collect receipts asynchronously

Database Optimization:

• Index KEL by identifier prefix for fast lookup
• Cache key state for frequent access
• Use write-ahead logging for durability
• Implement efficient serialization (CBOR for binary, JSON for debugging)

Security Considerations

Entropy Quality:

• Use OS-provided CSPRNG (e.g., /dev/urandom, CryptGenRandom)
• Verify entropy pool initialization
• Consider additional entropy sources for critical identifiers
• Test random number generator quality

Timing Attacks:

• Use constant-time comparison for signature verification
• Avoid timing-dependent branching in cryptographic operations
• Implement rate limiting for inception attempts
• Log suspicious timing patterns

Replay Protection:

• Inception events are inherently replay-resistant (sequence 0)
• Verify event hasn't been processed before
• Check timestamp reasonableness
• Implement event deduplication

Testing Strategies

Unit Tests:

• Test key generation with known seeds
• Verify identifier derivation correctness
• Test threshold validation logic
• Validate CESR encoding/decoding

Integration Tests:

• Test witness communication and receipt collection
• Verify multi-sig coordination
• Test delegation workflows
• Validate KEL initialization

Security Tests:

• Test with compromised witnesses
• Verify duplicity detection
• Test threshold boundary conditions
• Validate cryptographic primitives