Open Badges Standard Explained for LMS Administrators

What is the Open badges standard, really?

The name "Open Badges" gets thrown around constantly in ed-tech conversations, but the actual specification is more precise, and more useful, than most people realize. At its core, Open Badges is a data standard that defines how to package a verifiable claim about a learning achievement inside a digital image or JSON document in a way that any compliant platform can read, verify, and act on.

It was originally developed at Mozilla and later transferred to IMS Global Learning Consortium (now 1EdTech). The specification is freely available and openly licensed. When you issue a badge that complies with this standard, the badge carries its own evidence, you are not just handing someone a pretty graphic, you are delivering a cryptographically verifiable credential.

For LMS administrators, this matters because your learners increasingly expect credentials they can share on LinkedIn, submit to employers, or stack into a portfolio, and that only works if the badges you issue are actually interoperable. A proprietary "certificate image" simply does not travel the same way.

The anatomy of an Open badge: What the data actually contains

Understanding what is inside a badge is the foundation of everything else. Every Open Badge has three core data objects regardless of version:

1. Assertion, the individual instance of the award. It ties a specific learner to a specific badge at a specific point in time.
2. BadgeClass, the template or definition of the achievement. It describes what the badge means, what was required to earn it, and what the criteria URL points to.
3. Issuer Profile, information about the organization or individual who issued the badge: name, URL, contact email, and optionally a public key (in OB 3.0).

In OB 2.0, these objects are expressed as JSON-LD documents hosted at stable URLs. The assertion gets "baked", literally embedded, into a PNG or SVG image file. Anyone who receives the image can extract the JSON-LD from it and resolve the hosted URL to verify it is still valid and has not been revoked.

A minimal OB 2.0 assertion (JSON-LD)

Here is what a stripped-down OB 2.0 assertion looks like:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://example.com/assertions/abc123",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "deadsea",
    "identity": "sha256$c7ef86405ba71b85acd8e2e9568cf8e9a"
  },
  "badge": "https://example.com/badgeclasses/web-dev-fundamentals",
  "issuedOn": "2026-03-16T09:00:00Z",
  "verification": {
    "type": "hosted"
  },
  "evidence": {
    "id": "https://example.com/evidence/abc123",
    "narrative": "Completed a 12-hour course on web development fundamentals."
  }
}

Notice that the recipient's email is hashed with a salt. This is intentional, it protects the learner's privacy while still allowing verification against a known email address. The badge field points to the hosted BadgeClass JSON, and verification.type is hosted, meaning a verifier checks the live URL.

Open badges 2.0 vs. 3.0: the technical comparison

Open Badges 3.0 was finalized by 1EdTech in 2023 and represents the most significant structural change the specification has seen. The shift is not cosmetic, OB 3.0 adopts the W3C Verifiable Credentials (VC) Data Model, which fundamentally changes how verification works and how badges integrate with broader digital identity infrastructure.

How OB 3.0 uses verifiable credentials

The most important conceptual shift in OB 3.0 is that a badge is now an OpenBadgeCredential, a subtype of a W3C Verifiable Credential. This means the data structure, the proof mechanism, and the trust model all align with the broader W3C VC ecosystem, which is also used for government credentials, medical records, and professional licenses.

A Verifiable Credential has three logical parts: the credential itself (what is being claimed), the proof (cryptographic evidence that the issuer actually signed it), and optionally a credential status pointer for revocation checking. Here is a simplified example:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "id": "https://example.com/credentials/ob3/xyz789",
  "issuer": {
    "id": "https://example.com/issuers/acme-corp",
    "type": ["Profile"],
    "name": "Acme Learning Institute",
    "url": "https://example.com"
  },
  "issuanceDate": "2026-03-16T09:00:00Z",
  "credentialSubject": {
    "type": ["AchievementSubject"],
    "achievement": {
      "id": "https://example.com/achievements/data-literacy",
      "type": ["Achievement"],
      "name": "Data Literacy Foundations",
      "description": "Demonstrates foundational competency in data interpretation.",
      "criteria": {
        "narrative": "Must complete 8 hours of coursework and pass a 70% threshold assessment."
      },
      "image": {
        "id": "https://example.com/images/data-literacy.png",
        "type": "Image"
      }
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-16T09:01:00Z",
    "verificationMethod": "https://example.com/issuers/acme-corp#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3MvG..."
  }
}

The proof block is what makes OB 3.0 fundamentally different. A verifier does not need to call a live URL, it can verify the cryptographic signature against the issuer's public key, which can be resolved via DID document or a hosted key file. This works even if the issuer's server goes offline.

Badge baking: What it is and When it matters

