Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 7 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 privacy-preserving mechanism where the current state of a transaction event log (TEL) is cryptographically hidden such that only the controller of a designated [AID](/concept/aid) can disclose the revocation state at presentation time, preventing ambient observation by verifiers.
Note: The available source material for blinded revocation registry consists of fragmentary conversation snippets from an ACDC working group meeting (December 6), explicitly marked as incomplete with "TBW" (To Be Written) warnings. The following explanation reflects this preliminary, work-in-progress status.
A blinded revocation registry is a privacy-enhancing mechanism within KERI's transaction event log (TEL) architecture where the current state of credential revocation is cryptographically hidden. The defining characteristic is that the only way for a potential verifier to observe the state is when the controller of a designated AID discloses it at the time of presentation.
This approach fundamentally shifts control of credential status information from public observability to presenter-controlled disclosure, contrasting with traditional revocation registries where any party can query credential status.
The conversation notes describe a bulk issuance approach:
The sources describe this mechanism as a "salty nonce blinding factor" designed for "ease of sharing a secret and hiding information" about credential state.
The salty nonce blinding factor is the cornerstone of the blinded revocation registry's security. Implementation must ensure:
Management TEL: Must be established before individual credential TELs. This management layer:
VC TEL: Each credential requires its own TEL that:
Registrars function as TEL backers analogous to KEL witnesses. Implementation should:
The 90-day grace period requires careful state management:
States: ISSUED → ACTIVE → GHOST → REVOKED
Transitions:
- ISSUED → ACTIVE: Credential activation
- ACTIVE → GHOST: Revocation initiated (start 90-day timer)
- GHOST → REVOKED: Grace period expires
- GHOST → ACTIVE: Revocation cancelled (if supported)
Implement automated monitoring for grace period expiration and state transitions.
The issuer-holder correlation through shared salt is an explicit design trade-off. Implementations must:
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.
The sources explicitly acknowledge a privacy limitation:
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.
The conversation notes mention that at presentation time:
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.
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:
The conversation notes reference broader TEL architecture components:
However, these components are only mentioned in passing within the fragmentary notes, and their specific integration with the blinding mechanism is not detailed.
The source material represents early-stage conceptual work rather than a complete specification. Multiple "TBW" markers indicate substantial work remains to fully define:
Developers and implementers should treat this concept as preliminary material requiring further specification work before production implementation.
Blinded revocation registries are designed for ACDC credentials using IPEX protocol:
Lost Blinding Factor: If holder loses the shared salt:
Registrar Unavailability: Implement redundancy:
Correlation Leakage: Monitor and audit:
Bulk Issuance Optimization: The documented bulk issuance process enables efficient large-scale deployments:
Presentation Latency: Blinded registries require synchronous disclosure:
Implementations should verify:
The source documents explicitly mark this as preliminary work-in-progress. Implementers should: