This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.
Why This Matters
If you are building or buying a learning product, the credential is the thing your learner walks away with — it is your product's receipt, and increasingly the reason a buyer chooses you. Employers have noticed: in 2025 surveys, a large majority say they actively look for credentials they can verify, and over 320 million digital badges were issued that year. This article is the plain-language map of how modern credentials work, who the standards bodies are, what "verifiable" actually means in code, and how issuance wires into a learning platform you already run. It is written for an L&D director, founder, or product manager scoping a credentialing feature — not for a cryptographer, though an identity engineer should recognize every term used here.
First, Three Words People Use Interchangeably — and Shouldn't
Start with vocabulary, because most confusion here is a vocabulary problem.
A certificate, in the everyday sense, is a document that says someone finished something — the PDF with a gold seal your platform emails after the final quiz. It proves nothing on its own; it is a picture of a claim.
A digital badge is a certificate with structured data attached. The standard term for the achievement it represents, called an Open Badge, is a small machine-readable record — who earned it, who issued it, the criteria, sometimes the evidence — wrapped around (or alongside) a visual icon. A badge is a certificate that a computer can read, not just a human.
A verifiable credential is a badge (or any claim) that a computer can also trust. The precise term for a tamper-evident, cryptographically signed claim, called a Verifiable Credential (VC), is a small file carrying a digital signature from the issuer, so any third party can confirm two things on their own: that you really issued it, and that nobody altered it since. The signature is the difference. A certificate asserts; a verifiable credential proves.
Think of it as a trust ladder. A PDF certificate is a printed concert ticket — easy to photocopy. An Open Badge 2.0 is a ticket with a barcode that points back to the box office. A verifiable credential is a ticket with a hologram the bouncer can check in the dark, without calling the box office at all. Each rung adds a way for an outsider to believe the claim without trusting you personally.
Figure 1. The credential trust ladder. Each rung adds independent verifiability — a PDF asserts, a badge links back to you, a verifiable credential proves itself with a signature anyone can check.
Why the PDF Certificate Quietly Fails
The PDF is worth a moment because it is still what most learning products ship, and it fails in three specific ways a buyer will eventually hit.
First, it is forgeable. A PDF is an image; a learner with basic tools can change the name, the date, or the grade, and the result looks identical. Second, it is unverifiable at a distance. An employer who wants to confirm it has to email your support team, which does not scale and often goes unanswered. Third, the common "fix" — a verify link back to your site — is fragile: it breaks when you rename a page, migrate platforms, or shut down, and at that moment every certificate you ever issued becomes unprovable. A credential whose proof depends on your servers staying up forever is not really a credential; it is a promise.
Verifiable credentials were designed to remove that dependency. Because the proof travels inside the credential as a signature, a verifier checks it with your public key — published once, at a stable address — and never has to reach your application at all. The learner can prove their achievement years after your company is gone.
The Three-Party Model: Issuer, Holder, Verifier
Every modern credential system, whatever the brand name, is built on the same three roles, defined by the W3C Verifiable Credentials Data Model. Anchor them once and the rest follows.
The issuer is whoever makes the claim — your learning platform, a university, an employer. The issuer signs the credential with a private cryptographic key. The holder is the learner the credential is about; they receive it and keep it, usually in a digital wallet (a phone or web app that stores credentials). The verifier is whoever wants to check it later — a hiring manager, an admissions office, another platform.
The flow is simple. You (issuer) sign and hand the credential to the learner (holder). Later, the learner presents it to an employer (verifier). The employer's software runs two checks automatically: it confirms your signature against your published public key (so the claim is authentic and unaltered), and where applicable it confirms the learner authorized this particular sharing. Crucially, the verifier never has to contact you. That independence is the whole point.
Figure 2. The three-party trust triangle. The issuer signs once; the holder keeps the credential in a wallet they control; the verifier checks the signature against a published public key without ever calling the issuer's servers.
Two more ideas make this powerful. A verifiable presentation is what the holder actually sends — one or more credentials, signed again by the holder to prove they are the rightful presenter. And selective disclosure lets the holder reveal only part of a credential — proving they hold a diploma without exposing their birth date, for example. Both are built into the 2.0 data model and matter for privacy.
The Standards That Actually Run This
You do not invent any of this. Two standards bodies have already built it, and as of 2025 their work has converged into one coherent stack.
W3C Verifiable Credentials Data Model 2.0 — the secure container
The W3C Verifiable Credentials Data Model 2.0 became an official W3C Recommendation on 15 May 2025. It defines the data shape of a credential (claims expressed in JSON-LD, a JSON format that links each term to a shared vocabulary), the three-party ecosystem above, and — importantly — several ways to attach the cryptographic proof, so an implementer can choose the signing method that fits their regulatory and technical needs. It shipped as a family: alongside the core model came the Data Integrity cryptosuites, methods for securing credentials with JOSE and COSE (widely used signing standards), Controlled Identifiers, and the Bitstring Status List for revocation (more on that below). This is the generic foundation — it is not specific to education; the same model carries driver's licenses and supply-chain certificates.
Open Badges 3.0 — the education profile on top
Open Badges began at Mozilla in 2011 and is now maintained by 1EdTech (formerly IMS Global), the same body behind LTI and SCORM-adjacent education standards. The current version, Open Badges 3.0, was finalized in 2024, and it made a decisive move: an Open Badges 3.0 assertion is a W3C Verifiable Credential. In 1EdTech's own words, each badge (the OpenBadgeCredential type) is "digitally signed by its issuing organization as Verifiable Credentials compatible with the Verifiable Credentials Data Model 2.0." Every 3.0 badge is a VC; not every VC is a badge. That alignment means a 3.0 badge works in the broader credential and wallet ecosystem, not just inside education tools.
It helps to know what changed from the prior version. Open Badges 2.0 worked by "baking" the achievement data into the badge image — the JSON metadata was embedded inside the PNG or SVG — and verification typically pointed back to a hosted copy of the assertion on the issuer's server. That is the link-back model, with its fragility. Open Badges 3.0 moves the trust into a signature on a verifiable credential, so the badge proves itself.
CLR 2.0 — bundling badges into a transcript
A single badge is one achievement. The Comprehensive Learner Record (CLR) Standard 2.0, released by 1EdTech in March 2025, bundles many achievements into one verifiable package — a ClrCredential — which is itself a verifiable credential, signed the same way and aligned with Open Badges 3.0. Think of a badge as one line on a résumé and a CLR as the whole résumé, cryptographically signed. It is how you give a learner a portable, verifiable transcript of everything they did across your platform.
Figure 3. The standards stack. W3C Verifiable Credentials 2.0 is the foundation; Open Badges 3.0 and CLR 2.0 are the education-specific profiles built on it, which is why a badge issued by one tool can be read by any conformant wallet or verifier.
How Issuance Actually Wires Into a Learning Platform
This is the part builders care about, and it is more straightforward than the cryptography suggests. A credential is issued when a learner meets a defined condition, so the work is connecting "they finished" to "they got a signed credential."
The trigger comes from your existing tracking. When a learner completes a course, your learning system already knows — through a completion record in the LMS (one of the core learning metrics), an xAPI statement landing in your learning record store, or a cmi5 "passed/completed" result. That completion event calls an issuing service, which assembles the credential (the achievement, the criteria, the earner's identifier), signs it with the issuer's private key as an Open Badges 3.0 verifiable credential, and records its status so it can be revoked later.
From there the credential reaches the learner's wallet. 1EdTech's Badge Connect API — a RESTful API secured with OAuth 2.0 — handles the learner-initiated transfer of badges into the wallet or "backpack" of their choice, which keeps the learner in control of where their credentials live. If your assessment runs inside another institution's LMS, the result often travels back over LTI Advantage's Assignment and Grade Services — the same path covered in grading, rubrics, and grade passback — and the credential is issued on the strength of that recorded outcome. The same wiring is detailed end to end in the proctoring and assessment reference design.
Figure 4. The issuance pipeline inside a learning platform. A completion event from the LMS, LRS, or cmi5 triggers signing; Badge Connect moves the credential to the learner's wallet; a status list lets you revoke it later.
Revocation and expiry: the step everyone forgets
A credential is not always forever. A safety certification expires; a credential issued by mistake must be pulled back. Because verifiers do not contact you, you cannot just delete a record on your side and expect the credential to stop working. The standards solve this with a status list: the issuer publishes a single, compact, privacy-preserving list (the W3C Bitstring Status List), and every credential points to its slot in that list. A verifier checks the list to see whether the credential is still valid, revoked, or suspended. If you ship issuance without a status mechanism, you have built credentials you can never take back.
Common mistake: treating "verifiable" as a property of the image. A learner can screenshot a badge icon and it looks the same — the visual is decorative. The trust lives in the signed credential and its status check, not the picture. Design your verifier (and your buyers' expectations) around checking the signature and the status list, never around the image looking official.
Comparing the Formats
Here is the practical comparison a builder needs, with the standards-support column this section always includes.
| Property | PDF certificate | Open Badges 2.0 | Open Badges 3.0 / CLR 2.0 |
|---|---|---|---|
| Machine-readable data | No | Yes (baked in image) | Yes (JSON-LD claims) |
| Tamper-evident | No | Weak (hosted link) | Yes (digital signature) |
| Verifiable without contacting issuer | No | No | Yes (public key) |
| Revocation / expiry support | No | Limited | Yes (status list) |
| Learner holds it in a wallet | No | Partial (backpack) | Yes (Badge Connect API) |
| Selective disclosure / privacy | No | No | Yes (VC 2.0) |
| Standards support | none | 1EdTech Open Badges 2.0 | W3C VC 2.0 · Open Badges 3.0 · CLR 2.0 |
| Best fit | internal, low-stakes | legacy systems | new builds, portable credentials |
The pattern is clear: the higher up the table, the more an outside party can trust the claim without trusting you. For any new build where the credential is meant to travel — to an employer, another school, a public registry — Open Badges 3.0 on the W3C VC 2.0 base is the target.
Build vs Buy: Where the Line Sits
Lead with the trade-off, because it decides your roadmap. The credential standards are deep, the signing and key management are security-sensitive, and wallet interoperability has to be tested against real wallets — so the issuing-and-wallet plumbing is usually something you buy from a conformant credentialing platform. What you should own is the logic that is specific to your product: the rule that decides when a credential is earned, the criteria and metadata that make it meaningful, and the revocation policy.
The numbers usually favor buying the plumbing. Suppose you graduate 20,000 learners a year and want each to leave with a verifiable credential, and a credentialing platform charges roughly $0.40 per issued credential:
Per-credential pricing:
20,000 credentials/year × $0.40 = $8,000/year
Building your own W3C-conformant issuer instead means private-key management, a Bitstring Status List endpoint, a Badge Connect API, and wallet testing across several wallets — a few engineer-months up front, plus ongoing maintenance as the spec versions move (VC 1.1 to 2.0, Open Badges 2.0 to 3.0). At $8,000 a year, the bought option pays for itself for several years before an in-house issuer would break even — and you still own the parts that actually differentiate you. The exception is when credentials are core to your business model (a credentialing platform itself) or a compliance regime forces in-house key custody. The same logic drives the broader build vs buy vs extend an LMS decision.
Common mistake: picking a vendor that issues only its own proprietary format. If credentials cannot be read by any conformant wallet or verifier, you have rebuilt the PDF problem with extra steps — lock-in instead of portability. Require Open Badges 3.0 / W3C VC 2.0 conformance in the contract, and confirm it against 1EdTech's certification, not the sales deck.
A Note on Blockchain and Decentralized Identifiers
You will hear "blockchain credentials." The honest framing: a blockchain is one optional way to anchor trust, used by approaches like the open Blockcerts standard, but it is not required for a credential to be verifiable. The W3C model gets tamper-evidence from the issuer's signature, not from a ledger. Separately, Decentralized Identifiers (DIDs, a W3C Recommendation) are an optional way to identify the issuer or holder without a central registry; they pair naturally with verifiable credentials but are not mandatory. For most learning products, a standard signature plus a published public key delivers verifiability without taking on a blockchain's operational cost. Treat the ledger as a design option, not a default.
Where Fora Soft Fits In
Fora Soft builds learning, assessment, and video products where what a learner earns has to hold up outside the platform. In credentialing, the value we add is rarely the cryptography library — it is the engineering judgment to integrate a conformant Open Badges 3.0 / W3C VC issuing service cleanly, to wire issuance to the real completion signal (an LMS record, an xAPI statement, an LTI grade), and to design the revocation and status-list policy so a credential issued in error can actually be pulled back. We help teams decide what to buy and what to own, so the credential is portable, verifiable, and yours to govern — not locked inside one vendor's wall.
What to Read Next
- cmi5 explained: the bridge between SCORM and xAPI — how a completion result gets recorded, the trigger that issues a credential.
- LTI explained: launching tools inside any LMS — how a result travels back to the LMS via Assignment and Grade Services.
- Proctoring and assessment reference design — the full annotated blueprint where credential issuance is the final step.
Call to action
- Talk to a e-learning engineer — book a 30-minute scoping call to talk through your verifiable credentials plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the Verifiable Credential Readiness Checklist — A one-page gate to run before shipping credentials: confirm Open Badges 3.0 / W3C VC 2.0 conformance, wire the issuance trigger to a real completion signal, handle signing and key management, deliver to a learner wallet via Badge….
References
- Verifiable Credentials Data Model v2.0 — W3C Recommendation, 15 May 2025 (three-party model, JSON-LD claims, proofs, verifiable presentations). World Wide Web Consortium (W3C). Tier 1. https://www.w3.org/TR/vc-data-model-2.0/
- "W3C publishes Verifiable Credentials 2.0 as a W3C Standard" — press release, 15 May 2025 (issuer/holder/verifier, selective disclosure, family of specs). W3C. Tier 1. https://www.w3.org/press-releases/2025/verifiable-credentials-2-0/
- Open Badges Specification 3.0 — OpenBadgeCredential as a Verifiable Credential compatible with VC Data Model 2.0; Badge Connect API; Endorsement. 1EdTech Consortium. Tier 1. https://www.imsglobal.org/spec/ob/v3p0/
- Open Badges — standard overview (Open Badges 3.0 and CLR 2.0 assertions; Badge Connect API; OAuth 2.0; 2.0 vs 3.0). 1EdTech Consortium. Tier 1. https://www.1edtech.org/standards/open-badges
- Comprehensive Learner Record Standard 2.0 — ClrCredential, bundling achievements as Verifiable Credentials aligned with Open Badges 3.0. 1EdTech Consortium. Tier 1. https://www.imsglobal.org/spec/clr/v2p0
- Bitstring Status List v1.0 — W3C Recommendation (privacy-preserving revocation/suspension status for verifiable credentials). W3C. Tier 1. https://www.w3.org/TR/vc-bitstring-status-list/
- Decentralized Identifiers (DIDs) v1.0 — W3C Recommendation (optional decentralized issuer/holder identifiers). W3C. Tier 1. https://www.w3.org/TR/did-core/
- "Latest Comprehensive Learner Record Standard Improves Security, Portability and Verification of Digital Credentials" (CLR 2.0 released March 2025). 1EdTech Consortium. Tier 2. https://www.1edtech.org/1edtech-article/latest-comprehensive-learner-record-standard-improves-security-portability-and
- "New Report Finds 1.85 Million Credentials and Opportunities" — Credential Engine, 9 December 2025 (1,022,028 badges; 486,352 certificates in the US). Credential Engine. Tier 5. https://credentialengine.org/2025/12/09/new-report-finds-1-85-million-credentials-and-opportunities/
- "Over 1 Million Digital Badges on Offer in the U.S." — Inside Higher Ed, 10 December 2025 (badge-volume context). Inside Higher Ed. Tier 6. https://www.insidehighered.com/news/tech-innovation/alternative-credentials/2025/12/10/over-1-million-digital-badges-offer-us
- "An Introduction to Verifiable Digital Credentials" (PDF vs verifiable credential; tamper-evidence; issuer/holder/verifier; wallets). BCdiploma. Tier 6 (orientation). https://www.bcdiploma.com/en/blog/an-introduction-to-verifiable-digital-credentials
- Blockcerts — open standard for blockchain-anchored certificates (optional ledger anchoring; orientation only). Blockcerts. Tier 6. https://www.blockcerts.org/
Per the editorial conflict rule, where vendor marketing equates "blockchain" with "verifiable," this article follows the W3C VC 2.0 model: tamper-evidence comes from the issuer's signature, and a ledger is an optional anchor, not a requirement.
