2. Limited Visibility

The reconciliation or cleanup process has restricted observability within the network. The sources note that "only few people will see your reconciliation or clean up," indicating that fork resolution does not require network-wide disclosure or coordination.

This limited visibility characteristic provides operational privacy during recovery scenarios. Rather than broadcasting compromise and recovery details to all participants in the trust domain, the reconciliation mechanism allows targeted resolution with minimal exposure of the security incident.

Context Within KERI Architecture

While the reconciliation definition itself is minimal, understanding its role requires recognizing its position within KERI's broader duplicity handling architecture:

Duplicity Detection Foundation

Reconciliation operates downstream from KERI's duplicity detection mechanisms. The KERI specification establishes that duplicity exists when more than one verifiable version of a KEL is observed for a given AID. Detection mechanisms include:

• Internal verification: Each KEL version must be internally consistent with proper cryptographic signatures and hash chain integrity
• External comparison: Multiple verifiable KELs are compared to identify conflicts in event sequences, rotation events, or witness receipts

Reconciliation is the process invoked after duplicity has been detected and verified, representing the decision phase rather than the detection phase.

Relationship to Key State Determination

Validators in KERI determine the authoritative key state for an AID by evaluating KELs. The validator role, as defined in the source materials, involves determining "the current authoritative key set for an identifier from at least one key event (receipt) log." When multiple conflicting KELs exist, reconciliation becomes the mechanism by which a validator decides which version to accept as authoritative.

This connects reconciliation to the fundamental validator function: establishing control authority over identifiers. Without reconciliation, validators would lack a defined process for resolving conflicts when presented with forked event logs.

First-Seen Policy Integration

The KERI specification establishes first-seen as a foundational principle: "the first instance of a Message received by any Witness or Watcher. The first-seen event is always seen, and can never be unseen." This temporal precedence mechanism provides an objective basis for reconciliation decisions, though the specific procedures for applying first-seen policies during reconciliation are not detailed in the reconciliation-specific documentation.

Process Characteristics

Based on the available documentation, reconciliation exhibits these characteristics:

Decision-Oriented Nature

Reconciliation is explicitly described as a decision process - deciding "whether to accept a fork" or not. This binary framing indicates that reconciliation results in either:

• Acceptance: One version of the forked KEL is accepted as authoritative
• Rejection: The fork is deemed irreconcilable and the identifier may need to be abandoned

The sources do not document intermediate states, partial acceptance, or graduated reconciliation outcomes.

Controller-Initiated Process

The documentation specifically identifies the controller as the entity performing reconciliation: "the process in which a controller decides whether to accept a fork." This positions reconciliation as an action taken by the entity with control authority over the identifier, rather than a network-wide consensus process or validator-driven procedure.

However, validators also perform reconciliation when evaluating KELs for trust decisions, suggesting reconciliation operates at multiple levels within the KERI ecosystem.

Limited Observability Design

The stated advantage of "only few people will see your reconciliation or clean up" indicates reconciliation is designed to minimize the visibility and coordination requirements for fork resolution. This contrasts with blockchain-style consensus mechanisms that require network-wide agreement on canonical state.

Relationship to Other KERI Mechanisms

Reconciliation intersects with several other KERI protocol features, though the specific integration details are not comprehensively documented in the reconciliation-specific sources:

Pre-rotation Connection

The KERI architecture employs pre-rotation, where cryptographic commitments to next keys are established in previous events. This mechanism provides a foundation for distinguishing legitimate rotations from unauthorized forks during reconciliation, as authorized rotations use pre-committed keys while attacks would require non-committed keys.

Witness Agreement

The KERI specification establishes witness-based validation through KAACE (KERI's Agreement Algorithm for Control Establishment). Witnesses provide receipts that establish event observation, and their agreement patterns likely inform reconciliation decisions, though the specific witness role in reconciliation procedures is not detailed in the available sources.

Recovery Rotation Context

The stated advantage of potential identifier retention "after key compromise" connects reconciliation to recovery rotation scenarios. When keys are compromised, controllers can execute recovery rotations using pre-committed keys to establish new control authority. Reconciliation appears to be the process by which such recovery rotations are evaluated and potentially accepted by validators.

Documentation Limitations

The source materials provide only a minimal definition of reconciliation with two stated advantages. Specific details about reconciliation procedures, decision criteria, implementation requirements, and integration with other KERI mechanisms are not documented in the reconciliation-specific sources. The broader KERI specification likely contains additional reconciliation details delegated to sections on duplicity handling, witness consensus, and key state determination.

The attribution to Samuel Smith from a January 2, 2024 Zoom meeting indicates this definition represents authoritative guidance on KERI protocol behavior during fork scenarios, though it appears to be an outline or summary rather than a complete technical specification of the reconciliation process.

Implications for KERI Security Model

Reconciliation represents a critical decision point in KERI's security architecture. The ability to potentially recover from key compromise without identifier abandonment provides operational resilience, while the limited visibility of reconciliation protects operational security during recovery. However, the minimal documentation indicates that reconciliation is likely a complex mechanism with detailed procedures specified elsewhere in the KERI architecture, rather than a simple accept/reject decision at the protocol level.

Security Considerations

1. Timing Attacks: Implement protections against attackers manipulating timing to influence reconciliation. Use multiple independent time sources.

2. Witness Collusion: Design witness pools to resist collusion. Use threshold schemes that require supermajority agreement.

3. Evidence Integrity: Cryptographically sign all evidence (receipts, observations). Verify signatures during reconciliation.

4. Recovery Key Protection: Pre-rotated recovery keys must be protected with highest security. Compromise of recovery keys enables irreconcilable duplicity.

Testing and Validation

1. Reconciliation Scenarios: Test various reconciliation scenarios including:

   • Key compromise with successful recovery
   • Network partitions creating temporary duplicity
   • Witness failures during reconciliation
   • Irreconcilable duplicity requiring identifier abandonment

2. Evidence Simulation: Create test environments with simulated witnesses, watchers, and attackers to validate reconciliation logic.

3. Performance Testing: Measure reconciliation latency under various conditions. Optimize evidence collection and evaluation.

Integration with KERI Implementations

Reconciliation is supported across KERI implementations:

• KERIpy: Python reference implementation includes reconciliation logic in validator components
• KERIA: Cloud agent provides automated reconciliation for managed identifiers
• KLI: Command-line tools support manual reconciliation operations
• SignifyPy and SignifyTS: Client libraries expose reconciliation status and recovery operations