What is a verifiable credential?

A verifiable credential — a VC — is a piece of proof. Issued by an organization. Held by the person it's about. Verifiable by anyone who needs to trust it.

The plain-language explanation

Imagine a first aid certificate. Today, it's probably a PDF from the training provider, or a paper card in your wallet. If an employer wants to check whether it's real, they either take your word for it or call the training provider and wait.

A verifiable credential is the same certificate, done differently. The training provider issues it as a digital document, signs it with a cryptographic key that only they hold, and sends it to your phone. It sits in your digital wallet alongside your other credentials.

When someone needs to confirm it's real, you show them a QR code from your wallet. They scan it. Their device confirms — in seconds — that the credential was issued by the training provider you say it was, hasn't been altered, and hasn't been revoked. The training provider doesn't need to be called, emailed, or involved in any way.

The issuer issues. The holder holds. The verifier verifies. Each one has what they need, and no more than that.

That's the short version. If you want to go deeper — how the signing actually works, what makes the standard interoperable, why a verifiable credential is different from a PDF, a paper ticket, or a database lookup — keep reading.

What this looks like in practice.

Video still — placeholder

Animated. Captions included.

How a verifiable credential works

A verifiable credential moves through four stages: issued, held, presented, verified. Each stage has a specific role, and the security of the credential depends on how those stages fit together.

The four-stage lifecycle of a verifiable credential Four geometric nodes arranged horizontally from left to right — Issued, Held, Presented, Verified — connected by dashed arrows. Each node contains a simple geometric glyph: a document with a signing seal for Issued, a wallet card for Held, a QR pattern for Presented, and a checkmark for Verified. Stage 01 Stage 02 Stage 03 Stage 04 Issued Held Presented Verified
Four horizontal stages — Issued, Held, Presented, Verified — connected by dashed arrows.
Stage 01

Issued

The issuing organization — a government regulator, a professional body, a training provider — creates a credential: the qualification name, the holder's identity, the issue date, any expiry, and any conditions that apply. The credential is a structured digital document, readable by any system that supports the standard.

The issuer signs the credential with a cryptographic key that only they control. The signature is mathematically linked to both the credential's content and the issuer's identity. Any change to either — even a single character in the holder's name — breaks the signature and makes the credential fail verification.

Stage 02

Held

The signed credential is delivered to the holder's digital wallet, on their phone. It lives on their device, not on a central server. The issuer doesn't hold a copy for the holder to check out later; there's no third-party database keeping track of which credentials exist.

The holder controls what happens next. They can view the credential, share it, present it for verification, or keep it private. They can share the whole credential or, where the standard supports it, only the specific fields a verifier needs — confirming a qualification without revealing every detail.

Stage 03

Presented

When a verifier needs to confirm a credential, the holder presents it — usually through a QR code displayed in their wallet. The QR code contains a cryptographic reference to the credential, not the credential itself. The holder decides what to share in that moment, and what to hold back.

Presentation is an action the holder takes, not a query a verifier makes. A verifier cannot pull a credential from a holder's wallet. The exchange only happens when the holder initiates it.

Stage 04

Verified

The verifier scans the QR code and checks the credential against the registry that stores the issuer's cryptographic identity. The registry confirms the signature is valid — proving the credential was issued by the organization named on it — and confirms the credential has not been revoked.

The verifier sees only what the holder has shared, only what the issuer has signed, and nothing else. The verification takes seconds. The issuer is not contacted. No portal is accessed. The confirmation is mathematical, not administrative.

What makes a verifiable credential different from a PDF, a paper ticket, or a database lookup

People have been proving qualifications for as long as there have been qualifications. Each older method has specific weaknesses. Verifiable credentials are designed around those weaknesses.

A paper ticket or PDF

Can be edited, copied, photoshopped, or fabricated from scratch. A verifier has no way to confirm the version in front of them is what the issuer actually issued. Fraud is easy. Verification, beyond visual inspection, isn't possible.

A photo of a certificate, or a scan in an HR system

Still requires someone to contact the issuer to confirm the credential is real and still valid. Expensive, slow, and impossible at scale. Every credential check becomes a phone call or a manual database lookup somewhere.

A database lookup

Requires every verifier to connect with every issuer's system, every credential to live in a central database, and the issuer's systems to stay online indefinitely. None of this scales. And it puts the holder's credential record in a place the holder doesn't control.

A verifiable credential

Signed at the moment of issuance. Held by the person it's about. Verifiable against an open registry, with no call to the issuer needed. Works even when the issuer's portal is offline. Remains readable for as long as the open standards behind it remain readable — which is likely to be decades.

What standards make this work

Verifiable credentials aren't a product. They're an open international standard, developed and maintained by the World Wide Web Consortium — the same body responsible for HTML, CSS, and the core standards of the web itself. The standard is called the W3C Verifiable Credentials Data Model, and it is currently in its second version, published in 2024.

Because the standard is open and international, a credential issued through one system can be read and verified by any other system that supports the standard. A credential issued by a Canadian regulator can be verified by an Australian employer. A wallet from one provider can hold credentials from any issuer. The standard is what makes this possible, and Oliu™ is built on it — not adjacent to it, not inspired by it, not compatible with it. Built on it.

In Canada specifically, Oliu™ also aligns with the DIACC Pan-Canadian Trust Framework and Digital Governance Standards Institute guidance — national frameworks that define how digital credential infrastructure should operate in Canadian jurisdiction.

Why this matters for Canada

A credential that's verifiable in seconds, across provinces, without contacting the issuer, changes things a Canadian worker experiences every day.

A tradesperson moving from Alberta to Ontario doesn't need to re-qualify — their ticket travels with them. A first-aider applying for a job doesn't wait while their employer calls the training provider. A regulator investigating compliance doesn't need bilateral agreements with every other province. An employer hiring across provincial lines isn't choosing between speed and certainty.

The same change matters for the organizations issuing credentials. Fraud drops because forgery is mathematically impossible without the issuer's signing key. Verification burden drops because the issuer is no longer the bottleneck. Credentials stay relevant for longer because they outlive specific systems and portals. And the network effect grows: the more issuers join, the more useful every credential becomes.

This is the foundation Oliu™ is built on.