Comprehensive Explanation

AID (Autonomic Identifier)

Technical Definition

An Autonomic Identifier (AID) is a self-certifying identifier that maintains a cryptographic binding to its Key Event Log (KEL) according to the KERI specification. The term "autonomic" emphasizes the self-managing nature of these identifiers, distinguishing them from identifiers requiring external administrative authorities or algorithmic consensus mechanisms.

Formal Definition: An AID is a self-certifying identifier (SCID) combined with a Key Event Log that provides verifiable persistent control. The formula is:

Self-Certifying Identifier (SCID) + Key Event Log (KEL) = Autonomic Identifier (AID)

AIDs are classified into two fundamental categories:

1. Non-transferable AIDs: Do not support key rotation; controlling key pairs cannot be changed after inception
2. Transferable AIDs: Support key rotation through key pre-rotation mechanisms, enabling persistent control despite key compromise

Purpose in KERI/ACDC: AIDs serve as the foundational identity primitive in KERI, providing cryptographically verifiable control authority over identifiers without requiring trusted third parties. They enable:

• Decentralized identifier creation and management
• Verifiable key rotation and recovery
• Delegation hierarchies for scalable governance
• Credential issuance and verification in ACDC systems

Cryptographic Properties

Self-Certification Mechanism

AIDs achieve self-certification through cryptographic derivation from public keys using one-way functions. The identifier prefix is computed as:

1. Basic SCID: Direct derivation from public key
2. Self-Addressing SCID: Uses cryptographic digest of inception data
3. Multi-sig Self-Addressing: Supports multiple controlling key pairs

Derivation Process:

Seed → Private Key → One-Way Function → Public Key → Derivation Code + Digest → AID Prefix

Key Pre-Rotation Security

Transferable AIDs implement key pre-rotation, KERI's breakthrough solution to secure key rotation:

• Forward Commitment: Each rotation pre-commits to next keys via cryptographic digest
• One-Time Use: Rotation keys are used exactly once, minimizing exposure
• Post-Quantum Protection: Hidden pre-rotated keys provide resistance to quantum attacks
• Unbroken Chain: Maintains continuous cryptographic proof of control authority

The pre-rotation mechanism ensures that compromise of current signing keys cannot affect pre-rotated (unexposed) keys, enabling recovery without external trusted parties.

Cryptographic Strength

AIDs must provide approximately 128 bits of cryptographic strength as mandated by vLEI governance frameworks. Compliant algorithms include:

• Ed25519: Edwards-curve Digital Signature Algorithm
• ECDSA secp256k1: Elliptic Curve Digital Signature Algorithm

Data Format & Encoding

CESR Encoding Format

AIDs MUST be encoded in CESR (Composable Event Streaming Representation) as qualified cryptographic primitives. The encoding structure consists of:

1. Derivation Code: Prepended code indicating cryptographic algorithm and key type
2. Encoded Public Key: Base64 URL-safe encoding of the public key or its digest

Example AID Prefix:

EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

Where:

• E = Derivation code (indicates Blake3-256 digest of Ed25519 public key)
• Remaining characters = Base64-encoded digest

Text and Binary Representations

CESR provides dual-domain encoding:

Text Domain (T):

• Uses Base64 URL-safe character set: [A-Z, a-z, 0-9, -, _]
• Human-readable for debugging and logging
• Self-framing with prepended type codes

Binary Domain (B):

• Compact byte representation for efficient transmission
• Maintains same logical structure as text domain
• Enables bandwidth optimization

Conversion Property: CESR's composability ensures lossless round-trip conversion between text and binary domains for concatenated primitives.

Derivation Codes

Common AID derivation codes include:

• B: Ed25519 non-transferable prefix (basic SCID)
• E: Blake3-256 digest of inception event (self-addressing transferable)
• F: Blake2b-256 digest of inception event
• 1AAA: ECDSA secp256k1 non-transferable prefix

The derivation code enables cryptographic agility, allowing AIDs to specify which algorithm was used without requiring external metadata.

Usage in KERI/ACDC

In Key Event Logs (KELs)

AIDs are established and managed through KELs, which contain:

Inception Event (icp):

• Creates the AID and establishes initial key state
• Includes current signing keys and pre-rotated key digests
• Defines witness configuration and thresholds
• The AID prefix is the SAID of this inception event

Rotation Events (rot):

• Changes the authoritative key set
• Reveals previously pre-rotated keys
• Commits to new pre-rotated keys
• Maintains cryptographic chain of control

Interaction Events (ixn):

• Anchors external data without changing key state
• Used for credential issuance, revocation, and other operations

Common Usage Patterns

Single-Signature AIDs:

• Controlled by one-of-one signing keypair
• Simplest form for individual users
• Example: Personal identity wallets

Multi-Signature AIDs:

• Require threshold signatures from multiple keys
• Enables organizational governance
• Example: Corporate identifiers requiring 3-of-5 signatures

