Open Badge v2 vs v3 Explained: Which Spec Should You Use Today?

If you’re setting up a credentialing program in 2026, you’ll run into this question within the first hour of research: should you issue Open Badge v2.0 or the newer v3.0? The honest answer is “it depends on who has to read your credentials” — but that’s not satisfying if you’re the one who has to decide by Friday. So let’s walk through what actually changed between the two specs, who supports what today, and which one most issuers should ship right now.

What Open Badge v2.0 actually is

Open Badge v2.0 is the 1EdTech (formerly IMS Global) specification that’s been the backbone of digital credentialing since 2017. It’s built on JSON-LD and structured around three linked objects:

• IssuerOrg — who issued the credential (name, URL, email, logo)
• BadgeClass — the credential type itself (name, description, criteria, image)
• Assertion — the specific award to a specific recipient (recipient identity, issuedOn date, evidence, verification method)

A recipient’s Assertion points to a BadgeClass, which points back to an IssuerOrg. Verification happens one of two ways: hosted (the verifier fetches the live Assertion JSON from a stable URL and trusts the domain) or signed (the Assertion carries a JWS signature the verifier checks against the issuer’s published public key). Most platforms, including badges.ninja, default to hosted verification with signed as an option, because hosted is simpler to implement and easier for a human to spot-check.

Here’s a trimmed v2.0 Assertion, the kind of thing you’d get back from a GET /awards/{id} call:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

That structure is why v2.0 has become the de facto standard: it’s simple enough to implement in an afternoon, and it’s what nearly every consumer of badge data expects to see.

Hosted vs signed verification in v2.0

It’s worth understanding the two verification modes inside v2.0 itself, because people often conflate “v2.0 is less secure than v3.0” with “hosted verification is less secure than signed.” They’re not the same axis.

• Hosted — the verification.type is "hosted", and the Assertion’s id is a live URL. A verifier fetches that URL and checks the response matches; trust comes from controlling the domain (e.g., only badges.ninja can publish to badges.ninja/certify-badge/award/<guid>). This is what most consumer-facing verification pages use because a human can just click the link.
• Signed — the verification.type is "signed", and the Assertion carries (or references) a JWS signature over the payload. A verifier resolves the issuer’s public key and checks the signature independent of any URL being reachable. This is closer in spirit to v3.0’s model, just without the DID layer.

A minimal signed-verification check in Node looks like this:

import { jwtVerify, importJWK } from 'jose';
const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

If your program cares about credentials remaining verifiable even after your API goes offline for maintenance, signed v2.0 gets you most of the durability benefit of v3.0 without adopting DIDs.

What Open Badge v3.0 changes

Open Badge v3.0 is a rewrite on top of the W3C Verifiable Credentials (VC) Data Model, not an incremental update to v2.0’s JSON-LD shape. The differences that matter in practice:

• Cryptographic signing by default. Every v3.0 credential is a signed VC — there’s no “hosted, trust the URL” fallback. Verification is always mathematical, not domain-based.
• DID-based issuer identity. Instead of an IssuerOrg object with a URL and email, the issuer is identified by a Decentralized Identifier (DID), which resolves to a public key document.
• Alignment with the Comprehensive Learner Record (CLR) 2.0. v3.0 was designed to interoperate with CLR, so a single credential can carry achievement data plus the kind of structured transcript detail CLR consumers expect (competencies, assessment results, term/course context).
• Digital wallet compatibility. Because v3.0 credentials are standard W3C VCs, they can be held in identity wallets the same way a driver’s license or vaccine credential can — not just displayed on a web page.

In short: v2.0 answers “can a human or a simple script verify this credential,” and v3.0 answers “can this credential interoperate with the broader verifiable-credentials ecosystem — wallets, DIDs, formal learner records.”

Side-by-side comparison

Why the installed base still runs on v2.0

This is the part that tips the decision for most programs: the places your recipients actually want their credentials to show up still expect v2.0. LinkedIn’s Add to Profile flow, Credly, Badgr, and the vast majority of applicant-tracking-system integrations parse v2.0’s Assertion/BadgeClass shape. If your goal is “recipients can post this to LinkedIn and recruiters can click through to verify it,” v2.0 is not a legacy format you’re stuck with — it’s the format the ecosystem currently speaks.

We covered this exact tension from the recipient side in LinkedIn Skill Assessments vs Open Badges — the value of a badge is largely a function of how easily it plugs into the places recruiters and peers already look, and today that’s overwhelmingly v2.0-shaped infrastructure.

