Historical Context

Traditional identity systems have struggled with the availability-security trade-off. Centralized systems like DNS/CA achieve high availability through hierarchical infrastructure but create single points of failure and require trust in administrative authorities. Blockchain-based systems attempt decentralization but suffer from scalability limitations and require all participants to maintain consensus on a shared ledger.

The concept of witness-based verification has roots in distributed systems theory, particularly in Byzantine Fault Tolerant consensus algorithms. However, traditional BFT systems require all participants to agree on a total ordering of all events across all identifiers, creating significant overhead.

KERI's indirect mode represents an evolution of these concepts by:

• Localizing consensus: Each identifier has its own witness set, avoiding global consensus requirements
• Separating concerns: Witnesses provide availability and attestation, but validators make independent trust decisions
• Enabling ambient verifiability: Anyone can verify event logs without participating in consensus
• Maintaining cryptographic roots-of-trust: Witnesses attest but don't control; the controller's signatures remain authoritative

KERI's Approach

Witness Architecture

In KERI's indirect mode, the controller designates a set of witnesses when creating an identifier through the inception event. These witnesses are trusted components that:

1. Receive key events from the controller
2. Verify cryptographic integrity of events (signatures, hash chains, pre-rotation commitments)
3. Create signed receipts (key event receipts) attesting to event observation
4. Store and serve the witnessed event history to validators
5. Promulgate events on behalf of the controller when direct communication is not possible

The witness set is controller-managed and transferable - the controller can rotate witnesses through rotation events, maintaining control over the infrastructure supporting their identifier.

KAACE Consensus Algorithm