Delegated AIDs:

• Created under authority of delegator AID
• Enables hierarchical trust structures
• Example: GLEIF Root AID delegating to QVI AIDs

Group Multi-Sig AIDs:

• Each key controlled by different entity
• Requires cooperative coordination
• Example: GLEIF External AID controlled by multiple GARs

Verification Procedures

Verifying an AID involves:

1. Obtain KEL: Retrieve the complete Key Event Log for the AID
2. Verify Inception: Confirm AID prefix matches SAID of inception event
3. Validate Chain: Verify cryptographic chaining of all events
4. Check Signatures: Validate signatures using current authoritative keys
5. Verify Witnesses: Confirm witness receipts meet threshold requirements
6. Detect Duplicity: Check for conflicting versions of the KEL

Key State Determination: The current key state is determined by processing the KEL from inception through all establishment events, applying rotations in sequence to arrive at the current authoritative key set.

In ACDC Credentials

AIDs serve multiple roles in ACDC verifiable credentials:

Issuer AID (i field):

• Identifies the credential issuer
• Appears at top level of ACDC
• Provides cryptographic proof of issuance authority

Issuee AID (in a section):

• Identifies the credential subject
• Optional field (credentials may have no issuee)
• Enables holder binding

Controller AIDs:

• Control credential registries (TELs)
• Manage issuance and revocation state
• Anchor credential operations to KELs

Related Primitives

Self-Certifying Identifiers (SCIDs)

AIDs are a specialized form of SCID that adds:

• Key rotation capability through KELs
• Witness-based consensus
• Delegation support

Basic SCIDs are ephemeral (non-transferable), while AIDs enable persistent control.

Self-Addressing Identifiers (SAIDs)

SAIDs provide content-addressable identifiers for data structures. AIDs use SAID derivation for:

• Inception event identification (AID prefix = SAID of inception)
• Event chaining (each event references previous via SAID)
• Credential identification (ACDC d field)

Key Event Logs (KELs)

KELs are the verifiable data structure that makes AIDs "autonomic":

• Append-only log of key events
• Cryptographically chained (forward and backward)
• Provides proof of key state evolution
• Enables duplicity detection

Witnesses

Witnesses provide distributed consensus for AIDs:

• Designated by controller during inception
• Verify, sign, and store key events
• Enable indirect mode operation
• Support KAACE (KERI's Agreement Algorithm for Control Establishment)

Composition Patterns

AID + SAID + ACDC: Credentials use AIDs for issuer/issuee identification and SAIDs for content integrity, creating verifiable credential chains.

AID + Delegation + Multi-Sig: Hierarchical organizations use delegated multi-sig AIDs to distribute control while maintaining root authority.

AID + Witnesses + Watchers: Distributed infrastructure uses witnesses for consensus and watchers for ambient duplicity detection.

Implementation Considerations

AID Creation

Implementations must:

1. Generate cryptographically strong entropy (≥128 bits)
2. Derive key pairs using approved algorithms
3. Create inception event with proper structure
4. Compute AID prefix as SAID of inception event
5. Obtain witness receipts before considering AID established

Key Management

Critical security requirements:

• Protect pre-rotated keys at highest security level
• Separate signing and rotation authority for custodial scenarios
• Implement secure key generation using CSPRNG or true RNG
• Store private keys encrypted in secure keystores

Witness Configuration

vLEI governance mandates:

• Minimum 5 witnesses using KAACE sufficient majority threshold
• Witnesses must be discoverable via multiple mechanisms
• Access control independent of controller keys
• Publication via well-known URIs, OOBIs, DHT, and DID resolvers

Delegation Implementation

Delegated AIDs require:

• Cooperative establishment between delegator and delegate
• Delegator creates cryptographic commitment via seal
• Delegate creates establishment event with delegator reference
• Both parties must participate in rotations

Multi-Signature Coordination

Group multi-sig AIDs need:

• Asynchronous signature collection mechanisms
• Threshold satisfaction before event acceptance
• Coordination protocols for rotation events
• Mailbox services for message exchange

Security Properties

Duplicity Detection

AIDs enable detection of malicious behavior:

• Internal Inconsistency: Prevented by KEL verification from self-certifying root
• External Inconsistency: Detected when multiple verifiable but conflicting KELs exist
• First-Seen Policy: Witnesses record first observation, making duplicity evident

Post-Quantum Resistance

Pre-rotation provides quantum-safe properties:

• Digest commitments hide future keys from quantum attacks
• One-time key usage prevents compromise-based takeover
• Recovery possible even if current keys are broken

Zero-Trust Architecture

AIDs enable zero-trust computing:

• No reliance on intervening infrastructure security
• End-to-end verifiability from root-of-trust
• Ambient verifiability (anyone, anywhere, anytime)
• Cryptographic proof replaces institutional trust