Open Badges and W3C Verifiable Credentials

Open Badges 3.0 is built directly on the W3C Verifiable Credentials data model, which means a badge is no longer a standalone format but part of a wider, interoperable credential ecosystem. That shared foundation is what lets any compatible tool — including our Open Badge validator — check a badge's structure and proof without asking the issuing platform for permission.

That single design decision explains almost everything about how modern badges behave: why they verify offline, why they fit in the same wallets as diplomas and memberships, and why the ecosystem stopped depending on any one vendor staying in business. This article unpacks the relationship properly — what each standard contributes, what actually changed when badges became credentials, and how to tell whether a badge in front of you genuinely is one.

Two standards, one document

Start with the shape of the thing. An Open Badge 3.0 is not a format that resembles a Verifiable Credential, or a format with a VC "export option". It is a Verifiable Credential — one specific, carefully constrained kind:

The division of labor is clean. The W3C Verifiable Credentials data model defines the general container for making tamper-evident claims: who issued it, about whom, valid from when, sealed how, revocable where. It deliberately says nothing about education — the same model carries driving licenses, vaccination records and employee IDs.

Open Badges 3.0, maintained by 1EdTech, is what the VC world calls a profile: a specification that takes the general container and pins down exactly how achievements fit inside it — the Achievement vocabulary, criteria, evidence, alignment to skills frameworks, and the issuer Profile. A profile adds constraints, never contradictions: everything a valid Open Badge does is also valid VC behavior.

The history makes the relationship clearer. Badges predate the VC model — Mozilla launched Open Badges in 2011, a full decade before Verifiable Credentials matured into a W3C Recommendation. For two major versions, badges solved trust on their own, with hosted verification. The 3.0 redesign was a deliberate decision by 1EdTech to stop maintaining a parallel trust system and rebuild on the web's emerging standard — the full history is covered here.

Two vocabularies, one JSON file

You can see the layering directly in any badge's JSON. Some fields come from the VC data model; some come from the Open Badges profile; the document is both at once:

The @context array declares both vocabularies, and the type array claims membership in both worlds:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "https://badges.example.edu/issuer.json" },
  "validFrom": "2026-01-15T00:00:00Z",
  "credentialSubject": {
    "type": ["AchievementSubject"],
    "achievement": {
      "type": ["Achievement"],
      "name": "Data Analysis Fundamentals",
      "criteria": { "narrative": "..." }
    }
  },
  "credentialStatus": { "type": "BitstringStatusListEntry" },
  "proof": { "type": "DataIntegrityProof" }
}

Everything outside credentialSubject.achievement — issuer, validity window, status, proof — is plain VC machinery that any Verifiable Credentials library on earth understands without knowing what a badge is. Everything inside achievement is the educational payload that makes it a badge rather than, say, a gym membership. This is why generic VC tooling can verify a badge's signature while badge-aware tooling additionally understands its meaning.

The @context mechanism deserves a sentence of respect, because it is doing quieter work than it appears to. Both entries are JSON-LD contexts: documents that map every short field name in the credential to a globally unique definition. When a validator reports a context resolution failure, this is what broke — the credential is using words whose meanings can no longer be looked up. It is also why typos in context URLs are fatal rather than cosmetic: a credential whose vocabulary cannot be resolved is not merely misspelled, it is unintelligible to the machines the whole system is built for. The shared contexts are the dictionary that makes one issuer's criteria mean the same thing as every other issuer's.

One model, two envelopes

The VC data model also standardizes how the proof is attached, and badges inherit both options. An embedded proof keeps the credential as readable JSON with a DataIntegrityProof block inside it; a JWT envelope wraps the whole credential as a compact signed token, familiar to any team that has worked with web authentication. The choice is packaging, not security — both are first-class in the standard, both verify independently, and a good validator accepts either without being told which to expect. What matters for interoperability is that these are the same two envelopes used across the whole VC ecosystem, so badge issuers get mature, widely audited signing machinery instead of an education-specific invention. The trade-offs for issuers are covered in the issuing guide.

What actually changed: from hosted to signed

The deepest consequence of adopting the VC model is a change in what "verification" means. Open Badges 2.0 badges were mostly hosted: verifying one meant fetching the assertion from the issuer's server and trusting whatever came back.

Hosted verification had a quiet, structural flaw: the credential was only as alive as the server behind it. A platform shutting down — or just restructuring its URLs — didn't merely break links; it erased the verifiability of every badge it had ever hosted. Recipients held images pointing at a void.

The VC model inverts this. A 3.0 badge carries a cryptographic proof — either an embedded DataIntegrityProof or a JWT envelope — created with the issuer's private key. Verification means checking that signature against the issuer's published public key: pure mathematics plus one HTTP fetch. The issuing platform can vanish; as long as the issuer's profile and keys remain reachable, every badge it signed keeps verifying. Alter one character of the credential and the proof check fails. Trust moved from availability to cryptography — and that is entirely the VC data model's doing.

The trust triangle

The VC model also gave badges a cleaner cast of characters. Every verifiable credential system has the same three roles, and badges inherit them exactly:

The issuer signs the credential once and publishes its keys. The holder — the badge recipient — keeps the credential and decides when and where to present it. The verifier checks the proof and status against public resources, without an account and without asking anyone.

The subtle but important part is the holder's position. In the hosted 2.0 world, the issuing platform sat in the middle of every verification, which meant it could observe — in principle — every time a recipient's badge was checked, by whom, and when. In the VC model the issuer is structurally out of the loop: verification happens between the verifier, the credential and some public key material. Recipients own their credentials in a sense that is technical, not just contractual: the badge works from a file on their own disk, with no login and no platform mediating the relationship. For credentials that follow people across jobs and decades, that property matters enormously.

One wallet, many credentials

Because a badge is a standard VC, it stops living in a category of its own. It sits in the same wallet, and flows through the same verification machinery, as every other credential in a person's life:

This is interoperability in its most concrete form. A wallet does not need a "badge feature"; it needs VC support, and badges come along for free. The same holds across the stack: status checking uses the same Bitstring Status List mechanism as any other credential type, issuer identification can use the same decentralized identifier methods, and the proof suites are shared infrastructure maintained by a community far larger than the education sector alone.

For badge issuers this is a quiet superpower: every improvement the broader VC world ships — better proof suites, better wallets, better selective disclosure — arrives in the badge ecosystem without 1EdTech having to reinvent it. Badges stopped being an island.

Write once, verify anywhere

The practical payoff of all this standards alignment is that a single signed badge becomes legible to a whole landscape of independent systems:

An independent validator can check structure, proof and status. A wallet can import and present it. An HR system can read the skills data out of credentialSubject.achievement — including its machine-readable alignment to skills frameworks — and a learning platform can display it with live verification. None of these systems need a relationship with the issuer, an API key, or each other. The credential is the interface.

Contrast that with the proprietary alternative: a certificate that "verifies" only on the vendor's own website is not a credential, it is a brand experience. The verification button works precisely as long as the vendor's business model does. The VC foundation is what makes the difference testable rather than rhetorical — a real credential verifies on tooling its issuer has never heard of.

How to tell whether a badge is really a VC

Which brings us to the practical question: given a badge, how do you know it genuinely is a Verifiable Credential rather than a JSON file doing an impression of one? Five fields tell the story:

1. @context names both vocabularies — the W3C credentials context and the 1EdTech OB 3.0 context, in that order.
2. type claims both memberships — VerifiableCredential and OpenBadgeCredential.
3. credentialSubject carries an Achievement — the educational payload, with name and criteria.
4. A proof is attached — an embedded DataIntegrityProof or a signed JWT envelope. No proof, no credential.
5. credentialStatus resolves — the revocation mechanism answers when queried.

You do not check these by eye. Paste the badge URL or drop the file into the validator and read the report: context resolution, schema validation, proof verification and status, each pass and fail listed separately. A badge that satisfies all of them is a first-class citizen of the VC ecosystem. A badge that fails the first two was never in the ecosystem at all.

What the shared model does not solve

It is worth being precise about the limits, because standards enthusiasm has a way of overpromising. The VC data model makes a badge tamper-evident, not true. Verification proves that a specific issuer signed a specific claim and has not withdrawn it — it says nothing about whether the issuer's assessment was rigorous, whether the criteria were meaningful, or whether the issuer is anyone you should listen to in the first place.

Those questions remain stubbornly human. Whether a badge for "advanced data analysis" reflects a proctored assessment or a five-minute quiz is decided by the issuer's design choices, not the proof suite — which is why criteria and evidence matter as much as cryptography. And whether an issuer deserves trust is a reputational judgment the ecosystem deliberately leaves to verifiers rather than a central authority. The standard's honest promise is narrower and more valuable: it guarantees you are reading exactly what the issuer said, unaltered, with the issuer's identity cryptographically attached. What you make of what they said is still your call — the machine just makes sure nobody edited the conversation.

What this means in practice

If you issue badges, the VC alignment is now the baseline, not a bonus. Issue Open Badges 3.0 with real proofs and live status, whether through your own pipeline — the issuing guide covers the full lifecycle — or through a credentialing platform such as Certifier, which emits standards-compliant credentials without your team maintaining the cryptographic plumbing. Either way, apply the universal acceptance test: a sample credential must verify on independent tooling before the program launches, and keep verifying as it scales — which is an operational discipline of its own.

If you hold badges, prefer issuers whose credentials pass neutral validation, keep your original files, and know that your badges will outlive any single platform's login page.

If you review badges, never settle for the picture or the vendor's green checkmark. The whole point of the shared standard is that you can check the credential yourself, in seconds, on neutral ground.

A badge that speaks the web's language

The merger of Open Badges and Verifiable Credentials is one of those standards decisions that looks bureaucratic on paper and turns out to be structural in practice. By rebuilding on the W3C model, badges traded a private trust system for the web's shared one — and gained portability, longevity and independence that no education-only format could have sustained alone.

The result is a credential that speaks the web's native language of trust. An Open Badge is no longer something you must take an issuer's word for; it is a mathematical object that any wallet can hold, any system can read, and anyone can verify — today, and long after everyone involved in issuing it has moved on.