Security guarantees in indirect mode are provided through KA2CE (KERI's Agreement Algorithm for Control Establishment), which orchestrates consensus among the designated witness set. The algorithm ensures that:

• Witnesses reach agreement on the sequence and content of key events
• The threshold of accountable duplicity (TOAD) is satisfied before events are considered established
• Duplicity detection mechanisms can identify conflicting event sequences
• Validators can safely replay the key event history even when the controller is offline

Validator Operations

Indirect mode provides validators with three critical capabilities:

1. Verification: Cryptographic validation of key events without direct controller interaction
2. Control authority establishment: Determining the current authoritative key state
3. Duplicity detection: Identifying conflicting event sequences through comparison of witness attestations

All three capabilities depend on the validator's ability to replay the complete sequence of key events (the key event history or log) for a given identifier. Indirect mode ensures this replay capability remains available through the witnessed KERL infrastructure.

Trust Model

The indirect mode trust model is carefully structured:

• Primary root-of-trust: The controller's self-certifying identifier and cryptographic signatures
• Secondary root-of-trust: The witnessed KERL providing availability and attestation
• Validator independence: Validators make their own trust decisions based on witness attestations and their own security policies

Critically, witnesses do not control the identifier - they only attest to events they've observed. The controller's signatures remain the authoritative proof of control. This separation prevents witnesses from hijacking identifiers while still providing the availability benefits of distributed infrastructure.

Discovery and Bootstrapping

Indirect mode relies on OOBI (Out-Of-Band Introduction) for discovery of witness endpoints. An OOBI provides the initial association between an AID and the network locations of its witnesses. After this bootstrap introduction, all subsequent verification occurs through KERI's cryptographic mechanisms.

The system supports percolated discovery where:

• Initial OOBI provides witness locations
• Witnesses provide the complete KERL
• KERL may contain seals pointing to additional resources
• Discovery propagates through the network without requiring centralized directories

Availability Architecture

Indirect mode achieves nearly continuous availability through:

• Witness redundancy: Multiple witnesses maintain copies of the KERL
• Asynchronous operation: Validators can query witnesses at any time
• Mailbox mechanisms: Store-and-forward message delivery for asynchronous communication
• Watcher networks: Additional infrastructure for enhanced duplicity detection

This architecture enables mobile and web-based controllers with intermittent connectivity to maintain persistent, verifiable identifiers that remain accessible to validators even when the controller is offline.

Practical Implications

Use Cases

Enterprise Identity: Organizations issuing verifiable credentials need identifiers that remain available for verification even when internal systems are offline or undergoing maintenance. Indirect mode enables credential verifiers to validate credentials at any time by querying the issuer's witness infrastructure.

Mobile Applications: Smartphone-based identity wallets cannot maintain continuous network connectivity. Indirect mode allows these wallets to create events when online, with witnesses ensuring the event history remains available to verifiers even when the phone is offline.

Public Services: Businesses and services building reputation in persistent identifiers benefit from the high availability guarantees of indirect mode. Customers can verify the service's identity and credentials without requiring the service to be directly reachable.

Regulatory Compliance: Systems like vLEI (verifiable Legal Entity Identifier) require high availability for credential verification while maintaining cryptographic security. Indirect mode provides the infrastructure for GLEIF and Qualified vLEI Issuers to issue credentials that remain verifiable through witness networks.

Benefits

Availability Without Centralization: Indirect mode achieves high availability without requiring centralized infrastructure or trusted third parties. Each identifier has its own witness set, avoiding single points of failure.

Scalability: By localizing consensus to individual identifiers rather than requiring global agreement, indirect mode scales to support arbitrary numbers of identifiers without coordination overhead.

Flexibility: Controllers can choose their own witnesses, rotate witness sets, and adjust security parameters (like TOAD thresholds) based on their specific requirements.

Cryptographic Security: Despite relying on witnesses for availability, indirect mode maintains KERI's strong cryptographic guarantees. Witnesses cannot forge events or hijack identifiers - they can only attest to events they've observed.

Ambient Verifiability: The witnessed KERL structure enables anyone to verify identifier state at any time, supporting zero-trust computing models where verification doesn't depend on infrastructure security.

Trade-offs

Infrastructure Requirements: Indirect mode requires maintaining witness infrastructure, either self-hosted or through third-party witness services. This adds operational complexity compared to direct mode.

Trust Assumptions: While witnesses don't control identifiers, validators must trust that witnesses are honestly reporting events and not colluding to hide duplicity. The TOAD threshold and witness selection become critical security parameters.

Latency: Event establishment in indirect mode requires witness consensus, introducing latency compared to direct peer-to-peer communication. The time for events to be witnessed and receipts to be collected affects how quickly key state changes become authoritative.

Attack Surface: Indirect mode presents different attack surfaces compared to direct mode, particularly regarding availability attacks on witness infrastructure and consistency attacks through witness collusion. The protocol's mitigation properties are mode-specific.

Complexity: The witness consensus mechanism, KERL structure, and discovery protocols add complexity to implementations. Developers must understand witness selection, TOAD configuration, and OOBI resolution to properly deploy indirect mode systems.

Security Considerations

The KERI specification explicitly notes that direct and indirect modes have different attack surfaces for availability and consistency. Indirect mode's security depends on:

• Witness selection: Choosing witnesses with appropriate security properties and independence
• TOAD configuration: Setting thresholds that balance availability with security
• Watcher networks: Deploying additional infrastructure for enhanced duplicity detection
• OOBI security: Ensuring initial introductions are obtained through secure channels

Validators must assess these factors when deciding whether to trust identifiers operating in indirect mode, potentially requiring higher witness thresholds or additional verification for high-stakes interactions.

Relationship to Direct Mode

Indirect mode contrasts with direct mode, which supports intermittent availability through direct controller-validator communication. The choice between modes represents a fundamental design decision:

Direct Mode: Suitable for peer-to-peer scenarios, mobile devices with intermittent connectivity, and situations where maintaining witness infrastructure is impractical.

Indirect Mode: Appropriate for public services, enterprise applications, credential issuers, and any scenario requiring high availability or one-to-many interactions.

Many KERI deployments use both modes - direct mode for peer-to-peer interactions and indirect mode for public-facing identifiers. The protocol's flexibility allows controllers to choose the appropriate mode for each identifier based on its intended use case.

Operational Monitoring

Production deployments should monitor:

• Witness availability: Track uptime and response times for witness endpoints
• Receipt latency: Measure time from event creation to witness confirmation
• KERL consistency: Continuously compare KERLs across witnesses
• Query performance: Monitor validator query patterns and optimize witness infrastructure accordingly