Selective disclosure for AI agents: what BBS+ proves without revealing

The unlinkability implementation described here is unaudited.

Keep that in view for every claim that follows, it doesn't get less true two paragraphs down.

With that stated, here's the problem BBS+ actually solves for an agent.

The problem: proving one thing without proving everything

An AI agent that acts on someone else's behalf, placing orders, calling paid APIs, hiring other agents, regularly needs to prove something to a relying party without handing over its entire credential file. "This agent's operator is KYC'd." "This agent is authorized to spend up to $500." "This agent belongs to a registered fleet." Each of those is one fact buried inside a larger signed document, and an ordinary signature doesn't let you extract one fact cleanly: it only verifies against the exact bytes it was computed over. Hand over one field, and you've either forged something or handed over the whole document.

BBS+ signs a vector of separate messages under a single signature, and lets the holder, not the issuer, derive a fresh, single-use proof at presentation time that reveals only the subset of messages the holder chooses. The rest stay provably signed but never leave the holder's machine. That's selective disclosure. The second property, which is where the interesting engineering lives, is unlinkability by design: because each presentation is a newly generated zero-knowledge proof rather than a copy of the original signature bytes, two presentations of the same credential to two different relying parties share nothing a verifier could use to tie them back to each other or to the original signing event, provided the implementation is correct. That "provided" is doing real work, and it's why the first paragraph of this page exists.

Where it comes from

Solidus didn't invent any of this. 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 from Man Ho Au, Willy Susilo, and Yi Mu in 2006. The interoperable wire format, the part implementations actually need to agree on to talk to each other, comes out of ongoing IETF and W3C/DIF BBS Cryptosuite specification work. It's two decades of peer-reviewed public-key cryptography, built on the same BLS12-381 pairing-friendly curve used for BLS signatures. @solidus-network/bbs implements that specification; Solidus authored the packaging, not the math.

How Solidus uses it for an agent

When an agent gets a passport, a did:solidus identity anchored to an ERC-8004 token on Base Sepolia: it can also be issued a BBS+ capability credential alongside it. That credential can carry a vector of claims: the operator's KYC status, a spend ceiling, a fleet membership, whatever a relying party needs to check before it will transact with the agent. At presentation time, the agent reveals only the claim in question. The clearest live example is operator KYC linkage: an operator gets verified once, and the agent can later prove "my operator is KYC'd" to a relying party without that relying party ever seeing the operator's underlying identity documents, name, or nationality, those stay inside the credential, unrevealed and still validly signed.

The proof

Run this yourself, don't take the claim above on faith:

npm i @solidus-network/auth @solidus-network/bbs
node node_modules/@solidus-network/auth/demo/unlinkability-demo.mjs

This issues one credential, presents it to two separate relying parties, verifies both presentations independently, and prints exactly what a colluding pair of relying parties would see if they pooled notes afterward. The demo's full printed output, and a byte-by-byte reading of it, lives on the unlinkability page; the number worth carrying back here is its correlation check. Across 432 byte offsets compared between the two presentations, one matched, against a random baseline of roughly 1.7. The two proofs aren't just differently formatted; they're statistically close to independent draws, which is what "unlinkable by construction" is supposed to look like in practice, not just in the paper. For an agent presenting the same capability credential to many relying parties, that is the property that keeps those parties from linking its actions into a single profile.

The honesty boundary

Read the demo's printed output carefully and it draws a line around the claim, and this page draws the same line rather than pointing at the demo and stopping. What's unlinkable here is what travels inside the presentation envelope, the credential's own signature and the fields chosen for disclosure. That claim does not extend to the network carrying that envelope. Two relying parties can still correlate an agent across presentations by comparing IP addresses, request timing, TLS or device fingerprints, or by simply pooling out-of-band data they each already collected on their own (an email address, a phone number, a payment card). Solidus ships no Tor or mixnet transport, so network-layer privacy is a separate, unaddressed problem: the credential format was never meant to solve it, and claiming otherwise would be the fence violation, not an omission. Nobody outside Solidus has checked the implementation yet.

Where this evidence goes next

A BBS+ presentation that verified, the proof, the claims revealed, the moment it happened, is exactly the shape of evidence an ERC-8004 Validation Registry entry would need to record: a third party attesting that a specific agent action was checked and found valid. Solidus hasn't filled that registry slot yet, it's gated on the upstream standard publishing a Validation Registry contract address, but the credential format described here is built with that destination in mind.