The complete Open Badges 3.0 guide: how it differs from W3C Verifiable Credentials

Open Badges 3.0 is an education credential standard built on top of W3C’s Verifiable Credentials (VC) data model. You’ve probably heard that “it adopted VC,” but what exactly changed, how does it differ from the previous Open Badges 2.0, and why does it matter for the day-to-day work of an educational institution? This piece pulls it all together.

W3C Verifiable Credentials — why did it suddenly show up in education credentialing?

Diagram of the Issuer → Holder → Verifier triangle

W3C Verifiable Credentials (VC) is a digital credential data standard created by W3C, founded by Tim Berners-Lee, the father of the web. It was designed as a general-purpose framework for exchanging real-world credentials — driver’s licenses, degrees, certifications — on the web without tampering. In May 2025, the VC Data Model v2.0 was finalized as an official W3C Recommendation, cementing its place as the foundational specification of the digital credential ecosystem.

The core structure is simple. An Issuer binds a Claim about a Subject with a cryptographic signature to produce a Credential, and the Holder presents it to a Verifier — a three-party model. On top of this, technologies like digital signatures, Decentralized Identifiers (DID), and Selective Disclosure are layered on.

But VC itself is “a general-purpose container that can hold any kind of credential.” To carry educational achievements inside it, you need a specific structure within — a separate metadata specification expressing what achievement was earned, by whom, and against what criteria. That’s exactly the role Open Badges 3.0 plays.

How does Open Badges 3.0 relate to W3C VC?

OpenBadgeCredential class

In one sentence: Open Badges 3.0 is an education credential standard that adopts the W3C VC Data Model as its “foundational specification.” If VC is a general-purpose container, Open Badges 3.0 is the specification for systematically packing educational achievement data inside it.

Concretely, a badge issued under Open Badges 3.0 carries two types at once: VerifiableCredential and OpenBadgeCredential. Verification tooling in the VC ecosystem recognizes the badge as “a valid VC,” while the structure also includes the metadata needed for education credentialing — Achievement (the achievement content), Criteria (the credentialing criteria), Evidence (supporting materials).

For a simple analogy: W3C VC is an internationally standardized passport form, and Open Badges 3.0 defines how to fill in the specific information of an education record on that form. Because the form is the same, it can be read anywhere in the world; because the contents are education-specific, learning achievements can be expressed precisely.

The Open Badges 3.0 spec, managed by 1EdTech (formerly IMS Global), was developed alongside CLR (Comprehensive Learner Record) 2.0. The design also makes it possible to bundle multiple individual badges (OpenBadgeCredential) into a learner’s comprehensive record (CLR) — a design choice made possible precisely because the VC data model sits underneath.

From Open Badges 2.0 to 3.0 — what actually changed

OB 2.0 Hosted/Signed vs. 3.0 VC comparison

Open Badges 2.0 was published in 2017, and 2.1 later added the Badge Connect API. But the fundamental data structure didn’t change much. In 3.0, the adoption of the VC data model brought a transition in the trust model of credentialing itself.

Category | Open Badges 2.0/2.1 | Open Badges 3.0 Data model | Proprietary JSON-LD schema | Based on W3C VC Data Model v2.0 Trust model | Platform hosts the data → platform-dependent verification | Cryptographic signatures → platform-independent verification Recipient identification | Email-centric | DID (Decentralized Identifier), URL, email, etc. Data storage | Dependent on the issuing platform’s server | Can be stored directly in the learner’s digital wallet Selective disclosure | Share the whole badge or nothing | Submit only the needed information via Verifiable Presentation Image requirement | Badge image required (metadata embedded in PNG/SVG) | Image optional (JSON-LD data-centric) Long-term verification | Verification fails if the issuer’s server disappears | Signature-based — verifiable even without the issuer Achievement type | Generic badge | Achievement Type subdivision (microcredentials, certifications, degrees, competencies, etc.)

Among these, the change that most affects institutional operations is the shift in the trust model. In 2.0, checking a badge’s authenticity required hitting the issuing platform’s server. If the platform shut down or modified its data, the trustworthiness of badges already issued was shaken along with it.

In 3.0, the badge itself carries a cryptographic signature, so anyone can independently verify the data integrity at the moment of issuance. To be honest, this is one change many institutions don’t yet feel in practice. But if you think about operating digital badges over five or ten years, it’s a meaningful difference.

Three key 3.0 changes institutions should pay attention to

Selective Disclosure, privacy protection

Enough about the tech spec — let’s look at this from the operational side.

First, learner-centric data ownership. In 2.0, the badge was effectively “stored on” the platform. If the learner left the platform, access to the badge could become difficult. In 3.0, the learner stores the badge directly in a digital wallet and submits it wherever they want. Even if the issuing platform disappears 20 years later, the badge can still be verified.

Second, selective information disclosure. When applying for jobs, you might only need to prove completion — but in 2.0, you had to share the entire badge in one piece. In 3.0, with Verifiable Presentation, the learner can pick and submit only the items they need. Bundling multiple badges into a single presentation is also possible.

Third, real interoperability across borders. Because Open Badges 3.0 shares the VC data model, badges issued under it are recognized immediately by VC-compatible wallets and verification tools. The EU’s digital ID wallet (EUDI Wallet) project is also being built on VC Data Model v2.0, and national digital credential systems are converging on VC as a standard. Cross-border credential interoperability is no longer a distant idea.

Domestic adoption: how far has Open Badges 3.0 come in Korea?

The domestic digital badge market began forming in earnest in 2021. As of 2025, over 200 universities in Korea are using digital badges, and the Human Resources Development Service of Korea operates a service issuing roughly 1,000 types of national technical qualifications as digital badges. The Seoul Metropolitan Office of Education, the Gyeongbuk Office of Education, and the Korea Youth Activity Promotion Institute under the Ministry of Gender Equality and Family are also applying digital badges to education, training, and activity credentialing.

1EdTech TrustEd Apps Directory — “Kolleges” search result

Domestic platforms with Open Badges 3.0 certification are also emerging. Kolleges secured OB 3.0 Issuer certification in 2024, then added Displayer and Host certifications in 2025, completing all three role certifications — issuance, display, and storage. With 2.0 and 2.1 certifications also obtained, the platform has built a structure where previously issued badge assets can be operated and linked continuously without disruption.

Standardized data integration of achievement data is increasingly being required in major government initiatives like RISE (Regional Innovation System & Education), K-MOOC, and the AI & Digital Innovation Leading University program. In this context, Open Badges 3.0 is becoming more than a “version upgrade” — it’s becoming practical infrastructure for inter-institutional data compatibility and long-term trust.

When is the right time for your institution to move to 3.0?

Checklist for deciding when to adopt 3.0

Not every institution needs to switch to 3.0 immediately. But if any of the following applies, it’s time to consider a 3.0-based platform.

If you currently exchange credentials with overseas universities or companies, or plan to. If standards-based metadata data integration is required for reporting on government program outcomes. If you operate programs where learner privacy and data self-determination matter. And if you plan to operate digital badges for five or more years, 3.0’s verification model — which reduces platform dependence — is clearly advantageous from a risk-management standpoint.

If you currently run on 2.0, the safest migration path is choosing a platform that supports both 3.0 and 2.0/2.1. You preserve your existing badge assets while shifting new issuances to 3.0.

Frequently asked questions

Q. Are Open Badges 3.0 and W3C Verifiable Credentials the same thing?

They are not. W3C VC is a general-purpose data model for representing digital credentialing information; Open Badges 3.0 is a specification that layers a metadata structure specialized for education achievement credentialing on top of that VC data model. If VC is the container, Open Badges 3.0 is the education recipe stored inside.

Q. Can badges issued under the existing Open Badges 2.0 be used in 3.0?

Some 3.0-certified platforms support compatibility with 2.0/2.1 badges. However, a 2.0 badge isn’t automatically converted to 3.0 format — platform-level backward compatibility is required. Kolleges has secured certification across all OB 3.0, 2.1, and 2.0 versions, so existing badge assets can be linked and operated as-is.

Q. Concretely, what changes when an institution adopts Open Badges 3.0?

The authenticity of issued badges can be cryptographically verified without depending on a platform, raising long-term trustworthiness. Learners can store badges in a digital wallet and submit only the information they need. And thanks to international standard compatibility, the same credential can be recognized by overseas universities and companies.