Issuer-Holder-Verifier triangle

Every Verifiable Credential system has exactly three roles, and naming them clearly is most of what makes the model easy to reason about:

• Issuer, checks a fact and signs a credential asserting it. A government issuing a passport; a bank running KYC; Solidus Verify running an identity check.
• Holder: the party the credential is about, who keeps it and decides when and to whom to show it. Usually, but not always, the same person as the credential's subject.
• Verifier, receives a presentation of the credential and checks it's genuine, current, and unrevoked, without needing to contact the issuer.

It's drawn as a triangle rather than a straight line for a reason: the issuer and the verifier never have to talk to each other. The holder sits in the middle, carrying proof between two parties who may never interact directly. That's what makes a credential portable, issued once, checked by anyone, for as long as it's valid.

That portability is the entire commercial bet behind Solidus Verify. The industry norm is that every relying party re-runs its own KYC check from zero, on every new user, forever. The triangle says that doesn't have to be true: issue once, hold it, present it to the second, third, and Nth verifier without redoing the work. Solidus is built to be the issuer, not a verifier, portability is the product.

Where it comes from

The roles themselves, issuer, holder, verifier, subject, are formally defined in the W3C Verifiable Credentials Data Model (see Verifiable Credential). The triangle diagram is not a W3C artifact; it's a widely reused teaching device out of the self-sovereign identity community: Sovrin Foundation and Hyperledger Indy material did much of the early popularizing, and nearly every SSI project since has redrawn its own version, Solidus included.

Solidus status

Shipped, but honestly partial. The code path for all three roles works on the live testnet: Verify issues, the identity dashboard holds and lets a user present with selective disclosure, and the SDK's verification logic checks a presentation correctly. What doesn't exist yet is a real second relying party, an organization with no relationship to Solidus, in production, actually accepting a reused credential instead of running its own check. That is the load-bearing assumption behind the whole triangle, and today it is unproven: it's a trust-network problem, not a cryptography one, and Solidus has no paying customer to point to yet.

Proof you can run yourself: the full loop, issue, hold, present, verify independently of the issuer, is runnable today against the live testnet. Solidus's credential-flow developer guide walks through exactly this with real code.