Comprehensive Explanation

inception

Process Definition

Inception is the bootstrap operation that establishes a new Autonomic Identifier (AID) within the KERI protocol. This operation creates a cryptographic binding between:

• A unique identifier prefix (derived from or containing public key material)
• An initial set of authoritative keypairs (current signing keys and pre-rotated next keys)
• Configuration parameters (witness configuration, thresholds, traits)
• Supporting infrastructure specifications

The inception operation produces an inception event - a serialized data structure that becomes the immutable first entry in the identifier's Key Event Log (KEL). This event is self-certifying and self-contained, meaning it carries all information necessary to verify the identifier's derivation and initial configuration without requiring external trust anchors.

Key Accomplishments:

• Establishes cryptographic root-of-trust for the identifier
• Defines initial control authority through key specifications
• Commits to future key rotation through pre-rotation digests
• Configures witness infrastructure for duplicity detection
• Creates verifiable audit trail foundation

When Used:

• Creating new identifiers for controllers, organizations, or entities
• Establishing delegated identifiers under existing authority
• Initializing multi-signature group identifiers
• Bootstrapping witness or watcher infrastructure identifiers

Key Participants:

• Controller: Entity generating keys and creating the inception event
• Witnesses: Designated entities that receipt and store the inception event
• Validators: Any party that will later verify the identifier's authenticity

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