Executive summary

Open Badges 2.0 and Open Badges 3.0 solve the same broad problem: they package evidence-rich, shareable digital badges so other systems can verify what someone achieved. But they do it in very different ways. Open Badges 2.0, released by IMS Global in 2018, used a custom JSON-LD badge model built around Assertion, BadgeClass, Profile, IdentityObject, and VerificationObject. Open Badges 3.0, voted Final by 1EdTech in June 2024, redesigns the badge as a W3C-aligned verifiable credential with issuer, credentialSubject, achievement, proof, and credentialStatus. IMS Global itself rebranded to 1EdTech in 2022, which is why official sources now appear on both domains.

That shift matters because Open Badges 3.0 is not just a small feature update. It changes how badge verification works, how digital badges move between platforms, how privacy is handled, and how badges fit into digital wallets, verifiable presentations, and broader credential ecosystems. 1EdTech explicitly notes that badges issued under 3.0 are not conformant to all existing 2.x data-model requirements.

For issuers, Open Badges 3.0 offers better future-proofing, richer metadata, more interoperable badge verification, and more scalable status checking. For earners, it reduces dependence on a single school or work email address, increases control over what they share, and makes credentials easier to store in wallets and present across education and employment contexts.

As of 7 May 2026, public pages indicate support for Open Badges 2.0, Open Badges 3.0, W3C Verifiable Credentials, wallet access, revocation, and API automation. At the same time, the public pages reviewed still show some mixed version messaging, so existing users should treat migration as a phased programme rather than a switch you flip in one day.

This article is based primarily on official Open Badges 2.0 and 3.0 specifications, 1EdTech implementation material, W3C recommendations, and public documentation.

Introduction

If you issue digital badges today, the debate is no longer about whether badges should carry metadata. That question has already been settled. The real issue is whether those badges can be trusted, moved, and re-used across different systems without losing meaning or breaking badge verification. That is where Open Badges 3.0 represents a genuine architectural step forward from Open Badges 2.0.

Open Badges 2.0 was already a serious standard. It introduced JSON-LD as the official model, added embedded criteria and evidence, improved alignment to frameworks, supported endorsements, and provided hosted or signed verification for digital badges. In other words, Open Badges 2.0 was not “basic”; it was the standard that made modern verifiable digital badges mainstream.

Open Badges 3.0 builds on that foundation, but it does so by joining the broader W3C verifiable credentials ecosystem. That move gives badges a more portable security model, better wallet compatibility, support for decentralised identifiers, stronger lifecycle management, and a richer achievement vocabulary that works more naturally with skills frameworks, learner records, and machine-readable verification workflows.

Open Badges 3.0 vs Open Badges 2.0

The table below summarises the biggest differences between Open Badges 3.0 and Open Badges 2.0 based on the official specifications, implementation guide, and W3C standards.

Data model

Open Badges 2.0 badges revolve around an Assertion that points to a recipient, a badge reference to a BadgeClass, and a verification block. Open Badges 3.0 replaces that structure with a verifiable credential model: the credential names an issuer, a credentialSubject, an achievement, and at least one cryptographic proof. This is the single most important technical difference, and it is why 1EdTech warns that 3.0 credentials are not conformant with all 2.x data model requirements.

Security and badge verification

Open Badges 2.0 supported two main verification paths: hosted badges and signed badges. Hosted badges relied on fetching the assertion at its URL, while signed badges used JWS and issuer-linked keys. Open Badges 3.0 moves verification into the Verifiable Credentials model, where a credential must carry at least one proof mechanism to be verifiable. It supports VC-JWT and Linked Data proofs, and the verification flow also considers signature validity, optional refresh, and status checks.

Portability

Open Badges 2.0 was portable mainly through baked PNG and SVG files and hosted badge URLs. Open Badges 3.0 keeps baked images, but it also makes the badge a wallet-friendly credential that can be bundled into comprehensive learner records and verifiable presentations. In practice, that means a badge can travel more naturally between issuers, holders, wallets, and verifiers.

Privacy and identity

Open Badges 2.0 did support hashed recipient identities and even pseudonymous recipient usage, but 1EdTech notes that email addresses were used far more commonly in practice and that this created security, ownership, and continuity problems. Open Badges 3.0 is explicitly designed to support URIs and DIDs, making it easier for learners to use identifiers they can keep beyond a school or employer account. 1EdTech also states that 3.0 gives learners more agency by allowing them to access their achievement data and choose what to share.

Interoperability

