Blind OOBIs are particularly valuable in scenarios requiring:

• Type 2 authentication with minimized friction
• Authentication by reference where direct verification would create overhead
• Latent authenticity scenarios where trust can be inherited through organizational structures
• Progressive trust strengthening where relationships transition from indirect to direct
• Privacy-preserving introductions where full witness lists should not be immediately disclosed

Process Flow

Step 1: Pre-Establishment of Trust Infrastructure

Before a blind OOBI can function, certain trust infrastructure must exist:

1. KEL Establishment: The referenced AID must have a KEL (Key Event Log) that has been securely established and verified to its root-of-trust
2. Witness List Registration: The AID must be registered on a witness list that the verifier has access to
3. Cryptographic Commitment: A trusted intermediary AID must cryptographically commit to the referenced AID through mechanisms like witness lists

This pre-establishment creates what the documentation calls a "via-via commitment" - a chain of indirect trust relationships that can be cryptographically verified.

Step 2: Blind OOBI Presentation

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.

Step 3: Trust Path Resolution

The disclosee must resolve the trust path through pre-established mechanisms:

1. Identify Trust Intermediary: Locate a natural person or entity that you trust who owns an AID
2. Verify Intermediary KEL: Confirm that this trusted intermediary's AID has a KEL that has been securely established
3. Locate Cryptographic Commitment: Find the cryptographic commitment from the trusted intermediary AID to the referenced AID (typically through a witness list)
4. Verify Commitment Chain: Cryptographically verify the commitment chain from trusted intermediary to referenced AID

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."

Step 4: Indirect Verification

Verification occurs through the established trust chain:

1. Witness List Lookup: Check if the referenced AID appears on the witness list of a trusted intermediary
2. KEL Retrieval: Retrieve the KEL for the referenced AID through the service endpoint provided in the blind OOBI
3. Root-of-Trust Verification: Verify the KEL to its root-of-trust using KERI verification protocols
4. Commitment Validation: Validate that the cryptographic commitment from the trusted intermediary to the referenced AID is valid

Step 5: State Transition - Unblinding (Optional)

A blind AID can transition to an "unblind" state through direct relationship establishment:

1. Direct Contact: Establish direct communication with the human being or entity controlling the referenced AID
2. Direct OOBI Establishment: Create a direct OOBI to the formerly referenced AID
3. Trust Path Shortcut: This direct relationship shortcuts the blind OOBI mechanism, eliminating the need for the indirect trust path

This transition represents a shift from indirect verification (through trusted intermediaries) to direct verification (through direct relationship), strengthening the trust relationship.

Technical Requirements

Cryptographic Requirements

1. KEL Integrity: The referenced AID must have a valid, cryptographically verifiable KEL that can be traced to its inception event

2. Witness List Cryptography: The witness list containing the cryptographic commitment must use proper digital signatures and CESR encoding

3. Commitment Verification: The cryptographic commitment from intermediary AID to referenced AID must be verifiable using KERI verification protocols

4. Root-of-Trust Chain: The entire chain from trusted intermediary through to referenced AID must be cryptographically verifiable to a root-of-trust

Timing Considerations

1. Pre-Establishment Requirement: Trust infrastructure (KELs, witness lists, commitments) must be established before the blind OOBI is presented

2. Asynchronous Verification: Verification can occur asynchronously - the disclosee does not need immediate access to all verification infrastructure

3. Progressive Trust Building: Trust can be established progressively, with initial blind verification followed by later direct verification

4. Witness Availability: Witnesses referenced in the trust chain must be available for KEL retrieval and verification

Error Handling

1. 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

2. Invalid Cryptographic Commitment: If the cryptographic commitment from intermediary to referenced AID is invalid or cannot be verified, verification fails

3. KEL Unavailability: If the KEL for the referenced AID cannot be retrieved from the service endpoint, verification cannot proceed

4. Witness List Inconsistency: If witness lists show duplicity or inconsistency, the blind OOBI verification should fail

5. Root-of-Trust Failure: If the KEL cannot be verified to a valid root-of-trust, the blind OOBI is not trustworthy

Usage Patterns

Typical Scenarios

Scenario 1: Organizational Hierarchy

In an organizational context, a blind OOBI enables trust inheritance through organizational structures:

1. Root Organization AID: A root organization establishes an AID with a verified KEL
2. Department AIDs: Department AIDs are cryptographically committed to the root organization AID through witness lists
3. Employee Introduction: An employee AID is introduced via blind OOBI, referencing the department AID
4. Trust Inheritance: Because the department AID is trusted (via the root organization), the employee AID can be verified through the trust chain

This pattern enables hierarchical trust delegation without requiring every employee AID to be directly verified by every verifier.

Scenario 2: Witness Network Bootstrap

Blind OOBIs facilitate bootstrap into witness networks:

1. Known Witness: A verifier knows and trusts a specific witness AID
2. Witness List Reference: A new AID is introduced via blind OOBI, appearing on the known witness's witness list
3. Indirect Verification: The new AID is verified through its presence on the trusted witness's list
4. Progressive Verification: Over time, the verifier may establish direct verification with the new AID

This pattern enables network expansion without requiring direct verification of every new participant.

Scenario 3: Privacy-Preserving Introduction

Blind OOBIs support privacy-preserving identity introduction:

1. Minimal Disclosure: The blind OOBI discloses only the AID and service endpoint, not the full witness infrastructure
2. Selective Verification: Verifiers who have access to the appropriate witness lists can verify; others cannot
3. Controlled Correlation: By not including witness lists in the OOBI itself, correlation opportunities are reduced
4. Progressive Disclosure: Full witness information can be disclosed later if needed

This pattern enables privacy-preserving authentication while maintaining verifiability for authorized parties.

Best Practices

1. Establish Trust Infrastructure First: Ensure KELs, witness lists, and cryptographic commitments are properly established before relying on blind OOBIs

2. Document Trust Paths: Clearly document the expected trust paths from known trusted intermediaries to referenced AIDs

3. Implement Fallback Mechanisms: Provide fallback to direct OOBI verification if blind OOBI verification fails

4. Monitor Witness Lists: Regularly verify that witness lists remain consistent and that cryptographic commitments remain valid

5. Plan for Unblinding: Design systems to support the transition from blind to direct verification as relationships mature

6. Validate Entire Chain: Always verify the complete chain from trusted intermediary to referenced AID, not just the final link

7. Handle Errors Gracefully: Implement robust error handling for missing trust paths, invalid commitments, and unavailable KELs

Integration Considerations

1. Witness Infrastructure: Blind OOBIs require integration with witness infrastructure for witness list management and KEL retrieval

2. Trust Policy Management: Systems must implement policies for determining which intermediary AIDs are trusted and under what conditions

3. KEL Storage and Retrieval: Integration with KEL storage systems is required for retrieving and verifying referenced AIDs

4. CESR Processing: Proper CESR encoding and decoding is required for processing witness lists and cryptographic commitments

5. OOBI Resolution: Systems must support both blind and standard OOBI resolution, with appropriate fallback mechanisms

6. Verification Caching: Consider caching verification results for blind OOBIs to avoid repeated verification of the same trust chains

7. Audit Trails: Maintain audit trails of blind OOBI verifications, including the trust paths used and verification outcomes

Security Considerations

Trust Transitivity

Blind OOBIs rely on transitive trust - trust in the referenced AID is derived from trust in an intermediary AID. This creates several security considerations:

1. Intermediary Compromise: If the trusted intermediary AID is compromised, all AIDs verified through that intermediary may be affected

2. Commitment Validity: The cryptographic commitment from intermediary to referenced AID must be continuously valid; rotation events may affect this

3. Witness List Integrity: The witness list providing the cryptographic commitment must maintain integrity; duplicity in witness lists undermines blind OOBI security

Verification Depth

The depth of the trust chain affects security:

1. Single-Hop Trust: Direct cryptographic commitment from a trusted intermediary to the referenced AID (strongest)
2. Multi-Hop Trust: Multiple intermediaries in the trust chain (weaker, more points of potential failure)
3. Chain Length Limits: Consider implementing limits on trust chain length to prevent excessive transitivity

Privacy vs. Verifiability Trade-off

Blind OOBIs create a trade-off between privacy and verifiability:

1. Privacy Benefit: Not including witness lists in the OOBI reduces correlation opportunities
2. Verifiability Constraint: Only parties with access to the appropriate witness lists can verify
3. Selective Disclosure: This trade-off enables selective disclosure of verification capabilities

Relationship to KERI Architecture

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:

1. Flexibility: Multiple verification paths can exist for the same AID
2. Scalability: Not every OOBI must carry complete verification information
3. Privacy: Verification capabilities can be selectively disclosed
4. Efficiency: Trust can be inherited through verified intermediaries without requiring every interaction to include complete verification paths

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.

Unblinding Support

Support the transition from blind to direct verification:

1. Relationship Tracking: Track when direct relationships are established with previously blind AIDs

2. OOBI Upgrade: Implement mechanisms to upgrade from blind OOBI to direct OOBI when direct relationships are established

3. Verification Preference: Prefer direct verification over blind verification when both are available

4. State Management: Maintain state tracking for AIDs that have transitioned from blind to direct verification

Performance Considerations

1. Parallel Verification: Implement parallel verification of trust chain links where possible

2. Lazy Verification: Consider lazy verification strategies where full verification is deferred until needed

3. Verification Caching: Cache verification results with appropriate expiration policies

4. Witness List Optimization: Optimize witness list lookups and cryptographic commitment verification

Security Hardening

1. Chain Length Limits: Implement limits on trust chain length to prevent excessive transitivity

2. Intermediary Validation: Regularly validate that trusted intermediaries remain trustworthy

3. Commitment Freshness: Verify that cryptographic commitments are current and have not been revoked

4. Duplicity Monitoring: Continuously monitor for duplicity in witness lists and KELs

5. Audit Logging: Maintain comprehensive audit logs of blind OOBI verifications and trust path resolutions