Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 175 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.
Binding is the cryptographic association of two data elements, such as linking an identifier to a key pair, or connecting data to its cryptographic commitment, thereby establishing verifiable relationships that enable authentication, integrity verification, and control authority.
Binding refers to the technique of creating verifiable associations between data elements through cryptographic mechanisms. In identity systems and verifiable data structures, binding establishes relationships that can be independently verified without requiring trust in intermediaries. The fundamental purpose is to create tamper-evident connections where any modification to the bound elements becomes cryptographically detectable.
The concept encompasses several types of associations:
A critical property of cryptographic binding is that it creates strong binding - relationships that cannot be forged or modified without detection. This contrasts with weak binding found in traditional systems where associations depend on administrative processes or trusted intermediaries rather than cryptographic proofs.
The scope of binding extends beyond simple one-to-one associations. In KERI-based systems, binding creates complex graphs of verifiable relationships including delegation hierarchies, credential chains, and event sequences. Each binding contributes to an overall architecture of verifiable provenance and control authority.
Traditional identity systems relied on administrative binding where trusted authorities maintained mappings between identifiers and keys. The classic example is the DNS/Certificate Authority model where CAs bind domain names to public keys through signed certificates. This approach suffers from:
When implementing SAID-based binding:
# characters)Verifying identifier-to-key binding through KELs requires:
When verifying ACDC credential bindings:
Implementing privacy-preserving binding:
The evolution toward self-certifying identifiers represented a significant advancement. In systems like IPFS and early blockchain implementations, identifiers were derived directly from public keys, creating cryptographic binding without external authorities. However, these early approaches had limitations:
The development of verifiable credentials (W3C VC specification) introduced binding between credentials and subjects through cryptographic signatures. However, the binding mechanism still depended on external identifier resolution systems (DIDs) that often relied on ledgers or centralized registries.
KERI implements binding through multiple complementary mechanisms that work together to create a comprehensive verifiable infrastructure:
KERI's Autonomic Identifiers (AIDs) establish binding between identifiers and key pairs through cryptographic derivation. The identifier prefix is either:
This creates strong cryptographic binding where the identifier itself proves its relationship to the controlling keys. Unlike traditional PKI, no external registry or certificate is needed to verify the binding.
The Key Event Log (KEL) extends self-certifying binding to support key rotation while maintaining identifier persistence. Each event in the KEL:
This creates a verifiable chain of binding that proves the current key state is the legitimate successor to the inception keys, even after multiple rotations. The binding is end-verifiable - anyone can cryptographically verify the entire chain without trusting intermediaries.
Self-Addressing Identifiers (SAIDs) create binding between identifiers and content through a recursive digest mechanism:
This binding enables:
Authentic Chained Data Containers (ACDCs) implement multiple layers of binding:
i field contains the issuer's AID, cryptographically binding the credential to its issuera.i field contains the issuee's AID (when present), binding the credential to its subjects field contains the schema SAID, binding the credential to its structure definitione (edges) section contains SAIDs of parent credentials, creating verifiable credential chainsThese bindings work together to create verifiable provenance chains where each credential's authenticity can be traced back to its root of trust.
KERI's cooperative delegation creates binding between delegator and delegate AIDs through mutual cryptographic commitments:
This bidirectional binding ensures neither party can unilaterally establish or modify the delegation relationship. The binding is verifiable by examining both KELs.
Witnesses are bound to AIDs through:
This creates a verifiable infrastructure where witness participation can be cryptographically proven.
Binding has significant privacy implications. In KERI, the document notes that binding "lifts the privacy of the subject through that connection" - creating associations between previously separate data elements. This means:
KERI addresses these concerns through:
Organizational Identity: The vLEI ecosystem uses binding extensively:
These bindings create a verifiable hierarchy from GLEIF's root of trust down to individual role holders.
Supply Chain: Binding enables verifiable provenance:
Access Control: Binding supports authorization systems:
Verifiable Provenance: Binding creates auditable chains of custody and authority. Every credential, delegation, and authorization can be traced back to its root of trust through cryptographic verification.
Portability: KERI bindings are infrastructure-independent. AIDs and their bindings can move between systems, ledgers, or networks while maintaining verifiability.
Scalability: Binding through SAIDs enables compact references to complex data structures. A 44-character SAID can represent an entire credential graph.
Interoperability: Standardized binding mechanisms enable different systems to verify relationships without requiring shared infrastructure or trust frameworks.
Complexity: Implementing proper binding requires understanding multiple cryptographic primitives (digests, signatures, key derivation) and their interactions.
Performance: Computing SAIDs and verifying binding chains adds computational overhead compared to simple database lookups.
Privacy: Strong binding can enable correlation and tracking. Systems must carefully design disclosure patterns to balance verifiability with privacy.
Key Management: Binding to keys means key compromise affects all bound relationships. KERI's pre-rotation mitigates this but adds complexity.
Revocation: Changing bindings (like revoking credentials) requires additional infrastructure (TELs) and careful state management.
The fundamental trade-off is between security/verifiability and simplicity/performance. KERI's approach prioritizes cryptographic verifiability, accepting the complexity and computational costs as necessary for trustworthy decentralized identity systems.