@mintid-net/holder — the holder in WebAssembly

What the host injects, what the module never does

The surface

import { Holder, mintToken, submitSelfRevocation, staticVerifierKeys, type Transport } from "@mintid-net/holder";

const holder = await Holder.issue(offer, { transport, verifiers });        // identity credential, the OpenID4VCI holder half
const bytes  = holder.storageBytes();                                       // Uint8Array: the custody record (contains the link secret)
const again  = Holder.fromStorage(bytes, { transport, verifiers });
await holder.refreshWitness();                                              // adopts the issuer's current definition + witness; self-checked
const env    = await holder.present(challenge, { expectedOrigin });         // {proof_hex, issuer_id, status_root, claimed_predicates}
const mintp  = holder.presentForMint(gradeMin, mintChallenge, { ageOver }); // the one presentation that discloses status_ref, to the issuer only
const mat    = await mintToken(offer, holder, { transport });               // MintMaterial, JSON-ready
const msg    = await holder.selfRevoke(chainId);                            // {message (five fields), nullifier, ciphertext}; the holder refuses to present from now on
const rcpt   = await submitSelfRevocation(relayUrl, msg, { transport, chain: rpcUrl }); // "submitted" until the chain shows it
holder.info();                                                              // issuer, grade, validity, witness state; never the secret