When v3.0 actually matters

v3.0 isn’t hype — it solves real problems for specific programs:

• Universities and issuers under CLR mandates. If you’re issuing alongside a formal transcript system, or a state/regional education body requires CLR 2.0-compatible output, v3.0’s built-in alignment saves you from bolting CLR fields onto a v2.0 Assertion.
• Programs targeting digital wallet storage. If your recipients need to hold the credential in a wallet app rather than just display it on a web page, only a W3C VC (i.e., v3.0) will work there natively.
• Cross-issuer credential exchange with DID-based trust. If you’re building or joining a network where issuer identity needs to be cryptographically portable rather than “trust this URL,” DIDs are the right primitive.

None of those are common cases for a training program, bootcamp, or professional-development issuer in 2026. They’re common for institutions with compliance or interoperability requirements that specifically name CLR or W3C VCs.

A trimmed v3.0 credential shows how different the envelope looks, even when the underlying achievement data is conceptually the same award:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

Notice the issuer field is a DID, not a URL, and the whole document carries a proof block instead of a verification pointer. That’s the DID resolution + VC signing tooling mentioned above — real engineering work, and work that’s wasted if nothing downstream actually consumes it yet.

Common misconceptions worth clearing up

• “v3.0 is more secure.” Not necessarily — signed v2.0 and v3.0 both rely on cryptographic verification. v3.0’s advantage is standardized identity (DIDs) and wallet interoperability, not a security upgrade over signed v2.0.
• “v2.0 is deprecated.” It isn’t. 1EdTech maintains both specs, and v2.0 remains the version referenced by the platforms and integrations issuers actually use day to day.
• “You have to pick one for the whole program.” You don’t. Nothing stops an issuer from publishing v2.0 for general use and adding v3.0 output for a specific partner integration that requires it — the underlying award data doesn’t change, only the representation.

The migration path (and why you don’t need to pick forever)

The practical move for almost every issuer: ship v2.0 now, and treat v3.0 as an addition, not a replacement, when a specific downstream consumer demands it. A few reasons this works cleanly:

1. Your BadgeClass and Assertion IDs don’t need to change when you add v3.0 support later — you’re adding a second, differently-shaped representation of the same underlying award, not migrating existing recipients’ credentials.
2. Verifiers that only understand v2.0 keep working exactly as before.
3. You avoid building DID infrastructure and VC signing pipelines before you have a concrete requirement that needs them.

This is the same logic we use internally at badges.ninja: every award goes out as a v2.0 Open Badge — JSON-LD, hosted verification at a stable /certify-badge/award/{guid} URL, LinkedIn Add to Profile ready out of the box — because that’s what covers the overwhelming majority of what issuers are actually asked to produce. If your program later needs v3.0/CLR output for a specific institutional partner, that’s a scoped addition on top of a working v2.0 pipeline, not a rewrite.

That sequencing also protects you from a subtler risk: committing to DID infrastructure before you know which DID method your partners actually expect. The VC ecosystem hasn’t converged on one DID method — did:web, did:key, and ledger-anchored methods all show up in the wild, and picking the wrong one for a pilot partner means redoing issuer-identity work later. Waiting for a named requirement means you find out which method you actually need before you build anything.

A quick gut-check for your own program

Ask these three questions before you spend engineering time on v3.0:

• Does any consumer of my credentials — an employer ATS, a licensing board, a partner institution — explicitly require CLR 2.0 or W3C VC output? If no, v2.0 covers you.
• Do my recipients need to hold this credential in a digital wallet app, not just a web profile or LinkedIn? If no, v2.0 covers you.
• Am I building cross-issuer trust infrastructure where URL-based hosted verification genuinely isn’t sufficient? If no, v2.0 covers you.

If you answered “no” three times, you’re not behind by shipping v2.0 in 2026 — you’re matching the spec to the ecosystem that actually consumes it. Revisit the question when a specific partner or compliance requirement asks for v3.0 by name, not on a general sense that “v3 is newer.”

For more on how badge verification data holds up against older, non-standard credential formats, see Blockchain Certificates vs Open Badges, which digs into the verification and portability trade-offs from a different angle.

---

Ready to issue your first verifiable credential? Start free at badges.ninja — visual designer, public verification page, PDF certificate, Open Badge v2.0 output. No credit card required.