Revocation overview
Revocation is not implemented in openac-sdk 0.1.0 or in the wallet-unit-poc circuits. This section captures the design space, the constraints OpenAC imposes on candidate schemes, and pointers to ongoing research. Track delivery on the zkID 2026 roadmap.
Who this is for
Architects deciding how a wallet can prove "credential not revoked" without leaking which credential it holds, and researchers comparing accumulator / Merkle / status-list approaches under OpenAC's unlinkability constraints.
The problem in one paragraph
Classic revocation mechanisms — CRLs, status lists, OCSP — typically reveal which credential is being checked. Even a W3C Bitstring Status List leaks the index the holder cares about. If the verifier can correlate that index with subsequent presentations, OpenAC's unlinkability collapses. The goal of an OpenAC-compatible revocation scheme is to let a verifier learn the bit "credential is still valid" with no additional information that could link two presentations of the same credential.
Three scenarios modelled today
OpenAC Studio encodes three states (ruleset.ts). Each maps to a different trust assumption:
| State | What the wallet does | Trust assumption | Privacy cost |
|---|---|---|---|
none | Skip revocation entirely. | Issuer never revokes (e.g. low-stakes attributes that expire instead). | None — but you have no revocation. |
out_of_band | Verifier independently queries an issuer-side status endpoint. | Verifier trusted not to collude with issuer; verifier and issuer have a side channel. | High: issuer learns when and from whom a presentation occurs; with verifier metadata, can re-identify the holder. |
in_proof_future | Wallet attaches a ZK sub-proof that the credential ID is in the issuer's "valid" set. | Honest issuer publishing roots; correct verification of the membership/non-membership relation. | Designed to be zero (no per-credential identifier leaves the wallet). Not yet implemented. |
The Studio surface intentionally warns when the user selects in_proof_future; the wallet refuses to claim coverage it cannot deliver.
Constraints OpenAC imposes on any revocation scheme
- No fresh per-credential identifier in the clear. The presentation transcript already exposes the verifier nonce and the proof bytes. Adding a stable identifier (e.g. credential ID, status-list index) defeats unlinkability.
- Issuer-published state must be authenticated. A wallet attaching a witness against last-week's accumulator must be able to prove the root is current and signed by the issuer key the verifier already trusts.
- Compatibility with the Prepare/Show split. A revocation sub-proof should ideally fit into Show (per-session work) rather than Prepare (cached) — revocation status changes more often than the credential.
- Compatibility with the Tom256 / P-256 backend. New gadgets should live in the same Spartan2 instance to avoid a second proving system. See Security — assumptions.
Pages in this section
- Non-membership tree — design vocabulary and the candidate scheme analysed in the PSE blog.
- Issuer operations — what an issuer would need to publish.
- Verifier checks — how the verifier accepts a revocation sub-proof without learning the credential ID.
- Wallet flows — wallet-side witness management and freshness handling.
- Privacy analysis — how each candidate shifts the trust boundary.
External references
- PSE blog, Revocation in zkID: Merkle Tree-based Approaches — pse.dev.
- DIF Labs, Privacy-preserving revocation mechanisms report — GitHub.
- W3C, Bitstring Status List v1.0 — W3C (contrast / non-private baseline).
The repository's design note lives at revocation/README.md; the paper's formal treatment is in eprint 2026/251.