The storage-bytes rule. storageBytes() is the custody encoding of the holder library: byte for byte what the Python Holder.storage_bytes(), the Go binding and the mintid-holder process write, and any of them loads what this package writes (version 1 for a live identity credential, version 3 once it self-revoked). The tests replay records written by the Python binding and, live, have Python load records this package wrote. It contains the link secret: encrypt it before it leaves the page, under a key the host derives (a passkey's PRF output, for example); a ciphertext the service cannot open is not custody.

Verifier keys. staticVerifierKeys(records) pins records the host trusts (records it proved itself, or its trusted-verifier list). provenVerifierKeys(reader) is a fail-closed adapter over a reader the host provides — getVerifier(verifierIdHex) resolving only to a record proven against a header it trusts (as verifier-core's ChainClient does in Python). This package carries no light client, so in a browser the proven read is the host's to supply; until it has one, staticVerifierKeys with records proven elsewhere is the alternative. Without either, the holder presents nothing.

The challenge rule and the refusals

present refuses, building nothing and sending nothing, in this order: the self-revoked holder (credential_self_revoked); the request-signature rule — challenge_unsigned, challenge_key_unavailable, challenge_verifier_not_active, challenge_key_unknown, challenge_key_not_active, challenge_signature_invalid (the six of challenge-signature-v1, in their order); the exact origin (challenge_origin_mismatch: the request's audience is not expectedOrigin); the profile (challenge_profile_mismatch); the deadline (challenge_expired: now ≥ expires_at); one answer per challenge (challenge_replayed, remembered in memory for the life of the Holder). Then the proof: a policy the credential cannot satisfy is policy_unsatisfiable:<output key>.

Every refusal is a HolderError {code, step} (step: the operation or the network step — metadata, token, credential, witness, present, present_for_mint, verifier_keys, self_revoke, relay, chain, storage, module). Its message is "<step>: <code>" and never carries a value. The closed vocabulary (HOLDER_ERROR_CODES):

module_trapped: WebAssembly aborts on a panic, so the proof core's malformed-input guards, which catch an unwind natively, cannot catch it here; a hostile byte string that would be refused natively traps the instance instead. The package then refuses every later call; the host reloads the page (or the worker) and restores the holder from its custody record.

Prove time

A presentation has 10 seconds (SPEC-1): the verifier's challenge expires 10 seconds after it was issued, and in that window the page fetches the challenge, the module builds the proof and the page submits it. The proof's share depends on the device's CPU.

How MintID measures it. npm run bench:browser -- 5 1,4,6 (tests/browser/bench.mjs): headless Chrome; for each CPU factor a fresh tab, slowed through the DevTools protocol (Emulation.setCPUThrottlingRate) before the page loads; holder-v1's A3 credential with the launch identity policy (grade ≥ A3, age over 18, active, unexpired), a fresh holder each run; five runs each, the figure is the median of the four warm runs (the first is the engine's cold call), timed around the module call, no network. The CPU factor is the reference for slower devices: 1× is a recent high-end laptop, 4× is MintID's proxy for a mid-range laptop, 6× for a slower device. It is a proxy, not a device: no physical mid-range device has been measured yet, and a page should rely on estimateProveMs() (below), which measures the device it runs on. npm run bench (tests/bench.mjs) times the same calls in Node.

Measured on an Apple M3 Max, headless Chrome 155, 18 October 2026:

(0.1.0: its sources rebuilt on the same machine; a measurement of the published 0.1.0 module on the same hardware agrees within 5 %.)

For comparison, the same machine proves natively (the Python binding) in 0.14 s and 0.09 s; selfRevoke takes about 50 ms in WebAssembly. Where the time went (0.1.0, profiled): the range proofs (bulletproofs) were about 85 % of a presentation, most of it their inner-product argument; the module's own check of the proof before it returns it about 9 %; the BBS signature proof and the VB20 non-revocation proof together about 4 %; the custody decoding under 1 %. Underneath, 90 % of the time was one function: blst's portable Montgomery multiplication (BLS12-381, 32-bit limbs), called with the limb count as an argument. 0.1.1 changes two things, and neither changes a proof — the same proof bytes from the same randomness:

• The build: the multiplication is inlined with the limb count known, the Rust is built with link-time optimisation, then wasm-opt. The same code and the same arithmetic, about 35 % less time.
• The range proofs' arithmetic: each round of the inner-product argument halves its generators with two-point products that the range-proof library computed with a general multi-scalar method costing about six times two plain scalar multiplications; the proof core's copy of the library (identity-proof-core/vendor/bulletproofs-bls) computes them as plain multiplications — the same points — and the range-proof generators are built once instead of for every proof and every check. About 2.8× less time again; natively too (0.37 s → 0.14 s).

At 4× an identity presentation now takes about 2.5 seconds.

Check before asking. estimateProveMs() builds one dry present and one dry presentForMint on a built-in test credential (holder-v1's A3, a test issuer no verifier accepts; no network, nothing kept) and returns their times in milliseconds. In the measurements above it was within 7 % of the warm median at every factor (mostly on the slow side). It costs what it measures, so run it once, while the page is idle — at load, in the Web Worker that will present — and keep the result for the session. Do not ask a person to approve a presentation the device cannot deliver in time: when the estimate plus the page's network margin exceeds the window, say so instead of asking.

import { estimateProveMs, PRESENTATION_WINDOW_MS } from "@mintid-net/holder";

// The page's own margin: the challenge fetch, the submission and clock skew.
// On the public testnet the part of challenge-to-decision that was not the
// proof took 2.0 s and 3.3 s (the two runs below); 3 s is a reasonable start.
const NETWORK_MARGIN_MS = 3_000;

const estimate = await estimateProveMs();              // { present, presentForMint } in ms
const canPresent = estimate.present + NETWORK_MARGIN_MS <= PRESENTATION_WINDOW_MS;
// canPresent false → do not offer the approval on this device; say why.
// The issuer's mint challenge has the same 10-second window: compare presentForMint the same way.

With 0.1.1 and a 3-second margin, every row above fits the window: the 4× row with about 4.5 seconds to spare (2.5 s + 3 s), the 6× row with about 3 (3.8 s + 3 s). A device slower than that still exists — check with the estimate rather than assume. Design the flow to spend nothing inside the window it does not need: approve first, then fetch the challenge, then present at once; run the module in a Web Worker so the page stays responsive. On the public testnet (17 October 2026, two runs from Node, module 0.1.0): issuance 1.5 s, present 4.3 s and 3.2 s, challenge to the verifier's decision 6.3 s and 6.5 s, accepted both times.

The self-revocation prover runs in WebAssembly (about 0.1 s): the testnet journey built it, the relay submitted it and the holder's own node read confirmed it.