"Baking" is the process of embedding assertion metadata into an image file so the badge is self-contained. In OB 2.0, baking is the standard delivery format. The metadata is stored in the image's metadata chunk (PNG uses iTXt chunks; SVG uses an embedded <script> or attribute). When a learner downloads the badge image and shares it, the metadata travels with it.

In OB 3.0, the credential is primarily a JSON-LD document. Baking is still possible, the OB 3.0 spec allows an image claim inside the credentialSubject, but the canonical shareable object is the JSON document itself, not a PNG file. This matters for your LMS because:

• You need to decide whether to offer a downloadable image (OB 2.0 style) or a downloadable JSON credential (OB 3.0 style), or both.
• Learners on older platforms that expect PNG badges may still need an OB 2.0-baked image.
• Newer systems (VC wallets, CLR platforms) expect JSON.

LMS integration patterns: How to actually implement this

There are three realistic paths for getting Open Badges out of your LMS:

1. native LMS Open badges support

Moodle has supported Open Badges since version 2.5 and issues OB 2.0 badges natively. Canvas (via Badgr integration) and some corporate LMS platforms also have built-in badge issuance. The advantage here is tight integration with course completion events, competency frameworks, and gradebook data. The limitation is that native implementations are often OB 2.0 only and may lack OB 3.0 support or advanced evidence handling.

2. lTI-Based integration

Learning Tools Interoperability (LTI) lets you connect your LMS to an external badge issuing service without custom development. When a learner completes a course, the LMS fires an LTI event; the connected tool receives it and issues the badge. This approach is platform-agnostic and is how most enterprise LMS deployments handle badging.

3. aPI-Based integration

For full control over trigger logic, badge metadata, and delivery, a direct API integration is the most flexible option. You hook into your LMS's completion webhooks or event bus and call the badge issuer's REST API. This lets you pass rich metadata, course ID, score, evidence URL, aligned competencies, that the badge carries forward.

Issuing platforms: tools that support the standard

Unless your LMS has solid native Open Badges support with OB 3.0 already built in, you will likely use a dedicated badge issuing service. Here is what to look for and one platform worth noting:

What to look for in an Open badges platform

• OB 2.0 and OB 3.0 support, ideally both, so you are not locked into one version
• API access, for automated, event-driven issuance from your LMS
• Recipient email notification and acceptance workflow
• Revocation controls, ability to revoke individual assertions
• Analytics dashboard, who accepted, who shared, who verified
• Bulk issuance, for course cohorts and event completions

IssueBadge.com

IssueBadge.com is a dedicated digital credentialing platform that supports both Open Badges 2.0 and Open Badges 3.0. It provides an API for LMS integration, bulk issuance, recipient management, and badge analytics. For LMS administrators who need a platform that is explicitly aligned with the 1EdTech Open Badges specification in both versions, IssueBadge.com is a practical option worth evaluating.

Recipient identity and privacy: What you need to get right

One of the most commonly mishandled aspects of Open Badges in LMS deployments is recipient identity. The spec gives you options, and your choice has real privacy implications.

In OB 2.0, the recipient is identified by a type and an identity value. The most common type is email. The spec supports both plaintext and hashed identity. Plaintext is acceptable for some use cases (the learner explicitly consents), but hashed with a salt is far more private and is recommended for most deployments.

The verification flow for a hashed recipient works like this: a verifier takes the email address of the person claiming the badge, appends the known salt, hashes it with SHA-256, and compares the result to the identity field in the assertion. If they match, the badge belongs to that person. The verifier never sees the raw email in the badge data.

In OB 3.0, recipient identity is expressed as an IdentityObject within the credentialSubject, and the spec also supports DIDs (Decentralized Identifiers) as recipient identifiers, enabling fully portable identity that is not tied to an email address.

Revocation: How to un-issue a badge

LMS admins frequently overlook revocation until they need it, usually after a learner's completion is disputed or a record correction is required. The Open Badges standard defines revocation for both versions:

• OB 2.0: The issuer publishes a hosted RevocationList JSON document. Each revoked assertion is listed by ID. Verifiers are expected to check this list.
• OB 3.0: Revocation uses the W3C StatusList2021 mechanism. A credential contains a credentialStatus pointer to a bitstring list hosted by the issuer. Checking is still URL-based, but the format is standardized across the VC ecosystem.

From an LMS admin perspective, what matters is: does your badge issuing platform actually check revocation on verification, and does it allow you to revoke individual assertions without administrative overhead? Both are table-stakes features in any serious implementation.

LMS administrator implementation checklist

Use this checklist when planning or auditing your Open Badges implementation: