How a Solidus verification feels

The unlinkability implementation described here is unaudited.

Every later relying party checks a signature instead of re-running the document check. Here is exactly what happens, and why the missing callback line is the argument, not a marketing flourish.

The mechanism: issuer, holder, verifier, and no line back

Three roles, formally named in the Issuer–Holder–Verifier triangle:

• Solidus Verify issues. It runs the identity check once, document read, liveness, whatever the relying party's policy requires, and signs the verified result into a Verifiable Credential.
• The user holds. The credential lands in their own wallet, not in a Solidus record keyed to that one relying party. It's theirs to keep and present again, at any later service that accepts it.
• The next relying party verifies. It checks the issuer's signature and the holder's proof of control over the credential. It does not call Solidus to confirm anything, and it does not re-collect or re-check the original document.

That absence is the mechanism, not a footnote to it: no callback. The diagram this page pairs with draws that line severed, not dotted: there is no path from verifier back to issuer at check time. Resolving the signature does touch Solidus's chain once, to fetch the signing key behind a did:solidus identifier; the consensus and validator machinery underneath that lookup is the network's story, covered at solidus.network/protocol, not this page's.

One thing this mechanism does not do: discharge a relying party's own regulatory KYC obligation. Reuse is convenience and cost: the compliance decision, and the liability for it, stays with whoever is doing the relying.

The standards underneath, named precisely

• The credential itself follows the VC Data Model 2.0, a real W3C spec, not a house format.
• The identifier is did:solidus, registered in the W3C DID Method Registry, pull request #713, merged 2026-07-04 (curl -s https://api.github.com/repos/w3c/did-extensions/pulls/713 | jq '{state,merged,merged_at}' returns exactly that). A registry listing, not a W3C standard or endorsement: the standard is DID Core, which Solidus didn't write. did:solidus identifiers exist
• Presentation can use BBS+ signatures for selective disclosure, unaudited, with an audit targeted H2 2026 via an NLnet NGI Zero grant not yet awarded, to reveal, say, "over 18" without the birthdate underneath it. Until that audit runs, "unlinkable" describes what the design intends, not a verified property of the code doing the signing.

What actually happens, end to end

1. Capture, the relying party's flow collects a document photo and a liveness check. Captures are stored in object storage under a retention policy, not indefinitely and not "never": document images purge automatically after 30 days by default, session recordings after 365, and that purge job runs daily in production today. Full data-handling detail lives on /security, not here.
2. Issuance, Solidus signs the verified attributes into a VC 2.0 credential bound to a did:solidus identifier.
3. Wallet storage: the credential goes to the holder's own wallet, not a per-relying-party record on Solidus's servers.
4. Presentation, at the next relying party, the holder presents the credential, optionally disclosing only the claim asked for via BBS+ signatures.
5. Verification, the relying party checks the signature and resolves the did:solidus identifier against its chain. No callback, no re-collected document.

Where to go next

• /reusable-credential, the modeled unit economics of reuse, math shown, not a bare number.
• /docs/quickstart, issue and verify a credential yourself, as a developer.
• /security, the full and dated table of what is held today and what is not: no external audit, no SOC 2 / ISO / eIDAS yet.

The one thing on this page you can independently check today is the DID registry receipt above, run the curl yourself. Everything about BBS+ unlinkability is a design claim until the audit runs; to see it work rather than take our word, run the unlinkability demo, a separate page, with its own runnable proof, that this one only describes.