Open Badges 3.0 was designed to interoperate with the W3C VC ecosystem and with 1EdTech CLR 2.0. That means a single achievement badge can live next to other credentials in the same wallet and use the same trust primitives. This is a practical difference, not just a standards difference. Education, training, and employment systems can build once around VC-compatible verification flows instead of maintaining a badge-only verifier.

Metadata richness

Open Badges 2.0 already supported embedded criteria, evidence, images, endorsements, multilingual content, tags, and alignments. Open Badges 3.0 expands the model much further with achievementType, creator, related, resultDescription, awardedDate, credentialStatus, refreshService, termsOfUse, and skill assertion use cases. It also uses an extensible achievement-type vocabulary that includes forms such as certification, course, licence, membership, and microcredential.

Issuance workflows

Open Badges 2.0 focused on producing a hosted assertion or a signed assertion and optionally baking it into an image. Open Badges 3.0 still supports text files, web resources, and baked images, but it also standardises secure REST endpoints, service discovery, TLS requirements, and OAuth 2.0 authorisation for exchanging credentials and profiles. That gives vendors and in-house teams a much cleaner integration path.

Revocation and lifecycle

In Open Badges 2.0, hosted badges could be revoked by returning HTTP 410 Gone or a minimal revoked assertion, while signed badges relied on the issuer’s revocation list. In Open Badges 3.0, lifecycle management is modelled through credentialStatus, validFrom, validUntil, and optionally refreshService. The verification rules explicitly support status checks using a bitstring status list, which W3C describes as privacy-preserving, space-efficient, and high-performance. Open Badges 3.0 also introduces an awardedDate field so a credential can be updated without losing the original award date.

Decentralisation

Open Badges 3.0 is more decentralised in two useful ways. First, it can use DIDs for issuers and subjects. Second, it separates the creator of the achievement definition from the issuer of the credential, which opens up shared issuing models and delegated trust patterns. The spec even includes use cases for self-assertion, re-issuing old email-based badges to wallet identifiers, and creator-authorised issuance by a different organisation. That said, decentralisation does not remove the need for trust policies; verifiers still need to decide which issuers they trust.

What it means for issuers and earners

For issuers

Open Badges 3.0 raises the bar. You now need to think in terms of proof formats, identifier strategy, lifecycle status, wallet compatibility, and secure exchange. That is more engineering and governance work than simply publishing a hosted assertion, but it also gives you a stronger and more future-ready badge verification story. Your digital badges become easier to validate outside your own website, which is exactly what employers, partner institutions, and ecosystem apps want.

For earners

Open Badges 3.0 is better suited to long-term ownership because it no longer depends so heavily on an email address tied to one institution. 1EdTech even includes a re-issue use case where an older badge can be reissued to a wallet-controlled identifier after a learner loses access to a school email. In real terms, that improves portability across jobs, degree programmes, and countries.

For employers and verifiers

Open Badges 3.0 is useful because the credential can carry stronger proof, richer context, and clearer status information. A badge can say not only who issued it and when, but also what type of achievement it represents, what it aligns to, what results were achieved, and whether the credential is still valid. That makes digital badges more dependable for hiring, admissions, licensing, and continuing education checks.

How Certopus fits into the Open Badges ecosystem

Certopus currently supports Open Badges 2.0 and W3C Verifiable Credentials, helping organizations issue secure, metadata-rich, and verifiable digital credentials. Through Open Badges 2.0, Certopus enables institutions, academies, communities, and businesses to create digital badges with embedded evidence, criteria, issuer information, skills, and verification support.

The platform also supports features such as credential verification, API automation, LinkedIn sharing, wallet access, revocation, expiry management, and white-label credential experiences. This makes Open Badges 2.0 much more practical for real-world credentialing workflows across education, hiring, certification, and training ecosystems.

Organizations using Certopus today are therefore primarily working within the Open Badges 2.0 framework while still benefiting from broader verifiable credential capabilities offered through W3C VC support.

For teams evaluating future credential infrastructure, Open Badges 3.0 remains an important emerging standard to watch because of its deeper alignment with digital wallets, decentralised identity systems, and the wider W3C Verifiable Credentials ecosystem.

Need more information?

Schedule a demo to learn more about Certopus for your business use case, or if you have any questions, don't hesitate to contact us. We would be delighted to assist you. Finally, if you're on social media, follow us to remain informed about our latest developments and learn more about digital credentials like certificates, badges, and micro-credentials.

💡 Book a demo