Checkpoint: The Hidden Index Is the Whole Problem

The PRC-based anonymous-credential revocation system can now be reduced to one design contract: a holder needs a current validity decision, the revocation authorities must not learn which record was requested, and a verifier must receive a binding fact rather than a bare assertion. This checkpoint connects those requirements to the difference between a shared public status artifact and a private certificate for one hidden record. The useful test is whether we can predict what each participant learns and what the server side must do next.

One problem, three constraints

Imagine a credential that lets its holder use a regulated service. The issuer created it legitimately, but circumstances can change: the credential may be lost, stolen, misused, or associated with a qualification that is no longer acceptable. At the next presentation, the verifier must be able to reject it. That is the accountability side of the problem.

Now add the privacy goal. The credential is anonymous, so the holder should be able to disclose only the claim relevant to this service. A status check should not turn the hidden credential into a stable identifier that tells an issuer where and when the holder is interacting. The revocation authorities may maintain the database that records current status, but a legitimate query should not tell them which database row the holder selected. That is the query-privacy side.

Finally, the decision has to be practical. A nationwide system may contain hundreds of millions or more credentials, while the holder may be using a phone and the verifier may have only a short interaction window. A solution that sends a database-sized object to every holder, asks every user to refresh a witness after every revocation, or makes the verifier perform a large proof each time may preserve one property while failing the deployment problem.

These requirements constrain one another. A long-lived witness or cached list reduces network work but can keep a revoked credential acceptable after the status has changed. A fresh query improves timeliness but makes authorities and network reachability part of every presentation. A public list can share status information across a large group, but the list's index, URL, update pattern, and access logs may still provide correlation clues. A private query can hide the requested row, but the authorities then need to perform more work on demand.

The PRC proposal is valuable because it names this joint constraint instead of optimizing one dimension in isolation. It does not claim that the authorities can forget the database or that a verifier can accept a credential without checking anything. It changes the shape of the evidence: the authorities privately certify a record at a hidden index, and the holder later proves that the certificate belongs with the anonymous credential.

flowchart LR P["Privacy: hide the requested record"] --> C["Private certificate"] F["Freshness: check a changing status"] --> C S["Scale: keep holder and verifier work small"] --> C C --> Z["Zero-knowledge link to anonymous credential"] Z --> V["Verifier receives a binding validity decision"]

The diagram is a compact test of the mental model. Privacy alone would not tell the verifier whether the certificate is true. Freshness alone could still expose the holder's identity. Scale alone could be achieved by a public list that does not meet the authority-side privacy goal.