Issuer operations

Research preview

None of the operations described below are implemented in openac-sdk 0.1.0. This page captures the contract an issuer must satisfy to support the in_proof_future profile.

An issuer that wants to plug a privacy-preserving revocation scheme into OpenAC has four responsibilities. Each maps to a public artefact the wallet and verifier will need to fetch.

1. Maintain the revoked set

The issuer maintains the set $S$ of revoked credential identifiers. Identifiers should be:

• stable — present in every credential the issuer mints (e.g. an internal serial number);
• opaque — chosen so that holders cannot guess each other's IDs from public information;
• field-encodable — fit in the proving curve's scalar field with room for sentinel values.

When a credential is revoked, the issuer inserts its identifier into $S$ and republishes the structure described in Non-membership tree.

2. Publish authenticated roots

Each update produces a new Merkle root $R_t$ at logical time $t$. The issuer publishes a signed bundle:

{
  "root": "<hex>",
  "epoch": 4287,
  "publishedAt": "2026-05-14T00:00:00Z",
  "signature": "<ECDSA-P256 over (root || epoch || publishedAt)>"
}

Two requirements:

• Bind the signature to the same key the verifier trusts for the credential, or document a separate revocation key with its own rotation policy and trust list.
• Make older roots discoverable. Verifiers may accept proofs against any root not older than a published "valid window" $\Delta$. Wallets need to know which roots are still acceptable.

3. Distribute witness updates

After publishing $R_t$, every wallet that holds a non-revoked credential needs an updated witness against $R_t$. Three practical models:

Model	How wallets fetch witnesses	Privacy of fetch
Pull-by-prefix	Wallet downloads the slice of the tree containing its identifier.	Leaks a few bits of identifier (the prefix). Mitigated with oblivious-RAM-style tricks or padding.
Pull-by-leaf	Wallet downloads the exact witness for its identifier.	Identifier is leaked to the CDN. Acceptable only if CDN ≠ verifier and rotates aggressively.
Push-all	Issuer publishes the entire updated tree; wallets recompute their witness locally.	Best privacy, highest bandwidth. Viable when $

Whichever model is chosen, the channel must be authenticated (TLS with pinned CA, or an issuer-signed bundle) so a network attacker cannot serve stale or forged roots.

4. Key rotation and incident response

Plan for revoking the revocation key. The same scheme the issuer uses for credential key rotation applies, but with a stricter SLO: a compromised revocation key lets an attacker delist arbitrary credentials. Recommended controls:

• Separate HSM for revocation signing.
• Short epoch interval so the maximum window of trust in a key is bounded.
• Public log of root publications (e.g. an append-only transparency log) so the wallet can audit that no two conflicting roots were issued for the same epoch.

Today

Until any of the above ships, OpenAC issuers operate exactly as today: SD-JWT issuance, ECDSA P-256, no in-circuit revocation. Wallets and verifiers use the out_of_band scenario and accept the linkability cost.

The eventual API shapes (URL conventions, witness format, signature envelope) will be specified in the Implementation profile.