Credential Portability: Why the Verification You Already Did Should Travel

The unlinkability implementation described here is unaudited.

An issuer signs a credential once; you keep it and show it again wherever it's asked for.

That's the difference worth naming. "I verified my identity once" sounds like it should mean the same thing everywhere, but usually it doesn't, most services check you, keep the result on their own server, and make you start over the moment you're somewhere else. The distinction here is who holds the outcome afterward. Once an issuer signs a credential, you hold it, not the company that ran the check, not a database you can't see into. What you show to the next relying party is a cryptographic presentation of something you already possess, not a repeat of the original check.

The mechanism, in three steps

An issuer signs it once. In the flow this page describes, that issuer is verify.solidus.network, the place identity verification actually happens. This page isn't where that job gets sold or explained; if you're evaluating the verification step itself, that's the right place to look. Here, the credential already exists and has already been signed.

The holder keeps it. This wallet is the holder, full stop, never the issuer, never the verifier. It stores the credential client-side and is the thing that makes the next step possible. Issuer, holder, and verifier are the three roles of the Issuer-Holder-Verifier triangle, and this page won't re-teach that model, for the full three-role picture and how each side checks the others, see what a verifiable credential wallet is.

The holder re-presents it, selectively, each time. Every relying party gets its own presentation, generated fresh, revealing only the claims it asked for. You can see the shape of the guarantee for yourself, the demo ships in the published package:

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

Its own output prints the honesty boundary along with the result: two independent presentations verify correctly, and the pooled correlation surface across them contains only cohort-level constants and the claims each relying party actually requested, not enough to link the two appearances back to one person. The same output is explicit that this is presentation-layer only: it says nothing about IP address correlation, timing correlation, device fingerprinting, or two relying parties pooling data out of band.

What "portable" means for a wallet specifically

Without this, two things tend to happen. Either you re-do the underlying check at every relying party that asks, filling out the same form, uploading the same document, waiting on the same review, again, or you hand over a copy of the full document itself, over-sharing information nobody asked for just because that's the only unit you have to give. Both cost you time or privacy you didn't need to spend.

With it, neither happens. The issuer isn't back in the loop for the second relying party, the third, or the tenth: it signed once and its job is done. You control what gets re-presented and to whom, one presentation at a time, each revealing only what was asked. That's the entire value of holding the credential somewhere durable instead of leaving the result sitting inside the issuer's own system.

This is also why "portable" is the right word and not "shared" or "synced." Nothing is being copied to a common pool that multiple parties draw from, and no central party is granting access on your behalf. The credential sits in one place, this wallet, and what moves outward each time is a fresh, purpose-built presentation of it, not the credential itself. A relying party that receives one learns exactly what it asked to learn and nothing else; it doesn't get a durable copy it can pass along or correlate against later without your involvement.

What this page is not claiming

It would be easy to read the above as "credentials from any issuer flow freely between any wallets and any verifiers": that ecosystem doesn't exist yet, and this page isn't claiming it does. The one real, describable flow today is Solidus Verify issuing a credential and this wallet holding and re-presenting it. There's no live multi-issuer marketplace, no interoperability proof against other wallets, and no claim that this pattern already works across vendors.

Where this goes next

The commercial and cost side of the first step, what verification itself involves, what it's for, who runs it, belongs to verify.solidus.network, not here. This page's job was the concept: what a credential does once it's signed, and why holding it yourself changes what happens next. For the fuller definition of the term this page is a worked example of, see the Credential Portability entry in the Lexicon. This wallet's flow is the concrete, checkable case referenced there.