Open Badges 2.0 vs 3.0: Key Differences and Migration Guide

If you've been running a badge program on Open Badges 2.0 and you're hearing about Open Badges 3.0, you probably have the same question everyone does: do I need to do anything, and if so, what?

The short answer is that OB 2.0 is not going away tomorrow and your existing badges are still valid. But OB 3.0 represents a meaningful upgrade, not just a minor revision, and understanding the differences will shape decisions about platform selection, recipient experience, and future-proofing your credential program.

This guide covers everything: what actually changed, what it means in practice, and a concrete migration path if you decide to move forward. For the full context on Open Badges themselves, start with What Are Open Badges? Complete Explanation of the Standard, and for the broader credential field, see the Digital Credentials Complete Guide.

Why a new version Was needed

Open Badges 2.0, released in 2018, served the badge ecosystem well. But by the early 2020s, two problems were becoming clear.

Problem 1: Verification depended on the issuer's server. In OB 2.0, badge assertions are hosted at a URL controlled by the issuing platform. If that URL goes down, because the platform shuts down, the issuer stops paying, or infrastructure changes, the badge becomes unverifiable. This is a fragile foundation for credentials that are supposed to last years.

Problem 2: Siloed ecosystems. The digital credential space was fragmenting. Open Badges lived in one ecosystem. W3C Verifiable Credentials (used in enterprise identity, government systems, and decentralized identity) lived in another. Badges couldn't be used in VC wallets. VC systems couldn't read badge metadata. This made interoperability difficult and limited the reach of badge credentials.

Open Badges 3.0 was designed to solve both problems by aligning the badge data model with the W3C Verifiable Credentials Data Model, the emerging global standard for digital credentials.

The 6 key differences at a glance

The data model Change: what it really means

The shift from the OB-specific JSON-LD context to the W3C VC Data Model is the structural foundation of everything else in OB 3.0. Let's unpack what it means in practice.

In OB 2.0, a badge assertion looks like this at a high level: it uses @context: "https://w3id.org/openbadges/v2" and is structured around OB-specific types like Assertion, BadgeClass, and IssuerProfile.

In OB 3.0, the same credential uses @context: ["https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context.json"] and is structured as a VerifiableCredential with a credentialSubject containing the badge achievement data. The issuer becomes the VC issuer. The recipient becomes the credential subject.

This means that any system that can read a W3C Verifiable Credential can now understand an OB 3.0 badge, as long as it also understands the OB 3.0 extension context for badge-specific fields like achievements, criteria, and alignments.

Cryptographic proofs and why they matter

This is a highly important change from a reliability perspective. In OB 2.0, verification requires fetching the badge assertion from the issuer's hosted URL. If the URL is unavailable, verification fails. There is no alternative.

In OB 3.0, every badge is signed with the issuer's private key. The public key is published, either at a URL or via a DID document. Anyone who has the badge can verify the signature locally, without ever contacting the issuer's server. This is called server-independent verification.

Why does this matter? Because credentials are supposed to be long-lasting. A professional certification earned in 2024 should still be verifiable in 2034, regardless of whether the issuing platform is still online. Cryptographic proofs provide that durability. Hosted URLs do not.

OB 3.0 supports two proof mechanisms:

• Linked Data Proofs (LD-Proofs): The proof is attached directly to the JSON-LD credential document. This is the native W3C approach and maintains full JSON-LD semantics.
• JWT VC (JSON Web Token): The credential is packaged as a JWT, signed using standard JWT signing algorithms. JWTs are widely supported in existing developer tooling, making this easier to implement in many contexts.

Recipient Identity: email vs DID

In OB 2.0, recipients are identified by a hashed email address. This works, but it's tied to an email address the person may change, and it relies on a third-party identity provider (the email service) to define the person's identity.

In OB 3.0, recipients can be identified by either:

• Email (with hashing): Same as OB 2.0, still supported for backward compatibility and simplicity.
• Decentralized Identifier (DID): A cryptographically controlled identifier like did:web:alex.example.com or did:key:z6Mk... that the person controls independently of any centralized service.

DIDs are powerful because they're self-sovereign, the holder controls them. If someone changes their email, their DID-based credentials still identify them. If they want to selectively disclose certain credentials to certain verifiers, DID-based systems support that through selective disclosure mechanisms.

For most badge programs today, email-based identity is still perfectly adequate. DIDs are more relevant for high-stakes credentials (professional licenses, academic records) and enterprise deployments where identity portability is a hard requirement.

Interoperability: The big win of OB 3.0

The biggest strategic benefit of OB 3.0 is interoperability with the broader W3C VC ecosystem. What does that unlock?

• Digital wallets: OB 3.0 badges can be stored in any W3C VC-compatible digital wallet, including emerging EU digital identity wallets, enterprise identity solutions, and consumer credential apps. In OB 2.0, recipients are limited to badge-specific platforms.
• Employer verification systems: Enterprise HR systems and ATS platforms that support W3C VC verification can automatically verify OB 3.0 credentials in hiring workflows.
• Academic record systems: Universities building W3C VC-based transcript systems can include OB 3.0 badges in the same verifiable credential portfolio as academic records.
• Government identity infrastructure: As governments build national digital identity systems on W3C VC standards, OB 3.0 credentials can integrate with those systems natively.

Backward compatibility

One of the most common questions: do OB 2.0 and 3.0 work together?

The direct answer is no, they use different data models and different verification methods. A system built to verify OB 2.0 badges cannot verify OB 3.0 badges without being updated. And a system built only for OB 3.0 cannot verify OB 2.0 badges unless it implements both versions.

1EdTech has published conformance certification requirements for OB 3.0, and platforms that achieve conformance certification should handle both versions. Always check your platform's conformance claims before committing to a migration.

Migration Guide: moving from OB 2.0 to OB 3.0

Here's a practical migration framework for organizations currently issuing OB 2.0 badges.

Should You Migrate Now?

Whether to migrate immediately depends on your specific situation. Here's a simple decision framework:

• Migrate now if: Your platform already supports OB 3.0, you issue high-stakes credentials where long-term verifiability matters, or your recipients are asking for VC wallet compatibility.
• Migrate soon if: You're renewing your badge platform contract and can choose an OB 3.0-capable provider, or you're building a new badge program from scratch.
• Wait if: Your current platform doesn't yet support OB 3.0, your recipients have no current need for VC wallet compatibility, and your OB 2.0 program is working well.

The one thing you should do regardless of migration timing: ensure your existing OB 2.0 badges are hosted on infrastructure that will remain stable. The hosted URL dependency of OB 2.0 is its Achilles heel, and you don't want credentials to become unverifiable because your platform changes domains or shuts down a service.