This is the **revocation oracle problem**, a fundamental tension in credential system design. ## Why it happens Most revocation schemes work by having the verifier (or your wallet) query a status endpoint at the moment of use: - **OCSP** (used in TLS certificates): your client sends the cert's serial number to the issuer's OCSP responder to ask "is this still valid?" - **Credential Status Lists** with per-credential endpoints: same pattern, different format In both cases, the issuer's server sees: - Which credential is being checked (its ID or index) - The IP address of the checker - The timestamp So the issuer can reconstruct: *credential X was used at place Y at time Z*. ## Why it's hard to fix Revocation requires the issuer to be able to mark a credential invalid *after* issuance. That inherently means some party needs fresh state from the issuer. The question is *who* fetches it and *what* is revealed in the fetch. ## The mitigations | Approach | How it helps | Tradeoff | |---|---|---| | **Bitstring Status List** (W3C) | Verifier downloads a large bitmap for many credentials at once; single index is harder to isolate | Issuer still sees *which list* was fetched, timing correlation remains | | **CRL caching** | Verifier downloads a full revocation list periodically, not per-use | List can be large; freshness lag | | **OCSP Stapling** | Server fetches and caches the OCSP response, presents it to clients | Issuer sees verifier, not holder; doesn't help holder-presented credentials | | **Cryptographic accumulators** (e.g., zk-SNARK based) | Holder proves non-revocation with a zero-knowledge proof; issuer never learns which credential or where | Complex, computationally expensive, harder to revoke efficiently | | **Short-lived credentials** | Credentials expire quickly (hours/days); no revocation check needed | Requires frequent re-issuance; issuer learns from issuance cadence instead | ## The core tradeoff Revocation = issuer retains post-issuance authority. Privacy = issuer loses post-issuance visibility. These are structurally in tension. Zero-knowledge proofs are the only approach that satisfies both rigorously, but they come with real engineering cost. This is why systems like **SD-JWT** and **ISO mDL** (mobile driver's licenses) are still working through this problem, and why "privacy-preserving revocation" is an active area in the W3C Verifiable Credentials working group.