Rainbow Table Attack Resistance

The conversation notes state that "no information can be obtained via a rainbow-table-attack because the hash has enough entropy added to it." This indicates the blinding mechanism adds sufficient randomness to prevent pre-computation attacks on credential status values. However, specific entropy requirements are not detailed in the available sources.

Correlation Trade-off

The sources explicitly acknowledge a privacy limitation:

• "The shared salt correlates between the issuer and the issuee"
• This is described as "the worst problem we have to consider, which is acceptable"

This represents a deliberate design trade-off where issuer-holder correlation is accepted to enable the blinding mechanism. The sources do not elaborate on whether this correlation risk can be mitigated through additional techniques.

Presentation Process (Fragmentary)

The conversation notes mention that at presentation time:

• The presenter must perform some form of "decomposition" to reveal state
• The verifier receives sufficient information to conclude: "Yes, that was an approved schema issued by the issuer!"
• The blinding mechanism protects against observers determining state without the holder's cooperation

The sources do not provide complete details on the cryptographic protocols used during presentation or how the blinding factor is applied to prove state validity.

Use Case Context

The sources indicate this mechanism is specifically designed to "hide the state of certain credentials to some verifiers in the future, while keeping the state verifiable for others." This suggests use cases where:

• Credential holders require privacy protection against surveillance of usage patterns
• Selective disclosure of revocation state is necessary for different verifier relationships
• The issuer-holder correlation is an acceptable trade-off for enhanced presentation privacy

Related TEL Infrastructure (Mentioned)

The conversation notes reference broader TEL architecture components:

• Management TEL: Signals creation of the credential registry and tracks the list of registrars
• VC TEL: Tracks issued/revoked state of individual virtual credentials
• Registrars: Act as backers for TEL infrastructure, analogous to witnesses in KERI KEL systems
• Grace Period: A 90-day period for "ghost credentials" before revocation is finalized

However, these components are only mentioned in passing within the fragmentary notes, and their specific integration with the blinding mechanism is not detailed.

Implementation Status

The source material represents early-stage conceptual work rather than a complete specification. Multiple "TBW" markers indicate substantial work remains to fully define:

• Complete cryptographic protocols for blinding and disclosure
• Integration with existing KERI/ACDC presentation protocols
• Operational procedures for salt management and key lifecycle
• Security analysis beyond the rainbow table attack consideration
• Detailed privacy analysis of the acknowledged correlation problem

Developers and implementers should treat this concept as preliminary material requiring further specification work before production implementation.

Integration with ACDC/IPEX

Blinded revocation registries are designed for ACDC credentials using IPEX protocol:

• Ensure proper SAID usage for credential integrity
• Implement schema validation during issuance and presentation
• Support IPEX message flows for credential exchange
• Maintain ACDC chaining for provenance

Error Handling Strategies

Lost Blinding Factor: If holder loses the shared salt:

• Credential becomes unpresentable
• May require reissuance with new blinding factor
• Consider backup/recovery mechanisms

Registrar Unavailability: Implement redundancy:

• Sufficient registrar pool size
• Threshold-based consensus
• Fallback mechanisms for temporary unavailability

Correlation Leakage: Monitor and audit:

• Document known correlation channels
• Implement correlation minimization where possible
• Provide holder tools to understand correlation risks

Performance Considerations

Bulk Issuance Optimization: The documented bulk issuance process enables efficient large-scale deployments:

• Batch credential creation
• Shared blinding factors for credential sets
• Parallel TEL creation

Presentation Latency: Blinded registries require synchronous disclosure:

• Optimize cryptographic operations
• Pre-compute presentation proofs where possible
• Consider caching strategies for frequently presented credentials

Testing and Validation

Implementations should verify:

• Rainbow table attack resistance through entropy testing
• Proper state transitions through grace period
• Registrar consensus under various failure scenarios
• Privacy properties through correlation analysis
• Integration with KEL anchoring mechanisms

Specification Status Warning

The source documents explicitly mark this as preliminary work-in-progress. Implementers should:

• Consult the formal ACDC specification's blindable state TEL section
• Participate in ACDC working group discussions
• Expect implementation details to evolve
• Plan for specification changes in production systems
• Monitor the ACDC specification repository for updates