Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 16 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.
A blind OOBI is an Out-Of-Band Introduction where the AID verification mechanism exists independently of the OOBI itself, relying on pre-established trust relationships (such as witness lists or KEL verification) rather than embedded witness information, enabling indirect trust establishment through cryptographic commitments.
A blind OOBI (Blind Out-Of-Band Introduction) is a specialized discovery mechanism within the KERI protocol ecosystem where the verification of an AID (Autonomic Identifier) relies on external mechanisms rather than being directly embedded within the OOBI structure itself. Unlike standard OOBIs that contain explicit witness information, a blind OOBI is essentially a URL that references an AID without including the witness list or verification infrastructure.
The term "blind" indicates that the witness is not contained in the OOBI itself. Instead, verification depends on alternative mechanisms that have been established separately through pre-existing trust pathways. This separation of discovery from verification enables more flexible authentication patterns while maintaining KERI's cryptographic security guarantees.
The blind OOBI process involves several key participants:
Before implementing blind OOBI support, ensure proper trust infrastructure:
KEL Management: Implement robust KEL storage and retrieval mechanisms that can handle both local and remote KELs
Witness List Management: Maintain witness lists with proper CESR encoding and digital signature verification
Cryptographic Commitment Tracking: Track cryptographic commitments between AIDs, including rotation events that may affect commitments
Trust Policy Engine: Implement a policy engine that determines which intermediary AIDs are trusted and under what conditions
Implement a multi-stage verification process:
Trust Path Discovery: Implement algorithms to discover trust paths from known trusted intermediaries to referenced AIDs
Chain Verification: Verify each link in the trust chain, from trusted intermediary through to referenced AID
KEL Retrieval: Implement robust KEL retrieval from service endpoints, with appropriate timeout and retry logic
Root-of-Trust Verification: Verify KELs to their root-of-trust using KERI verification protocols
Caching Strategy: Implement caching for verified trust chains to avoid repeated verification overhead
Implement comprehensive error handling:
Missing Trust Path: Provide clear error messages when no trust path can be established
Invalid Commitments: Handle invalid or expired cryptographic commitments gracefully
KEL Unavailability: Implement fallback mechanisms when KELs cannot be retrieved
Duplicity Detection: Integrate with duplicity detection mechanisms to identify inconsistent witness lists
Blind OOBIs are particularly valuable in scenarios requiring:
Before a blind OOBI can function, certain trust infrastructure must exist:
This pre-establishment creates what the documentation calls a "via-via commitment" - a chain of indirect trust relationships that can be cryptographically verified.
The discloser provides a blind OOBI to the disclosee. The blind OOBI takes the form:
(url, aid)
For example:
("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")
Critically, this OOBI does not include witness information. The URL provides a service endpoint, and the AID identifies the entity, but the verification mechanism is not embedded.
The disclosee must resolve the trust path through pre-established mechanisms:
As the documentation states: "Here's my public key and here's my AID and because this in an another witness list I trust it."
Verification occurs through the established trust chain:
A blind AID can transition to an "unblind" state through direct relationship establishment:
This transition represents a shift from indirect verification (through trusted intermediaries) to direct verification (through direct relationship), strengthening the trust relationship.
KEL Integrity: The referenced AID must have a valid, cryptographically verifiable KEL that can be traced to its inception event
Witness List Cryptography: The witness list containing the cryptographic commitment must use proper digital signatures and CESR encoding
Commitment Verification: The cryptographic commitment from intermediary AID to referenced AID must be verifiable using KERI verification protocols
Root-of-Trust Chain: The entire chain from trusted intermediary through to referenced AID must be cryptographically verifiable to a root-of-trust
Pre-Establishment Requirement: Trust infrastructure (KELs, witness lists, commitments) must be established before the blind OOBI is presented
Asynchronous Verification: Verification can occur asynchronously - the disclosee does not need immediate access to all verification infrastructure
Progressive Trust Building: Trust can be established progressively, with initial blind verification followed by later direct verification
Witness Availability: Witnesses referenced in the trust chain must be available for KEL retrieval and verification
Missing Trust Path: If no trust path can be established from a known trusted intermediary to the referenced AID, the blind OOBI cannot be verified
Invalid Cryptographic Commitment: If the cryptographic commitment from intermediary to referenced AID is invalid or cannot be verified, verification fails
KEL Unavailability: If the KEL for the referenced AID cannot be retrieved from the service endpoint, verification cannot proceed
Witness List Inconsistency: If witness lists show duplicity or inconsistency, the blind OOBI verification should fail
Root-of-Trust Failure: If the KEL cannot be verified to a valid root-of-trust, the blind OOBI is not trustworthy
In an organizational context, a blind OOBI enables trust inheritance through organizational structures:
This pattern enables hierarchical trust delegation without requiring every employee AID to be directly verified by every verifier.
Blind OOBIs facilitate bootstrap into witness networks:
This pattern enables network expansion without requiring direct verification of every new participant.
Blind OOBIs support privacy-preserving identity introduction:
This pattern enables privacy-preserving authentication while maintaining verifiability for authorized parties.
Establish Trust Infrastructure First: Ensure KELs, witness lists, and cryptographic commitments are properly established before relying on blind OOBIs
Document Trust Paths: Clearly document the expected trust paths from known trusted intermediaries to referenced AIDs
Implement Fallback Mechanisms: Provide fallback to direct OOBI verification if blind OOBI verification fails
Monitor Witness Lists: Regularly verify that witness lists remain consistent and that cryptographic commitments remain valid
Plan for Unblinding: Design systems to support the transition from blind to direct verification as relationships mature
Validate Entire Chain: Always verify the complete chain from trusted intermediary to referenced AID, not just the final link
Handle Errors Gracefully: Implement robust error handling for missing trust paths, invalid commitments, and unavailable KELs
Witness Infrastructure: Blind OOBIs require integration with witness infrastructure for witness list management and KEL retrieval
Trust Policy Management: Systems must implement policies for determining which intermediary AIDs are trusted and under what conditions
KEL Storage and Retrieval: Integration with KEL storage systems is required for retrieving and verifying referenced AIDs
CESR Processing: Proper CESR encoding and decoding is required for processing witness lists and cryptographic commitments
OOBI Resolution: Systems must support both blind and standard OOBI resolution, with appropriate fallback mechanisms
Verification Caching: Consider caching verification results for blind OOBIs to avoid repeated verification of the same trust chains
Audit Trails: Maintain audit trails of blind OOBI verifications, including the trust paths used and verification outcomes
Blind OOBIs rely on transitive trust - trust in the referenced AID is derived from trust in an intermediary AID. This creates several security considerations:
Intermediary Compromise: If the trusted intermediary AID is compromised, all AIDs verified through that intermediary may be affected
Commitment Validity: The cryptographic commitment from intermediary to referenced AID must be continuously valid; rotation events may affect this
Witness List Integrity: The witness list providing the cryptographic commitment must maintain integrity; duplicity in witness lists undermines blind OOBI security
The depth of the trust chain affects security:
Blind OOBIs create a trade-off between privacy and verifiability:
Blind OOBIs represent an important pattern in KERI's design philosophy: separation of identification from verification mechanisms. By decoupling the OOBI (which provides discovery via URL and AID reference) from the verification infrastructure (which relies on established KELs, witness lists, and cryptographic commitments), the system achieves:
This architectural approach supports more efficient and scalable trust networks while preserving the security properties essential to KERI's design, particularly end-verifiability and duplicity detection.
Timeout Handling: Implement appropriate timeouts for network operations and verification processes
Support the transition from blind to direct verification:
Relationship Tracking: Track when direct relationships are established with previously blind AIDs
OOBI Upgrade: Implement mechanisms to upgrade from blind OOBI to direct OOBI when direct relationships are established
Verification Preference: Prefer direct verification over blind verification when both are available
State Management: Maintain state tracking for AIDs that have transitioned from blind to direct verification
Parallel Verification: Implement parallel verification of trust chain links where possible
Lazy Verification: Consider lazy verification strategies where full verification is deferred until needed
Verification Caching: Cache verification results with appropriate expiration policies
Witness List Optimization: Optimize witness list lookups and cryptographic commitment verification
Chain Length Limits: Implement limits on trust chain length to prevent excessive transitivity
Intermediary Validation: Regularly validate that trusted intermediaries remain trustworthy
Commitment Freshness: Verify that cryptographic commitments are current and have not been revoked
Duplicity Monitoring: Continuously monitor for duplicity in witness lists and KELs
Audit Logging: Maintain comprehensive audit logs of blind OOBI verifications and trust path resolutions