Open Badges 3.0, Explained for Issuers

The short version

Open Badges 3.0 rebuilt a badge as a verifiable credential. The badge itself did not change: same image, same achievement, same criteria, same issuer. What changed is the container it travels in and the way somebody checks it.

For most organisations issuing badges, that is a change in plumbing rather than a change in what their learners can do. It matters a great deal if you need to interoperate with systems you do not control, and it matters very little otherwise. The section on whether you actually need it is the one to read if you only read one.

What Open Badges is for

Open Badges is a standard maintained by 1EdTech, originally created at Mozilla in 2011. Its purpose is interoperability: a badge issued by one organisation should be collectable, displayable, and checkable by software written by someone else entirely.

Without a standard, every issuer's badge is a private arrangement. A learner holding badges from six providers holds six things that only work in six places. The standard describes the badge in a fixed machine-readable structure, covering what it is called, who issued it, what the criteria were, and who earned it, so any conforming system can read all six.

That is the whole ambition, and it is a good one. It is worth holding onto because it is also the test: if nothing outside your organisation needs to read your badges programmatically, the standard is solving a problem you do not have.

What actually changed in 3.0

Versions 1.0 and 2.0 defined their own format for describing a badge, and their own way of checking one. The common method was hosted verification: the badge pointed at a URL on the issuer's server, and checking it meant fetching that URL and comparing. Simple, and dependent on the issuer's server still being there and still answering.

Version 3.0, published in 2023, stopped defining its own container. A badge became an OpenBadgeCredential: a W3C Verifiable Credential whose subject carries an achievement. The same data model that describes a digital driving licence or a professional membership now describes a badge.

The practical consequence is in the bottom row of that diagram. A verifiable credential carries its own proof, a digital signature checked against a published key, so verification no longer depends on reaching the issuer's server at the moment somebody looks. That is a genuine improvement, and it is most of what 3.0 is.

What the change buys you

Three things, in descending order of how much they will matter to you.

Verification that does not phone home. Under hosted verification, a badge stops being checkable when the issuer's URL stops responding. A domain lapses, a platform migrates, an organisation winds down. A signed credential keeps verifying regardless, because the check is mathematics rather than a lookup.

One data model instead of several. Badges, transcripts, and other credentials now share a structure, which means the tooling built for any of them works for all of them. If you issue more than one kind of thing, this compounds.

Wallets, eventually. The verifiable-credential world assumes learners hold their credentials in a wallet they control rather than in each issuer's platform. That is a meaningful shift in who owns a credential. It is also, honestly, further off in practice than in the literature. Wallet adoption among the people receiving your badges is currently near zero, and planning around it in 2026 is planning for a world that has not arrived.

Two things it is not

It is not blockchain. This is the most persistent misunderstanding, and it costs organisations real money. Verifiable Credentials, and therefore Open Badges 3.0, are verified with public-key cryptography: a signature checked against a published key. No ledger is involved and none is required. Some vendors anchor credentials to a blockchain and describe it as though the standard demanded it. It does not.

It does not make your badge trusted. A conformant badge is a correctly structured badge. It says nothing about whether your assessment was rigorous or your organisation is respected. Standards carry format, not credibility. An issuer nobody has heard of issuing perfectly conformant badges is still an issuer nobody has heard of. Spotting a fake certificate covers how that reads from the receiving end.

Do you actually need it?

Most people searching for this have been told they need Open Badges by somebody who did not explain why. Here is a test that settles it. If you answer yes to any of these, you need the standard. If you answer no to all four, you need verifiable badges, which is a different and much smaller requirement.

• Has an accreditor, regulator, or funder named it? Some programmes are contractually required to issue conformant badges. That is the clearest yes there is, and it is not negotiable.
• Must your badges import into a system you do not control? A partner's platform, a national skills registry, a client's HR system that consumes badge metadata. Interoperability is what the standard is for.
• Do your learners already hold badges from other issuers and expect to collect yours alongside them in one place?
• Are you issuing at a scale where machine-readability is how your badges will mostly be consumed, rather than by people clicking links?

Four noes is the common result, and it is not a failure. What those organisations want is that a learner can share a badge and a stranger can confirm it, which a signed, hosted credential does without any of the standards work. How badges work here covers that version.

What moving costs

If you did answer yes, the cost is worth knowing before you commit. Adopting Open Badges 3.0 is not a setting.

• Key management becomes yours. Signed credentials mean private keys that have to be generated, stored securely, and rotated. A leaked key invalidates the trust in everything signed with it.
• Your achievements need real definitions. The standard expects structured criteria, alignment to frameworks where relevant, and consistent achievement records. Most issuers discover their existing badge descriptions are a sentence and a picture.
• Two versions run in parallel for years. 2.0 badges remain valid and widely supported, so you are supporting both during the transition rather than switching.
• Your vendor has to actually implement it. Ask for the conformance certification, not the marketing page. 1EdTech publishes a register of certified products; "3.0 ready" and "3.0 certified" are different claims.

Where we stand

Plainly: Certifications.ng does not currently issue Open Badges, in any version. Our badges are signed with Ed25519 at issuance and hosted at a permanent verification page, so they deliver the outcome the standard was built to enable: a badge a learner can share and a stranger can check without contacting anyone. They do not carry Open Badges metadata, and a backpack expecting that format will not import one.

We would rather say that here than in a procurement conversation. If a regulator or a partner has named the standard, that is a real requirement and you should weigh it against vendors that hold the certification. If nothing has, the version number is not what stands between your learners and credentials they can use. How we compare with Credly takes the same distinction into a buying decision, and reaches the same conclusion about who should not choose us.

The security page sets out how our signing works and what it does not cover, and verifiable credential covers the difference between having the property and conforming to the specification, which is the distinction this entire subject turns on.