What Are Verifiable Credentials?
There is a document almost everyone carries that solves a problem we have collectively failed to solve digitally for over three decades. Your passport. Hand it to a border agent in Zurich, Tokyo, or São Paulo. The agent inspects it, checks the photograph, verifies the issuing authority’s security features, and hands it back. No phone call to your government. No real-time database query. The document itself carries the proof.
Now try the same thing online.
You log in to a website. That website confirms you know a password, or that you control a particular email address. But it cannot confirm that you are a licensed physician. Or a certified financial adviser. Or an authorised representative of a specific institution. For that, it has to call an external service, check a central registry, or ask you to upload a document that a human will review three days later.
Verifiable credentials are the digital passport. A structured, cryptographically signed assertion about who you are or what you are authorised to do — issued by an authority both you and the verifier trust, and checkable without calling anyone.
The concept is not new. What is new is that we finally have the cryptographic infrastructure to make it work at institutional scale without recreating the very dependencies the concept was meant to eliminate.
Three Roles, One Triangle
The model rests on three actors — and the relationship between them is what makes the whole thing work.
The issuer creates the credential. A medical board certifies a physician. A university grants a degree. An employer confirms an institutional role. The issuer signs the credential with a cryptographic key. That signature is the digital equivalent of the embossed stamp on your passport — it can be verified by anyone who knows the issuer’s public key, and it cannot be forged.
The holder is the person or organisation the credential describes. Holders store credentials in a wallet, an application, or institutional infrastructure. The critical difference from traditional systems: the holder decides when and with whom to share. In a database model, the issuer controls access. In a credential model, the subject does. This is not a philosophical preference. It is an architectural choice with direct implications for data minimisation, privacy regulation, and operational independence.
The verifier is whoever needs to check. A hospital admissions system. A pharmacy. A financial compliance platform. A border control application. The verifier does not contact the issuer. It checks the cryptographic signature against the issuer’s public key — a process that takes milliseconds, works offline, and leaks nothing back to the issuer about when or where the credential was presented.
This triangle is not a login. It is a trust relationship. And the distinction is structural, not semantic.
Why This Matters More Than Better Passwords
Standard login systems — OAuth, SAML, and the protocols layered on top of them — are session mechanisms. They confirm you have the right to access a particular system at a particular moment. They are not designed to carry durable assertions about who you are across institutional boundaries.
OAuth works well within a single domain. A user authenticates with an identity provider, gets a token, accesses services. But the moment you cross from one institution to another, OAuth runs into a structural limitation: it assumes the party issuing the token is the party relying on it. Institution A’s tokens mean nothing to Institution B unless they have negotiated a federation agreement first. When you need ten institutions to interoperate, you need up to 45 bilateral trust agreements. At a hundred institutions, it becomes 4,950.
So what actually happens? Everyone converges on a central identity provider — Google, Microsoft, Okta — and the “federation” becomes a hub-and-spoke dependency. The decentralisation was theoretical. The centralisation is real.
Certificate-based systems face a different version of the same problem. Traditional PKI can confirm that a server is authentic. It can even confirm that an individual holds a specific certificate. But the structural weakness is not scale — OS-shipped root certificate stores handle that reasonably well. The structural weakness is trust delegation. Every certificate authority is a third party that can be compromised, coerced by a government, or simply fail. DigiNotar proved this in 2011. And today, Let’s Encrypt alone holds roughly 60% market share for TLS certificates — a single US institution that is a structural single point of failure for internet transport security.
Verifiable credentials solve this differently. Instead of routing trust through a central authority, each entity maintains its own cryptographic identity. Verification is direct: the verifier reads the issuer’s public key material and checks the signature. No intermediary, no bilateral negotiation, no single point of failure whose compromise invalidates everything it ever signed.
Selective Disclosure: Show Only What Is Needed
A credential is issued once and presented many times. But presenting a credential does not mean sharing everything in it.
A pharmacy needs to know that a prescriber holds a valid practitioner registration. It does not need the prescriber’s employer, graduation date, or continuing education record. Selective disclosure means the holder shares only the attributes the verifier requests — and the verifier confirms only what it asked for.
This is not a privacy feature bolted on after the fact. It is an architectural property of the credential format itself. The implications for compliance are significant: in any jurisdiction with data minimisation requirements — GDPR, the Swiss Data Protection Act, HIPAA — the credential model is structurally aligned with the law rather than fighting against it.
From Specification to Production
Verifiable credentials are not a whiteboard concept waiting for someone to build them. They are in production.
In Swiss healthcare, SEAL — the starting point of Vereign’s communication layer on Stargate — carries over 800,000 encrypted messages per month between more than 30,000 medical practices. Every message processed through this infrastructure carries verifiable assertions about the sender’s identity and professional authorisation. The receiving party — a hospital records system, a specialist clinic, a pharmacy — verifies those assertions independently. No central registry queried. No trust intermediary consulted.
The trust architecture underpinning this uses Decentralized Key Management (DKMS) — a design principle where each entity maintains its own cryptographic identifier anchored to an append-only key event log. Think of it as putting the Certificate Authority at the edge: every organisation becomes its own trust anchor, and any counterparty can verify that trust by reading the cryptographic record directly. No shared CA required. No bilateral negotiation. No single point of failure.
The key management is designed for operational resilience: if a key is compromised, the entity rotates to pre-committed replacement keys without changing its identifier. The trust relationship survives key compromise — something traditional certificate systems cannot do without re-issuing every credential from scratch.
What Makes a Credential “Verifiable”
The word does specific technical work. A credential is verifiable when three conditions hold:
- Signature verification. The issuer’s cryptographic signature can be confirmed against a public key that the verifier trusts or can discover through a trusted resolution process
- Tamper evidence. Any modification to the credential after issuance breaks the signature — the verifier detects it immediately
- Revocation checking. The issuer can publish revocation information without revealing which specific credentials have been revoked, protecting holder privacy even in the revocation process
These three properties are what separate a verifiable credential from a self-asserted claim. Anyone can put a job title in an email signature. Only a trusted issuer can produce a signed, non-repudiable credential that a third party can independently confirm — and that the holder controls.
The Real Question
The legacy model of digital identity — a provider holds your data, you authenticate to that provider — served the early internet adequately. It does not serve environments where multiple institutions need to trust each other’s assertions about people, roles, and authorisations without surrendering control to a shared intermediary.
Verifiable credentials represent a different architecture. Identity assertions are held by the subject. Issued by appropriate authorities. Verifiable by any party that trusts those authorities. Without intermediaries. Without central bottlenecks. Without the privacy implications of centralised data stores.
The technology is deployed. The standards are maturing. The production numbers are growing. The question for any regulated organisation is no longer whether verifiable credentials work — but what happens to those who wait while their peers build trust infrastructure that actually delivers cryptographic proof instead of asking everyone to just take their word for it.
