BBS+ Signature

A BBS+ signature signs a list of messages at once, not one blob of data, and lets whoever holds it prove some of those messages to a verifier later, without handing over the whole signed list or reusing the same proof twice.

Start with what it replaces. An ordinary signature scheme (RSA, ECDSA, even the Ed25519 signature described elsewhere in this Lexicon) signs one fixed string of bytes. If an issuer signs "name: Aylin, birthdate: 1994-03-02, nationality: TR" as a single string, proving your age to a bar means handing over that whole string, name and nationality included, because the signature only verifies against the exact bytes it was computed over.

BBS+ signs a vector of separate messages under one signature, and (this is the actual invention) gives the holder a way to derive a brand-new, single-use zero-knowledge proof from that signature at presentation time. The proof says "I hold a valid BBS+ signature over N messages, and here is a subset of them, revealed", for whichever subset the holder picks, in the moment, not whichever subset the issuer picked at signing time. Two things fall out of that:

• Selective disclosure. The holder, not the issuer, decides at presentation time which fields to reveal. Prove you're over 21 without disclosing your birthdate or name.
• Unlinkability, by design. Because each presentation is a freshly generated zero-knowledge proof rather than a copy of the original signature bytes, two presentations of the same credential to two different verifiers share nothing a verifier could use to link them back to each other or to the original signing event, provided the implementation is correct.

Where it comes from

The base scheme, "BBS", was designed by Dan Boneh, Xavier Boyen, and Hovav Shacham in their 2004 paper "Short Group Signatures." The "+" extension that makes practical multi-message selective disclosure possible came two years later, from Man Ho Au, Willy Susilo, and Yi Mu (2006). The interoperable, standardized wire format, the thing implementations actually need to agree on to talk to each other, comes out of ongoing IETF and W3C/DIF BBS Cryptosuite specification work. Solidus designed none of this. It is decades-old, peer-reviewed public-key cryptography, built on the same pairing-friendly BLS12-381 elliptic curve used for BLS signatures (see that entry).

Solidus status

Solidus's BBS+ implementation is unaudited. State that before anything else, because every claim above about unlinkability is a claim about the design's intent, not a verified property of our code: nobody outside Solidus has checked it yet. An audit is targeted for the second half of 2026, contingent on an NLnet NGI Zero grant; it has not started.

What exists today: @solidus-network/bbs implements BBS+ signing, and @solidus-network/auth builds selective-disclosure credential presentation on top of it. This runs on Solidus's public testnet: there is no mainnet, and this credential format has not been used in a production KYC flow with a paying customer.

Proof you can run yourself: npm i @solidus-network/auth, the unlinkability demo ships inside the package tarball. It runs on your own machine; nothing requires trusting Solidus's servers to see the output.