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:

• Ephemeral identifiers: Key rotation required abandoning the identifier
• No recovery mechanisms: Key compromise meant permanent loss of control
• Limited delegation: Hierarchical key management was difficult or impossible

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's Approach

KERI implements binding through multiple complementary mechanisms that work together to create a comprehensive verifiable infrastructure:

Self-Certifying Identifier Binding

KERI's Autonomic Identifiers (AIDs) establish binding between identifiers and key pairs through cryptographic derivation. The identifier prefix is either:

• Directly derived from the public key using a one-way function
• Self-addressing - derived from a digest of the inception event that includes the public key

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.

Key Event Log Binding

The Key Event Log (KEL) extends self-certifying binding to support key rotation while maintaining identifier persistence. Each event in the KEL:

• Backward chains to previous events through cryptographic digests
• Forward chains to next keys through pre-rotation commitments
• Signs the event with current authoritative keys

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.

SAID-Based Content Binding

Self-Addressing Identifiers (SAIDs) create binding between identifiers and content through a recursive digest mechanism:

1. Content is serialized with a placeholder for the SAID
2. A cryptographic digest is computed over the serialized content
3. The digest becomes the SAID, which is embedded in the content
4. The final content is self-addressing - its identifier is cryptographically bound to its content

This binding enables:

• Tamper evidence: Any modification changes the SAID
• Content addressability: The identifier uniquely identifies the content
• Compact references: SAIDs can represent complex data structures efficiently

ACDC Credential Binding

Authentic Chained Data Containers (ACDCs) implement multiple layers of binding:

• Issuer binding: The credential's i field contains the issuer's AID, cryptographically binding the credential to its issuer
• Subject binding: The a.i field contains the issuee's AID (when present), binding the credential to its subject
• Schema binding: The s field contains the schema SAID, binding the credential to its structure definition
• Chaining binding: The e (edges) section contains SAIDs of parent credentials, creating verifiable credential chains

These bindings work together to create verifiable provenance chains where each credential's authenticity can be traced back to its root of trust.

Delegation Binding

KERI's cooperative delegation creates binding between delegator and delegate AIDs through mutual cryptographic commitments:

• The delegator includes a seal in their KEL referencing the delegate's inception event
• The delegate includes a seal in their inception event referencing the delegating event
• Both parties sign their respective events

This bidirectional binding ensures neither party can unilaterally establish or modify the delegation relationship. The binding is verifiable by examining both KELs.

Witness Binding

Witnesses are bound to AIDs through:

• Configuration binding: The inception event specifies witness AIDs and thresholds
• Receipt binding: Witnesses sign receipts that reference specific events
• OOBI binding: Out-of-band introductions bind witness AIDs to network endpoints

This creates a verifiable infrastructure where witness participation can be cryptographically proven.

Practical Implications

Privacy Considerations

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:

• Identifier correlation: Binding an AID to a subject enables tracking across contexts
• Credential correlation: Binding credentials to subjects enables profiling
• Relationship disclosure: Binding reveals organizational structures and authority relationships

KERI addresses these concerns through:

• Pseudonymous AIDs: Identifiers don't inherently reveal subject information
• Selective disclosure: ACDCs support revealing only necessary attributes
• Graduated disclosure: Progressive revelation of bindings as trust develops
• Chain-link confidentiality: Legal protections on how binding information is used

Use Cases

Organizational Identity: The vLEI ecosystem uses binding extensively:

• QVI binding: GLEIF binds Qualified vLEI Issuer credentials to QVI AIDs
• Legal Entity binding: QVIs bind Legal Entity credentials to organization AIDs
• Role binding: Organizations bind role credentials to individual AIDs
• Authorization binding: Legal entities bind authorization credentials to QVIs

These bindings create a verifiable hierarchy from GLEIF's root of trust down to individual role holders.

Supply Chain: Binding enables verifiable provenance:

• Product binding: Physical items bound to digital twins via ACDCs
• Custody binding: Transfer events bind products to new custodians
• Certification binding: Quality certifications bound to products
• Audit binding: Inspection records bound to specific product instances

Access Control: Binding supports authorization systems:

• Permission binding: Authorization credentials bound to specific AIDs
• Resource binding: Access rights bound to protected resources
• Delegation binding: Authority delegated through verifiable credential chains
• Revocation binding: Revocation events bound to specific credentials

Benefits

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.

Trade-offs

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.

Performance Optimization

• Cache verified bindings to avoid redundant cryptographic operations
• Parallelize verification of independent binding chains
• Use compact representations (SAIDs) instead of full content when possible
• Implement incremental verification for long KELs (verify only new events)
• Optimize SAID computation using efficient hash implementations (Blake3 is faster than SHA-256)