What Are Verifiable Credentials? A Plain-Language Guide

Think about the last time someone asked to verify your age. You probably handed over your driving licence, which told them your name, address, date of birth, height, and several other details they had no reason to see. The person checking may have photographed it. The bar, the pharmacy, the online platform then stored a copy somewhere. You proved you were over 18, but you handed over a great deal more than that single fact.

Verifiable credentials change this. They let an authority sign a specific claim about you. You carry that claim. A verifier checks the signature and gets their answer. Nobody needs to phone the original authority. Nobody needs to store a copy of your whole record. The verifier learns exactly what they asked for: one fact, provably true.

This shift, from passing around copies and calling to verify, to carrying signed claims you can prove yourself, is what verifiable credentials make possible. If you work in a regulated industry in Europe and the term keeps turning up in briefings and compliance conversations, this is written for you.

A verifiable credential is a tamper-evident claim, signed at source by whoever holds authority over it, that anyone can check without contacting the issuer again.

Three properties define the concept:

Signed at source. The organisation that knows the fact signs it: the university signs the degree, the government agency signs the driving licence, the professional body signs the certification. That signature travels with the claim.

The holder keeps it. The credential goes to you, not to a middleman. You decide when to present it and to whom. It sits in a wallet on your phone, or in a system you control.

Verify without calling home. The verifier checks the signature mathematically. They do not need to call the issuing organisation, query a central registry, or wait for a third party to confirm. The credential carries the proof within itself.

The point is not to publish more data. It is the opposite. You prove the one fact that is needed and reveal nothing else. Data minimisation is the whole design goal here.

The W3C published the Verifiable Credentials Data Model 2.0 as an official recommendation in May 2025. That makes it a settled international standard. Governments and enterprises building systems today have a stable specification to build against, and it sits among the formats behind the EU's digital identity programme.

The system involves three roles. Together they form what the specification calls the trust triangle.

The issuer creates and signs the credential. This is the authority for the claim: a university, a government agency, a professional body, an employer. They produce a signed document that says, in effect, "this person has this qualification, and I am the authority for it." Once they hand it over, their job is done. They do not need to be online every time someone checks.

The holder is you. You receive the credential and store it in a wallet (a mobile app, a browser extension, an enterprise system). You decide when to share it and how much of it to reveal.

The verifier receives the credential and checks it. A verifier might be a bank confirming identity, an employer checking a professional licence, or an online platform confirming age. They check the issuer's signature, confirm the credential has not been altered, and get their answer.

On digital signatures. A digital signature is a seal only the issuer could have produced, but anyone can verify. It uses a pair of keys. The issuer keeps the private key, which never leaves their hands, and shares a public key anyone can use to check the seal. Nobody else can produce it, yet anyone can check it.

For a buyer, the practical question is not which mathematical curve is used. It is:

- Did this come from the expected issuer? - Has it changed since it was issued? - Is it still valid? - Was the holder allowed to present it?

Those checks are what make a credential verifiable in the first place, not just digital.

Selective disclosure. This is where verifiable credentials start to look different from a PDF. Take an age check. A nightclub, a car-hire desk, or an online service wants to know you are over 18. They do not need your exact date of birth, your name, or your address. With a traditional document you hand all of that over anyway.

With a selectively disclosable credential, you reveal only the claim you need: "over 18: yes." The mechanism, for those who want the name, is SD-JWT. The issuer signs the entire credential once, at the moment of issuance, using a legally binding digital signature. Each claim inside is wrapped individually. When you later present only the age claim, the verifier checks that specific claim against the original signature without you revealing the other fields, and without the issuer being involved at that moment at all. The issuer is not called, receives no notification, and has no record of where you used the credential. You hold the envelope; you choose which page to show.

Revocation. Credentials can go stale. A professional licence gets suspended, or an employee leaves the company and their credential should stop working. A document is reissued after a legal change. Verifiable credentials handle this through a status list (the W3C specification calls it a Bitstring Status List): a published reference the verifier can check to see whether a credential has been marked no longer valid. The issuer updates the list; the verifier reads it at the point of checking. The holder does not need to return the credential, and the issuer does not need to contact the verifier directly. Checks happen without a round-trip to the original issuer for every single verification.

A few things get conflated once this topic surfaces in a meeting, so it is worth being direct.

Verifiable credentials are not a login method on their own. They prove attributes about you; they are not an authentication protocol. You still need something to manage sessions and access.

They are not a central database or a register of people. No registry holds a list of all credentials issued. The issuer publishes a public key and, optionally, a revocation list. That is it.

They are not the same thing as a wallet. A wallet is an application that stores and presents credentials. The credential is the data; the wallet is the container. They are separate things.

They are not a tracking mechanism that phones home. Done correctly, the issuer has no visibility into where or how often you present a credential. The verifier checks the signature, consults the revocation list if needed, and that is the end of the exchange. No invisible reporting back to a third party.

They are not "self-sovereign" magic that removes the need for infrastructure. The holder gains real control over presentation, but institutions still matter. Issuers must be authoritative. Verifiers must know which issuers to recognise. Revocation has to work, and audit obligations do not disappear. The cryptographic layer solves trust in the claim. It does not automatically solve the plumbing beneath it: issuing credentials at scale, keeping revocations current across a network, and recording who verified what.

Digital certificates, the kind that secure websites and underpin legally binding document signing, have been around for decades. They work through a system of trusted authorities issuing certificates to servers or signers. A typical X.509 certificate proves a server is who it says it is, or that a person signed a document. That system is well-established and works well for what it was designed to do.

