Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 169 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Duplicity in KERI refers to the existence of multiple, mutually inconsistent versions of a Key Event Log (KEL) for a single Autonomic Identifier (AID), where each version is internally consistent but externally inconsistent with other versions, creating provable evidence of controller misbehavior through non-repudiable signatures.
Duplicity represents a fundamental security concept in KERI that describes external inconsistency in identifier management. Specifically, duplicity occurs when two or more versions of a Key Event Log (KEL) exist for the same Autonomic Identifier (AID), where each version is internally consistent (cryptographically valid with proper hash chains and signatures) but mutually incompatible with other versions.
The critical property that makes duplicity detectable is that every event in a KEL must be signed with non-repudiable signatures. This means any inconsistency between two KEL instances for a given AID constitutes provable evidence of duplicity by the signers. The controller who signed both versions cannot deny creating the conflicting versions, making duplicity:
A crucial distinction exists between duplicity and incompleteness: a shorter KEL is not duplicitous if it contains identical events to a longer KEL but is simply incomplete. Duplicity requires actual conflicting information between versions, not merely missing events.
The concept of duplicity detection has roots in distributed systems research, particularly in addressing the Byzantine Generals Problem and achieving consensus in the presence of faulty or malicious actors. Traditional approaches to preventing duplicity relied on:
While duplicity is an abstract security concept, implementing effective duplicity detection requires careful attention to several technical aspects:
Implementations must be able to compare KEL versions to identify conflicts. This requires:
To enable duplicity detection, systems must:
Effective duplicity detection benefits from watcher infrastructure:
When duplicity is detected, implementations should:
Duplicity detection adds computational overhead:
Implementations should optimize these operations while maintaining security guarantees.
These approaches share a common limitation: they either require expensive global consensus mechanisms or depend on trusted intermediaries whose compromise undermines the entire system.
The innovation in KERI's approach is making duplicity evident rather than attempting to prevent it through consensus or trusted parties. This shift from prevention to detection fundamentally changes the security model and enables truly decentralized key management.
KERI implements a duplicity-evident infrastructure where the protocol makes duplicitous behavior cryptographically provable rather than attempting to prevent it. This approach leverages several key mechanisms:
Internal vs. External Consistency: KERI distinguishes between two types of consistency issues:
Pre-Rotation Security: KERI's pre-rotation mechanism creates forward commitments to next keys through cryptographic digests. This makes it impossible for an attacker to create a valid conflicting rotation event without access to the pre-committed rotation keys, even if they compromise current signing keys.
Witness Networks: Witnesses provide signed receipts of key events they observe, creating independent records of the KEL. When a controller attempts to present different KEL versions to different parties, witnesses can detect this duplicity by comparing their receipts.
Watcher Networks: Watchers operate in "promiscuous mode," collecting KELs from multiple sources without being designated by controllers. This creates an ambient duplicity detection capability where anyone can discover conflicting KEL versions.
First-Seen Policy: The protocol implements a "first seen, always seen" principle where the first version of an event observed by a witness or watcher becomes the canonical version for that observer. Any subsequent conflicting version is evidence of duplicity.
KERI introduces the Threshold of Accountable Duplicity (TOAD) parameter, which defines the minimum number of witness confirmations required before a controller accepts accountability for an event. This threshold enables:
The KERI specification describes various "duplicity game" scenarios that illustrate how duplicity can occur and be detected:
Scenario 1: Local Consistency Guarantee: A controller promises to provide consistent pair-wise logs in private one-to-one interactions. Without witnesses, the controller could provide different log versions to different validators without immediate detection.
Scenario 2: Global Consistency Guarantee: A service promises to provide the exact same log to everyone. Witnesses enable detection when the service violates this promise by providing different versions.
Scenario 3: Ambient Duplicity Detection: With a watcher network, any validator can independently verify consistency by comparing their received KEL against multiple independent sources, making duplicity evident to anyone.
KERI's duplicity-evident approach provides several critical security properties:
End-Verifiability: Any party can verify the consistency of a KEL by checking signatures and hash chains without trusting intermediaries.
Ambient Verifiability: Anyone, anywhere, at any time can detect duplicity by comparing KEL versions, creating a "trust but verify" model.
Non-Repudiation: Because all events are signed, controllers cannot deny creating duplicitous versions once detected.
Accountability: The combination of TOAD and witness receipts creates clear accountability for key events.
High-Stakes Identity Systems: In systems like GLEIF's vLEI ecosystem, duplicity detection ensures that Legal Entity credentials cannot be issued based on conflicting key states. The witness and watcher infrastructure provides multiple independent verification paths.
Supply Chain Provenance: When tracking goods through supply chains using ACDC credentials, duplicity detection ensures that conflicting claims about custody or authenticity can be detected and proven.
Delegated Authority: In hierarchical delegation structures, duplicity detection prevents a delegator from creating conflicting delegation events that could authorize multiple incompatible delegates.
Decentralization: Unlike blockchain-based systems that require global consensus, KERI's duplicity-evident approach enables truly decentralized operation where each validator makes independent trust decisions.
Scalability: By making duplicity evident rather than preventing it through consensus, KERI avoids the scalability limitations of blockchain systems.
Portability: Identifiers can be moved between different infrastructure providers without losing duplicity detection capabilities, as the KEL itself contains all necessary verification information.
Privacy: Duplicity detection doesn't require publishing all events to a global ledger, enabling privacy-preserving identity systems.
Detection vs. Prevention: KERI detects duplicity rather than preventing it. This means duplicitous behavior can occur, but it will be discovered and proven. This trade-off enables decentralization but requires validators to actively check for duplicity.
Witness Dependency: While KERI doesn't require trusted third parties, it does benefit from witness infrastructure. Controllers must maintain relationships with witnesses, and validators must access witness receipts to detect duplicity effectively.
Complexity: The duplicity detection mechanisms add complexity compared to simpler PKI systems. Implementers must understand concepts like pre-rotation, witness thresholds, and TOAD to properly configure and operate KERI-based systems.
Recovery Scenarios: When duplicity is detected, the system must have policies for how to respond. Unlike prevention-based systems where invalid events are simply rejected, duplicity-evident systems must handle the social and governance aspects of proven misbehavior.
Watcher Networks: Deploying effective duplicity detection requires watcher infrastructure that can collect and compare KELs from multiple sources. Organizations implementing KERI should consider operating watchers or using watcher services.
Witness Selection: Controllers should carefully select witnesses that are independent and unlikely to collude. Geographic and organizational diversity in witness pools enhances duplicity detection.
Monitoring: Systems should implement active monitoring for duplicity, not just passive detection. This includes regular comparison of KELs across different sources and alerting when inconsistencies are found.
Response Protocols: Organizations should establish clear protocols for responding to detected duplicity, including investigation procedures, communication plans, and remediation steps.
Audit Trails: Maintaining comprehensive audit trails of all KEL versions observed, including timestamps and sources, provides evidence for duplicity investigations and supports accountability.