OpenBadges started in 2011 as a Mozilla project. It was the first widespread effort to standardize what a digital badge should look like, what it should claim, and how a third party could verify it. Over a decade, it has gone through three major versions, each with different architectural assumptions.
This article focuses on OpenBadges 3.0: what changed, why it changed, and what that means if you are issuing credentials today.
The short version
OpenBadges 3.0, finalized by 1EdTech in 2023, is a badge specification built on top of the W3C Verifiable Credentials Data Model. The badge is a W3C VC with extra fields that describe the badge specifically (image, criteria, alignment).
If you already understand W3C VCs (see What are verifiable credentials?), OpenBadges 3.0 is straightforward: it is a profile of the VC standard for the educational and professional badging use case.
How the three versions differ
The progression of OpenBadges is the progression of the broader credentialing ecosystem.
OpenBadges 1.0 (2013)
The original Mozilla specification. A badge was a JSON file referenced from an image (the image had the JSON URL baked in as metadata). Verification meant fetching the JSON from a URL and checking that the issuer matched.
The architecture worked but had a weakness: if the URL hosting the JSON went down, the badge could no longer be verified. The badge depended on the continued existence of the issuing infrastructure.
OpenBadges 2.0 (2018)
A major revision led by 1EdTech (then IMS Global). The format became proper Linked Data (JSON-LD). Verification still relied on hosted documents, but the standard added structural improvements: more rigorous schemas, better support for evidence and endorsements, alignment to learning standards.
OpenBadges 2.0 is still widely deployed. Most major credentialing platforms still issue 2.0 badges alongside 3.0.
OpenBadges 3.0 (2023)
The version that changed the architecture. A 3.0 badge is a W3C Verifiable Credential. The badge data lives inside the VC’s credentialSubject field. The proof is the VC’s cryptographic signature.
Three things changed with the move:
- Self-contained verification. The badge no longer depends on the issuer hosting a JSON document. The cryptographic proof is part of the badge itself.
- Interoperability with the broader VC ecosystem. A 3.0 badge can be stored in any VC-compatible wallet, verified by any VC verifier, and processed by any tool that consumes VCs.
- Status checking. The badge can be revoked via a standard status list, separate from the badge itself, without invalidating the cryptographic structure.
What a 3.0 badge contains
The badge-specific fields that 3.0 adds on top of the VC envelope:
- achievement: the description of what the badge represents. Name, description, criteria (what someone had to do to earn it), image.
- alignment: links to learning standards or competency frameworks the achievement aligns with.
- results: for badges that include performance data (a score, a level, a rubric outcome), the actual results.
- evidence: links or references to artifacts the recipient produced to earn the badge.
These fields turn a generic VC into a specific kind of credential: an evidence-backed claim of an achievement.
Why it matters for issuers
If you issue badges through a platform that only supports 2.0, your badges are tied to that platform’s hosted verification infrastructure. The badges work as long as the platform stays up and stays agreeable.
If you issue badges as OpenBadges 3.0, your badges are W3C VCs. Recipients hold portable, cryptographically verifiable credentials. The platform you used to issue them becomes optional infrastructure.
For organizations issuing badges for high-stakes purposes (professional certifications, regulated training, formal education), the move from 2.0 to 3.0 is the move from “this works while our platform is current” to “this works indefinitely.”
How Credostar implements OpenBadges 3.0
Credostar issues every credential as a W3C Verifiable Credential by default. When the credential carries badge-shaped data (an achievement, criteria, evidence), it is automatically structured as an OpenBadges 3.0 badge.
Concretely:
- The credential’s
typearray includesOpenBadgeCredentialalong withVerifiableCredential. - The achievement is in
credentialSubject.achievementwith the OB 3.0 fields. - The proof is a standard VC proof, verifiable by any compliant VC verifier (including OB 3.0-specific verifiers).
- The credential is signed by the issuer organization’s dedicated key, managed inside Credostar’s KMS.
The credential renders visually as a branded badge for the recipient, but underneath it is portable structured data they can take anywhere.
Where to go next
Read What are verifiable credentials? for the broader VC architecture. Read Credential types compared to see how badges relate to certificates, licenses, and blockchain-anchored credentials.
To issue OpenBadges 3.0 at scale, apply for early access to the Credostar Design Partner Program.