Skip to content

Credential Veil

Anonymous credentials · BBS selective disclosure

Signs one six-field credential with BBS over BLS12-381, then lets you reveal any subset of fields — or just prove you're over 18 — while the verifier checks a proof that never contains the signature or the hidden fields.

What is this?

A signed credential — a driver's license, a JWT, a mobile ID — is an all-or-nothing artifact: to prove one field, you hand over the whole document and the signature that binds it. BBS signatures break that. The issuer signs the six fields once; the holder can then prove, as many times as they like, that a valid signature exists over any subset of fields they choose to reveal — without ever showing the signature itself. Standard BBS protects the proof value from being used to identify which credential produced it, even by colluding issuers and verifiers. Revealed values and other context can still identify you. Exhibit 3 illustrates proof randomization and measures repeated disclosures; it does not prove unlinkability.

Honest scope: this is a teaching demo, not production crypto. The BBS signatures, proofs, pairings, Ed25519 baseline and the custom age range-proof on this page are all real and run in your browser. The BBS core is checked against publisher fixtures; the custom age proof has separate teaching tests. The credential data, issuer, and wallet are stage props: keys live only in this tab's memory. What this page does not prove: that a real deployment is private. Identifying disclosures, distinctive headers or issuer keys, revocation handles, and network metadata can still enable tracking, including by colluding issuers and verifiers.

Our BBS SHA-256 baseline is checked against draft-13 (13 October 2026) and matching versioned publisher test vectors. The draft remains work in progress. See the review and validation scope. These checks do not validate this lab’s custom age proof or browser side channels.

The credential

One issuer, one credential, six fields. Everything below uses this exact credential — signed once with BBS over BLS12-381 and once with Ed25519 for comparison.

Generating issuer keys…

1 · The problem: all-or-nothing disclosure

This is what a signed JWT or mobile driver's license does today. The credential is Ed25519-signed as one blob. Try to prove just one thing — that you're over 18 — and watch what the verifier actually receives.

2 · Selective disclosure — the headline

Same credential, BBS-signed. Check exactly the fields you want the verifier to see, then step through what actually happens. The hidden fields aren't blacked out on the verifier's side — they're absent. The signature never leaves your wallet.

Fields to reveal

    Present the same credential three times, revealing the same field. Compare the randomized BBS proof bytes with the repeated Ed25519 signature. Different bytes illustrate randomization; they do not prove unlinkability.

    BBS draft-13 §§3.3.7 and 5 (13 October 2026) clarify that the standard proof-value guarantee covers issuer–verifier collusion. Disclosed values and identifying context remain correlatable. Our BBS core is checked against draft-13. These checks do not validate the custom age proof below.

    Issuing a signature is different from showing it

    CoreSign here is deterministic for a fixed key, signed tuple and header/domain. Issuing a changed tuple creates a new artifact; repeating the same issuance reproduces the same signature. The buttons above rerandomize proof presentations of one already-issued credential, without contacting the issuer.

    Concrete BBS security (ASIACRYPT 2025; revised 22 October 2025) gives q-dependent issuer-key recovery costs: q describes signature exposure, not presentation count. Tight BBS security (EUROCRYPT 2026; revised 20 February 2026) distinguishes deterministic / once-per-message issuance from multiple randomized signatures of one message. Its proof-tightness limitation is not an exploit.

    4 · Predicate proof: "over 18" without a birth date

    The credential's date of birth is signed as its day count, so the holder can prove DOB ≤ cutoff with a bit-decomposition range proof linked into the BBS proof — the verifier learns exactly one bit. Bulletproofs make the same statement logarithmically smaller; this lab uses the inspectable O(n) construction and links the sibling for the efficient one.

    5 · Revocation — the honest tension

    Revocation needs the verifier to check something about this credential — and anything checkable is potentially correlatable. Below is a status list: one published bit per issued credential. It works. Look at what it costs.

    The tradeoff, stated plainly: showing the verifier your index (#17) at every presentation restores exactly the correlation handle the BBS proof removed. Cryptographic accumulators can prove "my bit is 0" in zero knowledge, repairing this — that machinery is out of scope here and the tension is not solved by the status list you just used.

    The three revocation designs, and what each one costs
    Approach How it works Verifier learns The cost
    Status list (this exhibit) Issuer publishes one bit per credential; verifier reads bit i Your stable index i, forever Unlinkability is gone — the index re-links every presentation the crypto just unlinked
    Issuer-online check Verifier (or holder) asks the issuer "is this one still good?" per presentation Nothing extra — but the issuer sees every place the credential is used Trades verifier correlation for an issuer who can log, profile, or veto every showing; issuer availability becomes a liveness dependency
    ZK accumulator membership Issuer maintains a cryptographic accumulator of non-revoked credentials; holder proves membership in zero knowledge inside the presentation One bit: "not revoked", with no index and no callback Real machinery — pairing-based accumulators with per-epoch witness updates every holder must fetch (a fetch pattern that itself needs care, e.g. via PIR or broadcast), plus more prover time

    What a privacy-preserving deployment would actually require, in one breath: an accumulator commitment in each epoch's issuer bulletin, a membership witness per credential that updates when anyone is revoked, a ZK proof of that witness linked into the BBS presentation the same way this lab links its age predicate — and a story for how holders fetch witness updates without the fetch itself becoming the tracking signal. Each piece exists in the literature; the honest point of this exhibit is that none of them is free, and a deployment that skips them silently lands back on this page's status list.

    What hides what, from whom

    On the name: this lab implements the scheme in draft-irtf-cfrg-bbs-signatures, which the draft calls plain BBS — its signature is the pair (A, e). BBS+ is a distinct scheme: the Au–Susilo–Mu variant (Constant-Size Dynamic k-TAA, SCN 2006), whose signature carries an extra blinding scalar, (A, e, s). The two are often conflated; this page means the former throughout.

    Scheme Issuer sees at issuance Verifier sees at showing Showings linkable? Reveal a subset?
    Plain JWT / mDL (this page's baseline) All fields All fields + the signature Yes — identical signature every time No
    BBS (this lab) All fields Chosen fields + a fresh proof No, at the crypto layer Yes — any subset, plus predicates
    Blind signatures (blind-sign) Nothing — signs blind The whole token + signature Not to the signer; verifier sees a stable token No — still all-or-nothing at showing
    Ring signatures (ring-sign) n/a — self-signed among a set The message + which ring Scheme-dependent (linkable variants exist) No — hides who, not what
    What this lab is not
    • Not a pairing lab — the BLS12-381 pairing is consumed as a primitive; see pairing-gate for the map e(P,Q) itself.
    • Not a blind-signature lab — there the signer is blind at issuance; here the issuer sees everything and the verifier is blind at showing. See blind-sign.
    • Not a range-proof lab — the age proof uses inspectable bit commitments; for the logarithmic-size construction see bulletproofs.
    • No Idemix / CL-signature build-out — BBS descends from Boneh–Boyen–Shacham group signatures via Camenisch–Drijvers–Lehmann; the RSA-based CL lineage solved the same problem a decade earlier.
    • No W3C Verifiable Credentials / SD-JWT wire formats and no DID/wallet ecosystem — the crypto is the subject, not the serialization.