Open Badges: the open standard behind verifiable credentials

The standard splits a credential into three parts, and the separation is smarter than it first looks. The Issuer describes who awards it: name, website, contact. The BadgeClass describes what is awarded: the credential's title, description, criteria and image. The Assertion is the individual award: this one person received this BadgeClass on this date.

That way the description of a certificate type only has to exist once, whether you award it to 20 people or 2,000. Here is what a real assertion from our system looks like, with only the token shortened:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

Two details are worth a second look. The badge field is only an address: the BadgeClass lives there, and it in turn points to the Issuer, so a verification tool works its way along the whole chain. And the recipient here is the address of the certificate page; no email address, not even a hashed one, appears anywhere. The public document therefore gets by without any direct contact details. The person's name sits on the linked certificate page, where they entered it themselves when they claimed it.

The specification knows two ways to make an assertion verifiable. With signed badges, the document carries a cryptographic signature from the issuer, so it proves itself, but that requires key management on the issuer's side. With hosted badges a simpler rule applies: the assertion is genuine as long as it can be retrieved at its own id address from the issuer. Verifying then just means requesting the URL and comparing.

The hosted approach has an underrated advantage: the clean revocation. When the issuer withdraws a credential, the same address answers from that point on with HTTP status 410 and a short document carrying the line “revoked: true”. A withdrawn certificate does not simply go quiet, it actively signals that it is no longer valid. That is how we handle it at OneClickBadge too, for instance when a certificate was issued twice by mistake.

One detail of the standard is almost poetic: “baking”. The badge graphic, usually a PNG, gets its assertion together with the verification address embedded directly into the image file, technically as an iTXt text block with the keyword openbadges. The image looks exactly the same afterwards, yet it carries its verification path within it: drop the file into a verification tool and you land at the assertion, no matter how many downloads and chats the image has travelled through.

The order of priority still matters: only the hosted assertion can prove anything. An image can be copied and altered at will, while the answer at the credential's address is controlled by the issuer alone.

Here we clear up the most common misunderstanding that haunts so many articles: LinkedIn does not read Open Badge metadata. There is no badge import, no automatic check, no special icon for verified badges. What LinkedIn has is the profile section “Licenses & certifications” with fields for a name, an issuing organization and a URL. None of that means LinkedIn has certified or endorsed anything.

That does not make the standard useless for LinkedIn, quite the opposite: the verification address belongs in the URL field. When someone clicks “Show credential” in the profile, they land on the certificate page, behind which the verifiable assertion sits. The entry itself can be prepared for recipients in a single click, with the form fields already filled in. What this looks like from the attendees' side is shown in the guide to adding it to your profile.

Implementing the standard yourself pays off for very few organizers: you would need permanently reachable endpoints for the Issuer, the BadgeClass and every single Assertion, plus revocation logic and a baked image. For events, webinars and training courses there is a ready-made route: at OneClickBadge you design an attendance certificate, and every issued copy automatically gets its hosted assertion, the revocation mechanism and the PDF with the image.

Distributing it to many attendees works without a list upload, through a self-service link you share after the event. Why this is also a privacy decision when it comes to credentials is covered on Certificates for many attendees.

Version 3.0 moves the standard onto W3C Verifiable Credentials, a model with cryptographic signatures and more control on the recipient's side. For higher-education ecosystems and long-lived educational records, that is the right direction. For the event-attendance use case, 2.0 in its hosted form is the pragmatic state of play today: every common verification tool understands it, revocation works, and nobody has to manage wallets or keys. That is why we rely on 2.0 hosted and keep watching 3.0 calmly.