Privacy analysis
This page lays out the trust boundary shifts when revocation is added to OpenAC, and the residual risks each design choice leaves on the table. The baseline is the OpenAC paper's analysis (Paper §Security); the deltas below describe what changes once a revocation channel exists.
Baseline (no revocation)
- Soundness. Malicious holder cannot produce a Prepare/Show pair that verifies without a valid SD-JWT and the device private key.
- Zero-knowledge. Verifier learns the public outputs of the Show circuit (predicate result, device public key) and nothing else about .
- Unlinkability. Two presentations from the same holder are computationally indistinguishable to a coalition of verifiers, assuming fresh blinds and fresh nonces.
The threat model is honest issuer, malicious prover, semi-honest verifier, colluding verifiers (Security — threat model).
Adding out_of_band checks
| Property | Effect |
|---|---|
| Soundness | Unchanged for the ZK layer. Becomes dependent on the integrity of the status channel. |
| Zero-knowledge | Unchanged for the ZK proof; the channel itself reveals additional information. |
| Unlinkability | Broken in the strong sense. Issuer learns the time and verifier identity of each check. Issuer + verifier can re-identify the holder. |
This is the current default in the PoC's Studio. Treat it as a stopgap suitable for low-stakes deployments where the issuer is contractually bound not to use revocation telemetry for tracking.
Adding in_proof_future with a non-membership tree
| Property | Effect |
|---|---|
| Soundness | Augmented: holder must additionally know a witness for non-membership of the credential ID in under the issuer-signed root . Forgery requires breaking the hash, ECDSA on the root, or the Spartan2 argument. |
| Zero-knowledge | Augmented: the sub-proof reveals only the root and the bit "non-member". Holder identifier remains private. |
| Unlinkability | Preserved against verifiers provided the wallet refreshes its witness on a schedule independent of presentations, and the issuer-published (root, epoch) is identical for everyone in that epoch. |
The residual risks form a checklist for the implementation profile:
Issuer-side residual risks
- Selective inclusion. A malicious issuer can mint two trees with different membership and serve different ones to different wallets. Mitigation: publish roots to a public transparency log; clients verify inclusion of their served root.
- Epoch padding. An issuer that updates the tree only when revoking a specific credential leaks information about who was revoked. Mitigation: update on a fixed cadence even with empty diffs.
- Witness-fetch identification. If the witness fetch endpoint serves per-leaf responses, the issuer learns who holds which credential. Mitigation: serve k-anonymous slices, range queries with padding, or oblivious access patterns.
Wallet-side residual risks
- Presentation-coupled refresh. Refreshing the witness right before a presentation correlates the fetch with the verifier. Mitigation: refresh on a schedule independent of UI events.
- Multi-credential correlation. A wallet with several credentials from the same issuer that refreshes them at staggered times leaks which credentials it holds. Mitigation: batch refreshes.
Verifier-side residual risks
- Replay against a forgotten root. A verifier that accepts a root not in its trust window but never invalidates older roots can be replayed. Mitigation: explicit per-epoch validity windows and rejection of unknown roots.
- Side channels. Witness sizes are constant in the non-membership tree by construction; the proof size is constant too. Verifiers should reject variable-length envelopes that hint at the underlying scheme.
Side-channel posture
- Timing. Prove/verify timings are dominated by Spartan2 IPA and are independent of credential content; they do leak the verifier's hardware class. This is not specific to revocation.
- Witness sizes. Constant in the non-membership tree by construction.
- Network layer. Fetching witnesses, signing nonces, and submitting proofs each create separate observable events. Apps should pad and batch as described above and avoid third-party telemetry libraries on the proving path.
When the implementation lands, this page will be revised to refer to the actual circuit witnesses and to publish the formal privacy theorems against the new relation.