The structural difference with verifiable credentials is the holder in the middle. Traditional certificates are issuer-scoped: the certificate is tied to the issuing authority, the subject is fixed at issuance, and the relying party trusts the issuer directly. There is no holder with agency over what to share. No selective disclosure; the verifier receives the full certificate or nothing.

Verifiable credentials change that. One credential issued by a university can be presented to an employer, a regulator, and a licensing body without the university being involved in any of those checks. The holder decides when and where to present it, and which claims to reveal.

One simpler distinction matters too. A scanned PDF or a photograph of a diploma is not a verifiable credential. It is a copy. You cannot verify a copy automatically. You can read it, but you cannot confirm it has not been altered, and the recipient has to trust the image rather than the underlying claim. A verifiable credential is signed at the source. That difference is structural, and it is what lets a machine confirm the claim instead of trusting an image of it.

In May 2024, the revised eIDAS regulation (EU 2024/1183) came into force. It requires every EU member state to make at least one European Digital Identity (EUDI) Wallet available to citizens by the end of 2026. Regulated organisations, including banks and large online platforms, are then required to accept it about a year later, in late 2027.

The EU's Architecture and Reference Framework specifies the technical underpinnings: selective disclosure using SD-JWT, and the ISO mobile-document standard (ISO/IEC 18013-5) for certain use cases such as mobile driving licences. The European Commission published the wallet enrolment implementing regulation in April 2026, another sign that the detail is being nailed down.

Practical testing has been underway. The POTENTIAL programme, a large cross-border pilot, concluded in September 2025 after running trials across 19 EU member states. Use cases covered included banking, SIM registration, and e-government services. These are pilots and proofs-of-concept. Widespread deployment has not arrived yet, but the regulatory deadline is fixed and the technical architecture is settled.

For organisations operating in Europe, particularly those in regulated sectors, this is not a distant experiment. The 2026 deadline is in the regulation. The specification is published. The pilots have shown what works and where the friction still sits.

Some are live. Some are still pilots.

Mobile driving licences using ISO 18013-5 are live in several jurisdictions, including a number of US states and trials in parts of Europe. The standard is stable and real-world deployment has started.

University diplomas and digital degrees have seen pilots from a range of institutions. Graduates can carry a verifiable record of their qualification in a wallet and share it with employers directly, without requesting a copy from the institution each time.

Professional qualifications and business licences are being explored by several national authorities, allowing practitioners to hold a verifiable record without relying on paper certificates or manual checks with the issuing body.

Aviation provides a concrete example of what cross-sector coordination looks like: an IATA proof-of-concept let travellers carry digital verifications across a journey, reducing manual document checks at each stage.

Under the EUDI pilots, e-government attestations such as tax status, address verification, and residency were tested across member states in anticipation of the 2026 rollout.

The pattern is consistent. The use cases that work best are those where a credential issued in one place needs to be verified in many places, across organisational and national boundaries, without requiring the original issuer to be involved in every check.

Verifiable credentials answer one question well: can I trust this claim. The signature is valid, the credential has not been revoked, the issuer is who they say they are. That part is solved.

What they do not solve is the exchange layer underneath. Issuing credentials at scale. Routing them between organisations running different systems under different trust frameworks. Propagating revocations reliably across a network of verifiers. Keeping a durable record of who verified what, when, and under which mandate.

A wallet holds a credential and presents it. That is its job. It does not run that exchange between organisations, each on its own systems and rules. It does not generate an audit trail that both sides of an exchange can point to later. It does not connect the infrastructure of an insurer with the infrastructure of a hospital, or a licensing body with a regulator.

That layer is where mintBlue sits: alongside wallets, not as another one. Everyone seals their own envelope. mintBlue is the postman, moving envelopes peer-to-peer. We never look inside. Every hand-off leaves a tamper-evident record of who did what and when. The record holds the fact of the exchange, never the content: which type of claim was verified, by whom, when, under which mandate. The envelope stays sealed, and there is no central pot of personal data to breach.

The part of that sentence that matters most is the last one. Wallets do not, by themselves, keep a durable audit trail of verifications. The person who presented a credential knows they did it; the verifier knows they checked it. But there is no shared, tamper-evident record that both parties can point to later, that a regulator can audit, or that an organisation can use to demonstrate compliance. That record is what mintBlue is built to provide.

This lands differently for each team that has to sign off. Privacy teams want data minimisation. Compliance teams want evidence that holds up later. Security teams want fewer central honeypots to defend. Operations teams want grip on data flows that happen through email attachments, portals, and manual checks. The same layer answers all four.

This is not a replacement for wallets or for the cryptographic trust layer verifiable credentials already handle. It is infrastructure that runs alongside what you already have, with trust, accountability, and auditability built into every exchange.

The 2026 deadline exists whether organisations are ready for it or not. The real question is how to start without rebuilding everything first.

The answer is that you do not have to rebuild. The infrastructure runs alongside existing systems. You can start with a single credential type, a single use case, and build from there. The underlying standards are stable and the tooling is maturing. The standards themselves are open; the work sits in running that exchange layer reliably and keeping a durable record of who verified what.

The more useful question for most organisations is about the exchange layer around the credential: who issues what, to whom, under which trust framework, and how do you keep a record of it that holds up when someone asks later.

That question is worth answering before the deadline arrives on its own.