TL;DR: A W3C Verifiable Credential is a digital credential that anyone can check cryptographically without contacting the issuer, defined by the Verifiable Credentials Data Model v2.0, a W3C Recommendation since 15 May 2025. The standard does not require a blockchain: an issuer can publish its public key on its own web domain, and a blockchain is one optional registry among several. TRUE Original delivers the same core properties (tamper-evidence, verification without contacting the issuer, permanence) by securing every document it issues on a public blockchain.
By issuing through a platform that already runs the verification, instead of setting up keys, identifiers and verification software of their own. The organisation supplies its design and its recipients, from a dashboard, a learning platform, a CRM or a spreadsheet, and the platform publishes each credential with its own link and proof. TRUE Original works this way: every document is anchored on a public blockchain and published on the issuer's own domain, and anyone can check it in TRUE Verify without an account. Karolinska Institutet issues course certificates through TRUE Original from inside Canvas.
A W3C Verifiable Credential is a set of claims, signed by an issuer, that a holder can show to any verifier and that the verifier can check with mathematics instead of a phone call. The W3C Verifiable Credentials Data Model v2.0 defines it in one line: "a tamper-evident credential whose authorship can be cryptographically verified." A diploma, a professional licence and a membership card can all be expressed this way. TRUE Verify, TRUE Original's free verification service, checks a credential against blockchain anchors, embedded digital signatures, issuer databases and more than 80 external credential platforms.
Many digital certificates are still pictures of paper. A PDF diploma looks official, but the only way to be sure of it is to write to the university and wait. The registrar who replies does the same work for every employer who asks. The employer who never asks takes the PDF on trust.
The W3C standard puts the proof in the credential.
The specification describes "a three-party ecosystem for the exchange of these credentials that is composed of issuers, holders, and verifiers." The issuer makes the claim and signs it: a university, a certification body, a licensing authority, an association. The holder keeps the credential and decides when to show it, to whom, and how much of it. The verifier is the employer, client or hospital that needs to trust the claim, and it never has to reach the issuer. With TRUE Original the issuer is the organisation behind the document, the holder receives it in TRUE Wallet, and the verifier checks it in TRUE Verify without an account.
| Aspect | Paper or PDF credential | Verifiable Credential |
|---|---|---|
| Verification | Contact the issuer manually | Cryptographic verification |
| Tampering | Easy to forge or edit | Tamper-evident by design |
| Issuer dependency | Must reach the issuer to verify | Verifiable without contacting the issuer |
| Privacy | Share the entire document | Share only the claims needed |
| Format | Varies by issuer | Standardised by W3C |
| Machine processing | Manual inspection | Automated verification |
The W3C Verifiable Credentials Data Model v2.0 has been a W3C Recommendation, the consortium's term for a finished web standard, since 15 May 2025. On 15 May 2025 the W3C Verifiable Credentials Working Group published seven Recommendations at once: the data model, two ways of securing a credential, two families of signature suites, a format for identifier documents and a revocation list. Examples written for version 1.1 (a Recommendation from 3 March 2022), with the context URL https://www.w3.org/2018/credentials/v1 and the field issuanceDate, are out of date.
The W3C framed the release as a message to governments as much as to developers. "Verifiable Credentials 2.0 reaching the status of Web Standards is a critical signal to innovators, policymakers, and tech leaders in governments, industry, and civil society", said Seth Dobbs, W3C CEO and President, in the W3C press release of 15 May 2025.
Two pieces are still unfinished. The W3C Verifiable Credentials Overview, updated as a Group Note on 30 July 2026, lists the Verifiable Credentials JSON Schema specification and the BBS cryptosuites as Candidate Recommendations, "technically complete" but not yet standards. BBS is the suite built for unlinkable selective disclosure.
The most private way of sharing a credential is the part still waiting.
The W3C Verifiable Credentials Data Model v2.0 specifies the structure of a credential (who issued it, about whom, which claims, valid from when) and requires every conforming credential to be secured by at least one securing mechanism. The specification recognises two classes: embedded proofs, such as Verifiable Credential Data Integrity 1.0, and enveloping proofs, such as Securing Verifiable Credentials using JOSE and COSE. Issuers and subjects are identified by URLs or by decentralised identifiers (DIDs).
Here is a professional certification in version 2.0. The first context URL is fixed by the specification, and validFrom and validUntil replace the version 1.1 fields issuanceDate and expirationDate.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "https://issuer.example/credentials/123",
"type": ["VerifiableCredential", "ExampleCertificationCredential"],
"issuer": "did:web:issuer.example",
"validFrom": "2026-03-04T12:00:00Z",
"validUntil": "2029-03-04T12:00:00Z",
"credentialSubject": {
"id": "did:example:holder456",
"name": "Maria Andersson",
"certification": "Certified Security Professional",
"level": "Expert"
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-rdfc-2022",
"created": "2026-03-04T12:00:00Z",
"verificationMethod": "did:web:issuer.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQp..."
}
}A credential written for version 1.1 looks like this:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://example.org/credentials/v1"
],
"id": "https://example.org/credentials/123",
"type": ["VerifiableCredential", "ProfessionalCertification"],
"issuer": "did:example:issuer123",
"issuanceDate": "2026-03-04T12:00:00Z",
"credentialSubject": {
"id": "did:example:holder456",
"name": "Maria Andersson",
"certification": "Certified Security Professional",
"level": "Expert",
"issuedBy": "Swedish Security Association"
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2026-03-04T12:00:00Z",
"verificationMethod": "did:example:issuer123#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic..."
}
}A decentralised identifier (DID) is an identifier whose owner can prove control of it without asking a central registry. The W3C Decentralized Identifiers (DIDs) v1.0 specification, a Recommendation since 19 July 2022, says DIDs "have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities." A DID resolves to a DID document, which holds the public key a verifier needs.
Verifiable credential verification checks the issuer's signature against the credential data, using the issuer's public key, which the verifier finds by resolving the issuer's URL or DID. If one character in the credential has changed, the signature check fails. The verifier then checks the validity period and, if the credential carries a status entry, whether the issuer has revoked it.
The issuer does its part once. The credential data is put into a canonical form and hashed, the hash is signed with the issuer's private key, and the signature travels with the credential as its proof. The private key never leaves the issuer.
The verifier runs four checks:
Revocation is a single bit. Bitstring Status List v1.0, one of the seven W3C Recommendations of 15 May 2025, sets a default list of 131,072 entries, "equivalent to 16 KB of single bit values", and with only a handful of revocations the compressed list shrinks to a few hundred bytes. The size is deliberate: the verifier downloads the whole list, so the issuer cannot tell which credential was being checked.
Yes, the W3C Verifiable Credentials Data Model v2.0 supports selective disclosure, which it defines as "the ability of a holder to make fine-grained decisions about what information to share." The holder places the chosen claims in a verifiable presentation and sends that instead of the full credential. Whether individual claims can be left out depends on the securing mechanism the issuer chose when signing.
Two mechanisms in the 2025 Recommendations can do it: the ecdsa-sd-2023 cryptosuite in Data Integrity ECDSA Cryptosuites v1.0, and Selective Disclosure for JWTs (SD-JWT) through Securing Verifiable Credentials using JOSE and COSE. A third, the BBS cryptosuite, also makes presentations unlinkable, so two verifiers cannot compare notes and find they saw the same holder. BBS is still a Candidate Recommendation.
The specification's simplest advice needs no cryptography: "It is considered best practice for issuers to atomize information or use a securing mechanism that allows for selective disclosure." Its example is a driving licence carrying an ID number, height, weight, birthday and home address. A bar checking age has no use for the address.
Holders don't always share raw credentials. Instead, they create Verifiable Presentations, packages that can include:
No, W3C Verifiable Credentials do not require a blockchain. The W3C Verifiable Credentials Data Model v2.0 lists distributed ledgers as one example of a verifiable data registry, next to "trusted databases, decentralized databases, government ID databases", and an issuer can publish its public key on its own website with the did:web method. A blockchain is an option an issuer can add for a public, timestamped record that does not depend on the issuer's own servers. SSF Stöldskyddsföreningen, a Swedish security association founded in 1934, takes that option through TRUE Original, and anyone can check an SSF certificate in a few seconds without contacting SSF.
The specification is relaxed about where trust data lives. A registry can be published "via a peer-to-peer protocol from a trusted publisher, a publicly accessible and well known web site (with a content hash), a blockchain, etc." The "etc." is in the original.
The belief that verifiable credentials run on blockchains has a source: many DID methods do use a ledger. The did:web method was written as the alternative. Its authors argued that "DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption," and proposed using "a web domain's existing reputation" instead. The did:key method needs no registry at all, because the public key is the identifier.
A record written to a public blockchain cannot be edited afterwards, by an attacker or by the issuer. It carries a timestamp no single party controls, so the date of issue is a fact rather than a field someone typed. A verifier can check it while the issuer's website is down, or years after the issuer has replaced its systems, and a revocation written to the chain stays readable on the same terms.
A W3C Verifiable Credential is checked with mathematics, while a PDF certificate is checked by asking the issuer. Anyone with a PDF editor can change a name or a date on a PDF certificate, and nothing in the file shows it. A verifiable credential fails verification the moment one character changes.
Many organisations moved from paper to digital years ago and kept paper's weakness: nothing binds the content to the issuer. PDF certificates remain the most common "digital credential" format. Password protection stops casual edits, not determined ones. A verifier who wants certainty has to reach someone at the issuer during office hours. Often, nobody tries. The check gets skipped, and a forged certificate passes because nobody looked.
A verifiable credential removes each of those weaknesses. The signature binds the content to a key the issuer controls, so any change breaks it. The shared format lets an applicant tracking system read a credential from any issuer without custom code. And the check needs no person at the issuer, so the ten-thousandth verification costs the same as the first and every check can be logged for an audit.
Verification:
An organisation implementing verifiable credentials makes four decisions: which DID method identifies it as an issuer, what each credential schema contains, how issuing and verifying connect to existing systems, and where holders keep their credentials. The did:web method asks the least of a new issuer, because it reuses the web domain the organisation already owns. None of the four decisions requires a blockchain.
The DID method decides where a verifier finds the issuer's public key.
| DID method | Where the public key is published | Needs a blockchain? |
|---|---|---|
| did:web | A did.json file on the issuer's own web domain | No |
| did:key | Inside the identifier itself | No |
| did:ethr | An Ethereum account, with key changes recorded in an ERC1056 smart contract | Only for key changes; creating the identifier needs no registration |
Different DID methods have different characteristics:
| DID Method | Decentralisation | Cost | Speed | Maturity |
|---|---|---|---|---|
| did:web | Low (depends on domain) | Free | Fast | High |
| did:ethr | High (Ethereum) | Gas fees | Medium | High |
| did:key | Maximum (self-certifying) | Free | Instant | High |
| did:ion | High (Bitcoin) | Minimal | Slow | Medium |
A did:web identifier carries the domain's reputation: a verifier who sees did:web:university.example knows which organisation stands behind the key. The trade-off is plain. Whoever controls the domain controls the identity.
A schema fixes which claims a credential carries. Include only what a verifier needs, reuse existing vocabularies, and split sensitive claims into separate credentials or sign them with a selective disclosure suite. Plan from the start how a credential is updated, suspended and revoked. Verifiable Credentials JSON Schema, the W3C format for publishing schemas, is still a Candidate Recommendation.
Issuing starts from an event in a system the organisation already runs: a learning management system marks a course as completed, an HR system records a new role, and an API call turns the event into a signed credential. On the receiving side, an applicant tracking system, an access control system or a compliance tool runs the verification and records the result.
A verifiable credential wallet is software that stores a holder's credentials and builds presentations from them. The W3C data model calls it a credential repository, "such as a file system, storage vault, or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials." Wallets exist as mobile apps, cloud services, browser tools and hardware devices, and Regulation (EU) 2024/1183 adds national ones: every EU Member State must provide EU Digital Identity Wallets to citizens by the end of 2026. Issuers should plan for several wallets rather than require one. Documents issued through TRUE also land on their own in TRUE Wallet, the holder's free professional profile, where a former manager, a colleague or the school can confirm the rest of the CV.
Verifiable credentials fit wherever one organisation has to trust a claim made by another: diplomas and professional certifications, employee and customer credentials, government identity, product passports and healthcare licences. In each case the holder presents the credential and the verifier checks it in seconds, without a phone call to the issuer. The W3C press release of 15 May 2025 named digital wallets in health, financial services, travel and education among the needs the standard serves.
Education and professional credentials. A university issues a degree the graduate keeps for life, and an employer checks it without writing to the registrar. Certification bodies do the same for professional qualifications, and training providers for completed courses.
Identity and access. An employer issues credentials for role and permissions that an access control system checks in real time. Governments issue identity documents, licences and permits; with the EU Digital Identity Wallet, the European Commission says, citizens "will have the power to choose which aspects of their identity and data they share with third parties."
Supply chain and products. The EU Ecodesign for Sustainable Products Regulation (EU) 2024/1781, in force since 18 July 2024, introduces the Digital Product Passport, which the European Commission describes as "a digital identity card for products, components, and materials." EU regulations will require DPPs for many products. VCs provide a standards-based format for DPP implementation. A product passport is a bundle of claims that a recycler or a customs officer has to trust, the same shape of problem as a diploma. TRUE Original already creates digital product passports verified on blockchain.
Healthcare. A licensing board issues a medical licence that a hospital checks before granting privileges, and a patient shows a clinic only the line of an insurance credential it needs.
TRUE Original delivers the core properties of a verifiable credential (tamper-evidence, verification without contacting the issuer, and permanence) by securing every document it issues on a public blockchain. Anyone can verify a TRUE document by clicking the button next to it on the web or by scanning the QR code on a printed copy with a smartphone camera, and no app is needed. By October 2026, TRUE Original had created, issued and stored over 900,000 documents for more than 200 issuing organisations, with customers in more than 15 countries.
A W3C Verifiable Credential and a blockchain-secured certificate answer the same question with different machinery. The first carries a signature inside the document. The second anchors the document's fingerprint on a public ledger, where nobody can change it afterwards.
The person checking does not need to know any of this. TRUE Verify, TRUE Original's free verification service, checks a document against its blockchain anchor and returns a security level. No account is required.
Real organisations, from 80-year security authorities to government agencies to universities, have implemented blockchain credentials and eliminated verification friction. SSF Stöldskyddsföreningen, a Swedish security association founded in 1934, issues blockchain-secured certificates through TRUE that anyone can verify without contacting SSF. Bolagsverket, the Swedish Companies Registration Office, built a concept called Proof of Business with TRUE in eight weeks, and Karolinska Institutet issues its course certificates through TRUE. Developers connect a learning platform or CRM through the TRUE API, which has five endpoints.
Choose a verifiable credential platform by the problem it has to solve. If partners require W3C conformance, you need a full W3C stack with DIDs, wallets and verification software; if the goal is documents anyone can verify without contacting you, a blockchain credential platform such as TRUE Original delivers that now. A hybrid path starts with the second and adds W3C formats as partners and wallets ask for them.
Map the credentials before choosing technology:
Start where the benefit is largest. High-volume credentials, where every manual check costs time. High-stakes ones, where a single forgery is expensive. Regulated ones, where a PDF no longer satisfies the auditor, and shared ones, where a common format saves integration work with partners.
A full W3C stack gives the most interoperability. It also asks the most of your IT department. A blockchain credential platform gives tamper-evidence and verification without contact from the first document, with far less to build. For a side-by-side view of what platforms offer, see the comparison of five digital credential platforms. Whatever you choose, keep the credential data exportable: JSON Schema and BBS are still Candidate Recommendations, and the EU wallets are still to arrive.
Regulation sets the pace for verifiable credentials and digital identity in Europe. Regulation (EU) 2024/1183, the European Digital Identity Framework, requires every EU Member State to provide EU Digital Identity Wallets to citizens by the end of 2026, and the European Commission says those wallets can carry "proof of other personal attributes like driving licenses, diplomas, and bank accounts." The same regulation adds the recording of electronic data in an electronic ledger to the EU's trust services.
EU Digital Identity Wallet: The EU is mandating digital identity wallets for citizens, with VC-based credentials. This will accelerate adoption across Europe.
eIDAS 2.0: Updated EU regulations strengthen requirements for electronic identification and trust services, with explicit support for VCs.
Digital Product Passports: EU sustainability regulations will require DPPs for many products, driving VC adoption in supply chains.
For universities, TRUE Original already offers eIDAS-sealed diplomas that are ready for the EU wallet.
The technical work still open is narrower than it was. Revocation is settled by Bitstring Status List v1.0. Zero-knowledge proofs, such as proving age without revealing a birth date, wait on the BBS cryptosuite. Exchange protocols, the rules for how a credential travels from issuer to wallet to verifier, and wallet interoperability are still open.
Trust frameworks are the harder part: agreements on which issuers are authoritative for which credentials. A signature proves who signed. It cannot prove the signer had the right to.
A wallet that carries a diploma and shows it to an employer without a phone call to the university is no longer a pilot project. Under Regulation (EU) 2024/1183, every Member State has to offer one by the end of 2026.
Every organisation we work with started with the same question. Give us thirty minutes and we will show you what your own documents would be worth.
Book a callNot sure where to start? Let us help!
Trusted by leading organisations worldwide
