Vendor Lock-In

Vendor lock-in is the cost, in money, time, or risk, of leaving a vendor once you've adopted it, beyond whatever the vendor's contract nominally allows. A buyer locked in isn't necessarily trapped by a legal clause; more often it's trapped by a proprietary data format, a workflow built around a specific API, or infrastructure a competitor's systems can't read, switching becomes expensive enough that "we could leave" and "we will leave" are different sentences.

Applied to identity verification specifically, the classic lock-in shape is the compliance record itself: an incumbent IDV vendor produces a check result the buyer holds, in that vendor's own format, tied to that vendor's own dashboard and API. Switching vendors doesn't just mean re-signing a contract: it usually means every existing customer's verification history stays behind, unreadable to the new vendor, and re-verifying an entire existing user base from zero is itself a real cost (see Re-verification Cost).

Where the "open format" counter-argument comes from

The W3C Verifiable Credentials Data Model was designed, in part, precisely to counter this: a credential in a standardized, published format, JSON-LD or JWT-based, is meant to be checkable by any conformant verifier, not just the one that issued it. In principle, that structurally weakens format lock-in: the record isn't trapped inside one vendor's proprietary schema.

Why that's only half the honest answer

An open credential format doesn't automatically mean an open credential system. Even a perfectly standards-compliant credential still needs somewhere to answer "is this issuer trustworthy" (a trust registry) and something to resolve its identifier against (a DID method and the network it lives on). If those two pieces are run by a single company, a buyer is still dependent on that company staying operational, priced fairly, and not degrading service, a real form of lock-in, just one level up the stack from record format. This is exactly Solidus's situation today: did:solidus resolves against Solidus's own testnet, and the one trust registry that exists is Solidus-operated (see Trust Registry, which names this centralization tradeoff itself, unprompted).

Solidus today

The format-level claim is real and checkable: Solidus issues SD-JWT VC-formatted credentials any conformant verifier, not just Solidus's own SDK, can check. The infrastructure-level claim is not yet true: there is one DID method (did:solidus), one chain (testnet, no mainnet), and one trust registry (Solidus-operated, not federated), and a buyer adopting Solidus today is dependent on all three continuing to exist and behave as advertised. Reducing that dependency, more validators, a federated or multi-operator registry model, is real, unstarted future work, not something this entry should imply is already solved.

See also

Trust Registry names the exact centralization this entry describes. Credential Portability is the format-level property that does hold up. Data Residency is a related, separately unresolved dependency question about where the underlying infrastructure physically runs.