What are Open Badges 3.0?

A digital badge is a credential you can earn and share online — a verifiable marker that you completed a course, demonstrated a skill, passed a certification, or reached a milestone. Think of it as the digital cousin of a printed certificate, but with one big upgrade: a badge carries its own evidence inside it.

The catch with most digital badges is that they only mean something inside the system that created them. An Open Badgefixes that. “Open” means it's built to a shared, open specification — so a badge issued on one platform can be read, displayed, and verified anywhere that understands the standard.

An Open Badge is really two things packed together:

• A picture — the badge image a person sees and shares.
• Structured, machine-readable data — who earned it, who issued it, what it represents, the criteria for earning it, when it was issued, and any supporting evidence.

That metadata is what turns a pretty image into a real credential. The Open Badges standard is stewarded by 1EdTech (formerly IMS Global), and it's used across higher education, bootcamps, professional associations, corporate learning and development, healthcare continuing education, and independent course creators.

Open Badges have been around for years. The headline difference between the older 2.0 version and the current 3.0 version comes down to how a badge is verified.

The practical upshot: 3.0 badges are more portable and more trustworthy. They fit into the broader world of verifiable digital identity, they work with credential wallets, and they don't depend on a single vendor staying alive to keep proving they're real.

Open Badges 3.0 doesn't reinvent the wheel — it sits on a more general standard called Verifiable Credentials (VCs), published by the World Wide Web Consortium (W3C), the same body behind core web standards like HTML.

A Verifiable Credential is a standard, tamper-evident way to express any digital claim — a university degree, a professional license, a club membership, or an achievement badge. Every VC has three parts that matter:

• The issuer — who is making the claim.
• The claim (credential subject) — what is being asserted, and about whom.
• The proof — a cryptographic signature that locks the claim to the issuer and makes any tampering detectable.

Because the proof is built in, a verifier(a person, an employer, another platform) can independently confirm three things without phoning the issuer: that the badge really came from the issuer it names, that not a single character has been altered since it was signed, and that it hasn't been revoked or expired. Open Badges 3.0 is simply a specific “profile” of Verifiable Credentials, tailored to describing skills and achievements.

Signing a badge solves half the problem. The other half is: where do you find the issuer's real key to check that signature? If a verifier looks up the key in the wrong place, the whole thing falls apart. This is the question did:web answers.

First, the basics of signing. The issuer holds a private key— a secret only it possesses, used to sign badges (like a wax seal only that organization can stamp). There's a matching public keythat is shared openly and can be used by anyone to confirm a signature is genuine. The private key signs; the public key checks. The math only works if both came from the same pair, and you can't forge a signature without the private key.

did:web is a way of publishing that public key at the issuer's own web domain. “DID” stands for Decentralized Identifier — an open W3C standard for naming an entity in a way that isn't owned by any one company. A did:web identifier is essentially a recipe for a web address. For example:

did:web:incredify.net:issuers:your-slug

https://incredify.net/issuers/your-slug/did.json

At that address sits a small public file containing the issuer's public key. So verifying an Open Badge 3.0 looks like this:

1. 1Read the badge and see which issuer (which did:web identifier) it claims.
2. 2Turn that identifier into a URL and fetch the public file at the issuer's domain.
3. 3Check the badge's signature against the public key in that file.
4. 4Confirm the badge hasn't been revoked or expired.

The crucial part: trust is anchored to the issuer's own domain, not to a vendor. Anyone can fetch the public key directly from the organization that made the badge and verify it themselves — no need to call the issuing platform's servers, ask permission, or “just trust” a middleman. Because the proof lives with the domain, a badge stays provably authentic even if the platform that originally created it ceased to exist. It's decentralized verification, using infrastructure organizations already have: a web domain.

You don't need to run your own cryptography to issue standards-compliant badges. A modern badging platform handles the hard parts — generating and safeguarding signing keys, publishing your did:web document, signing each credential, and giving recipients a place to claim and share it. The typical path looks like this:

1. 1Set up your organization and choose the domain identity your badges will be anchored to.
2. 2Design a badge and define what it represents — its name, description, earning criteria, and the skills it certifies.
3. 3Issue it to one person or to an entire cohort, signed automatically at the moment of issuance.
4. 4Recipients claim and share their badge — no account required — and anyone can verify it.

That's exactly what Incredify does: native Open Badges 3.0 credentials, signed with Ed25519 keys, with verification anchored to your domain via did:web — so your credentials are portable, durable, and provable. Want the deeper how-to? See the full documentation.