When the Bit Changes: From Fresh Token to Verifier Decision

The PRC-based anonymous-credential revocation system becomes a real system only when its certificate is placed inside a credential lifecycle. This chapter follows the path from issuance to a valid presentation, then repeats the path after an authority changes the status record. The aim is to make the accept-or-reject decision—and the costs of database privacy, offline delegation, freshness, and availability—concrete enough that the later performance claims can be judged against the whole interaction.

From issuance to a failed token

The lifecycle starts when an issuer creates an anonymous credential for a holder. In the paper's construction, the issuer places a revocation index in a credential attribute. That index is not meant to become a public identifier during presentation; it is the private link between the credential and the authorities' status database. The authorities maintain a record for that position, and the paper uses a specific convention for its binary database: D[idx] = 1 means that the credential is valid.

That convention is local to the paper. The W3C Bitstring Status List uses a different meaning for a revocation bit, where a set bit expresses a true status such as revoked. Both systems use a binary representation, but a bit has meaning only within the lifecycle and algorithms that define it. Here, the important semantic rule is that the holder seeks a certificate for the paper's expected-valid value.

When the holder is about to present the credential, they request a fresh PRC response from the decentralized revocation authorities. The request is for the hidden index, not for a public identifier. The authorities privately process their shares, certify the record at that index, and attach auxiliary data that includes a timestamp. The response is a non-revocation token: a signed statement whose commitment binds the index and the record without exposing them to the authorities or to the eventual verifier.

The holder performs a local check before presenting. They know the credential's private index, the commitment randomness used in the request, and the candidate record they need to establish. They verify that the returned certificate matches the expected valid value and the correct hidden index. If the check fails, the holder outputs no non-revocation presentation. This local failure path is as important as the successful path: the protocol is designed to stop a revoked credential before the holder asks a verifier to accept it.

If the local check succeeds, the holder constructs an anonymous credential presentation. The presentation includes a zero-knowledge proof that connects three facts without disclosing the index: the holder knows a valid anonymous credential, the hidden index in that credential is the one committed in the PRC certificate, and the committed status is the valid one. The proof lets the verifier check consistency rather than trust the holder's assertion about which database record was queried.

The verifier does not repeat the private database lookup. They parse the presentation and check the timestamp against an application-specific freshness limit.