Where Do Your Verifiable Credentials Actually Live?
This page is about one narrow question: after a credential is issued, where does the holder keep it? It is not about who issues a credential or why: that is a separate question, answered elsewhere, and this page will not wander into it. The Issuer-Holder-Verifier triangle names the three roles in any Verifiable Credential system: an issuer checks a fact and signs it, a holder keeps the credential and decides when to show it, a verifier checks it's genuine without calling the issuer back. That triangle is standards vocabulary, defined by the W3C Verifiable Credentials Data Model, drawn as a diagram popularized by the self-sovereign-identity community (Sovrin Foundation and Hyperledger Indy material did much of the early teaching), not invented by Solidus. This page sits entirely on the holder's leg of it: given a credential you now hold, where does it actually rest?
Three resting places, one unresolved question
A Verifiable Credential is a signed statement, so in principle it can sit anywhere bytes can sit. In practice, the field has converged on three real candidates, and none of them has won.
A wallet. The credential lives on a device the holder controls directly, a phone app, a browser extension, a hardware key. Presentation is fast: the holder already has the bytes, so proving possession is a local operation, not a network round trip. The cost is availability. A wallet-held credential is only as reachable as that one device. Lose the phone, and, depending on backup design: you may lose the credential along with it, or at minimum lose the ability to present it until you recover access. A wallet also raises the question of what happens across devices: presenting the same credential from a second phone usually means re-provisioning it, not simply logging in somewhere.
A personal data pod. The credential lives on a server the holder has designated as their own, a pod, reachable over the network rather than bound to one device. This solves the wallet's single-device problem: the credential is available from anywhere the holder can authenticate, not just from whichever phone happens to be nearby. The cost moves elsewhere, to operations. A pod is a server, and a server has to be run by someone: kept online, patched, backed up. If the holder runs it themselves, they've taken on an availability obligation a wallet doesn't impose. If a third party runs it on the holder's behalf, the holder has introduced a dependency on that operator staying up and staying honest about who else can read the data, governed, in Solid's architecture, by WAC/ACL rules sitting next to the resource itself.
The issuer's own database. The credential never really leaves the issuer; what the holder gets is a pointer, or a session, that lets a verifier check with the issuer directly. This is the default today, in the sense that most current identity checks work exactly this way, a bank or a KYC vendor keeps its own record and answers "yes, this person passed" when asked. It is worth naming the tension here plainly, because it undercuts the appeal of the other two options: if a verifier still has to contact the issuer to confirm a credential, the credential has not actually made anyone independent of the issuer. The entire reason the Issuer-Holder-Verifier triangle separates the issuer and verifier roles is so they don't have to talk to each other, a credential that routes back to the issuer on every check collapses the triangle back into a straight line.
None of these three is free of a real cost, and none is presented here as the answer. A wallet trades availability for speed and self-custody. A pod trades an operational burden for network-reachable availability. An issuer database trades genuine independence for the convenience of storing nothing at all.
Why this is still unsettled
This is not a gap in tooling that will close with the next release. Even the identity systems with the deepest institutional deployment behind them haven't converged on one answer. Solid's own production history (the BBC, the UK's NHS, and the Flanders regional government have all run real Solid deployments) is built around pods holding documents, governed by WAC/ACL, and Solid never adopted the Verifiable Credential data model as a first-class concept in the first place; a Solid pod answers "who may access this resource," not "who issued this claim about me." Systems built around wallets optimize for local, offline-first presentation and generally accept the device-loss risk as a tradeoff worth making. Systems that lean on the issuer's own database are usually not trying to solve portability at all: they're the pre-portability default, still answering "call us and we'll tell you," which is the exact behavior a portable credential is meant to replace. No consensus has formed, and this page isn't going to manufacture one where the field hasn't.
Where portability fits, without redefining it
The reason this question matters at all is Credential Portability, the property that lets a check performed once be reused elsewhere without repeating it. This page doesn't own that term or redefine it; it only names where a portable credential can be held once it exists. Wherever the credential rests, wallet, pod, or issuer record: the same three requirements from that term still apply: the credential has to be independently verifiable, selectively disclosable, and backed by a way for a verifier to trust the issuer in the first place. Custody location doesn't solve any of those three; it only decides who bears the availability cost of keeping the bytes reachable.
This page also isn't the place to compare KYC vendors, price a pod deployment, or argue for Solidus's own products by name, that's a different page, on a different surface, answering a different question. If a future edit of this page starts doing any of that, it has drifted; the first paragraph above is the check against that drift, not just the closing note.
What's actually running today
That's one data point in the wallet-versus-pod-versus-issuer-database question this page describes, not a resolution of it. Readers who want the pod option explained on its own terms, separate from this comparison, can start with What Is a Personal Data Pod?