Verifier checks

Research preview

in_proof_future is explicitly flagged as not implemented in OpenAC Studio (ruleset.ts). This page describes the checks a verifier would perform once the feature lands.

A verifier accepting an OpenAC presentation with revocation has three checks beyond the baseline OpenAC.verify:

1. The presentation includes a revocation sub-proof.
2. The Merkle root referenced by that sub-proof was published recently by a key the verifier trusts.
3. The sub-proof's non-membership argument verifies against that root.

Current PoC

Verifiers run the out_of_band scenario: they call OpenAC.verify(proof, keys) (which checks Prepare + Show + linking + device-binding signature) and then independently query the issuer's status endpoint with the credential identifier. This pattern is functional but defeats unlinkability because the issuer now learns the verifier's identity and the time of presentation; in the worst case the issuer and the verifier together re-identify the holder.

OpenAC Studio refuses to claim coverage for this case and surfaces the linkability cost in the rules UI.

Future in-proof model

Once a non-membership scheme ships, the presentation envelope grows to:

{
  "prepareProof": ...,
  "showProof": ...,
  "prepareInstance": ...,
  "showInstance": ...,
  "revocation": {
    "root": "<hex>",
    "epoch": 4287,
    "rootSignature": "<ECDSA-P256>",
    "proof": "<ZK sub-proof bytes>"
  }
}

The verifier:

Each check has a failure mode the verifier must distinguish:

Check	Failure mode	Likely cause
Sub-proof present	Missing	Wallet older than the verifier's policy; reject and surface remediation.
Root signature	Bad	Forged or expired root; reject.
Freshness	epoch outside window	Wallet has stale witness; ask the wallet to refresh and resubmit.
Non-membership ZK proof	Invalid	Credential is revoked, or wallet has buggy proof generation; reject.

Verifier configuration the profile must define

• Freshness window $\Delta$. How old a (root, epoch) may be at presentation time.
• Trusted issuer keys. How a verifier discovers the issuer's revocation-signing key and rotates it.
• Granularity of "revoked". Whether a credential can be partially revoked (e.g. only the device key) or only fully revoked.
• Replay handling. Whether the verifier maintains a per-session cache of (root, epoch) to detect rollback attacks against the issuer registry.

These details belong in the Implementation profile; they are intentionally out of scope of the SDK's stable API surface.