How Open Badges fit into verifiable credentials

A university issues a badge for completing a laboratory safety assessment. A student downloads a file, sends it to a placement coordinator, and the coordinator checks it without signing into the university's badge portal. That handoff is the reason Open Badges 3.0 uses the verifiable credential model.

An Open Badges 3.0 credential applies badge-specific rules to a W3C verifiable credential. The W3C model describes who makes a claim, who it concerns, how it can be verified, and how validity or status can be expressed. Open Badges adds the achievement: its criteria, issuer, possible evidence and results, and links to competencies. The difference matters when you have to judge whether the student passed an observed assessment or merely attended a session.

This guide follows that file from issuance to an actual decision. It also covers the things a signature cannot tell you and the dependencies you need to keep alive after changing platforms.

Four questions before you open the file

In the VC model, an issuer makes a claim about a subject. A holder obtains a credential and can share it with a verifier. The subject and holder often refer to the same person, but that must be established rather than assumed. Forwarding somebody else's signed credential does not change its signature. A verifier is the party checking the submitted credential for a specific purpose; that could be a hiring team or the placement coordinator in our example.

At each handoff, ask a different question:

1. Issuer: did an organisation you recognise actually control the key that signed this claim? Check its identity through a source independent of the file.
2. Subject: whom does the credential describe? Determine how its identifier maps to the person in front of you.
3. Holder: what did they submit? Retain the original signed export, not a social-media thumbnail.
4. Verifier: what was checked, when, and for which decision? An old report cannot establish today's withdrawal status.

The model makes sharing possible without requiring the verifier to log into the issuing platform. It does not guarantee an offline check. A verifier may still need to retrieve a public key, JSON-LD context, status list or referenced information. Depending on the presentation channel, the issuer or a service hosting those resources might observe requests. Do not promise recipients invisible verification unless you have examined the actual request path and privacy properties of your deployment.

Read a badge-shaped VC

In a typical Open Badges 3.0 export, @context supplies the vocabularies needed to interpret fields and type identifies the credential kind. issuer identifies the claimant. credentialSubject describes the recipient and includes the achievement. The achievement says what was awarded, while criteria tells the reader what was required. Validity dates, evidence, results, a proof, and a status reference need their own review; presence and form depend on the credential and applicable profile.

Suppose the safety badge says, "Completed laboratory safety training." That sentence supports a completion claim. If a placement requires independently demonstrated safe handling of hazardous materials, ask for the actual rubric or assessment outcome. A valid signature faithfully preserves even a vague claim. It cannot improve the claim's wording.

Inspect the achievement ID and criteria as well as its title. A stable achievement identifier helps distinguish a revised assessment from an older one with the same name. If evidence links point to a private learning platform, record that the work was not accessible to you; do not label the evidence verified. Use a permitted issuer channel for access to sensitive student work. A public evidence URL is not a requirement for a useful badge.

The contexts deserve special attention. A JSON object with issuer and achievement keys is not automatically a conformant Open Badge. The context and types tell software how to interpret those keys; the 1EdTech specification adds constraints beyond the W3C model. When investigating a failure, keep the received bytes untouched. Changing @context, editing a criteria URL or stripping a field to satisfy a validator can alter signed material and invalidate the proof.

Where W3C stops and Open Badges starts

The W3C VC model is intentionally general. It can represent a licence, a diploma or a badge. The Open Badges 3.0 specification narrows this to an achievement credential and defines badge-specific meaning. A generic VC validator can verify a signature while knowing nothing about whether an achievement has the expected structure or whether its criteria answer the reader's question.

Keep those tests separate. Technical validity asks whether the file has a supported structure and a valid proof. Interpretation asks whether the claimed achievement is appropriate evidence for your decision. Institutional trust asks whether you know and accept the issuing organisation. A three-part record is easier to defend than a single "verified" checkbox.

There is another source of confusion: Open Badges 3.0 identifies a badge specification, while VC 1.1 and VC 2.0 identify versions of the underlying credential model. A credential can meet badge-specific expectations while a particular verifier lacks support for its underlying profile or proof. When an issuer says "VC-compatible," request the exact sample and look at the detected profile, proof suite and status mechanism. The Open Badge 3.0 explainer walks through the format difference.

Open Badges 2.x uses a different model: hosted or signed Assertions referencing a BadgeClass and issuer Profile. Some 2.x badges are cryptographically signed; others rely on the issuer continuing to serve the hosted assertion. Do not feed a 2.x assertion to a 3.0-only checker and interpret an unsupported-format result as fraud. Use a validator appropriate to the format.

The proof is a testable claim about a key

An Open Badges 3.0 credential can be delivered in different supported representations. You may encounter a JSON credential with an embedded Data Integrity proof, a compact signed VC-JWT, or a PNG/SVG with credential data baked into the image. The verifier must support the actual representation and cryptographic suite presented; supporting one JWT algorithm does not imply support for every Data Integrity suite, and vice versa.

Decoding a JWT gives you readable claims. Only verification against the intended key and supported algorithm establishes that those protected claims have not changed. Equally, extracting JSON from a baked image finds its contents but does not establish that its proof is valid. A screenshot may preserve the appearance while removing the embedded payload entirely.

When the proof verifies, you know it matched a verification method. Ask where that method is published and whether it belongs to the institution named in the credential. A DID document or key URL is a way to resolve verification material, not an independent guarantee of institutional reputation. For the laboratory badge, find the university's credential programme via its own official domain or an established contact, then compare identifiers. A convincing logo in the file is insufficient.

There is a useful operational test for issuers: sign one real test badge, download it using the recipient's workflow, and ask an independent colleague to verify that exact export. Repeat with a copy whose achievement you intentionally edit. If the edited copy passes as the original, investigate before issuing a cohort. Keep the disposable originals and test outcomes for later migrations.

Status, expiry and the limits of a live check

A signed credential may remain cryptographically intact after its issuer has withdrawn it. Some credentials include a credentialStatus entry that points to a mechanism such as the W3C Bitstring Status List. A verifier following that entry can ask whether the referenced credential is currently revoked or suspended, subject to reachability and tool support. Other credentials have no status entry. That absence means you did not make a live withdrawal check through the credential, not that the credential has never been revoked.

Dates answer a different question. An expired badge can still accurately record a past assessment; it might no longer qualify someone to work unsupervised. A badge without an expiry date is not automatically suspect; a one-off historical achievement may intentionally be permanent. State your use case. For safety clearance, you may need current authorisation under a separate policy even when a past badge verifies.

A useful high-stakes verification note contains the date and time of the check, the original file or a controlled reference to it, the proof result, whether a status source was actually consulted, and any expiry finding. If the list was unavailable, retry later or ask the issuer through a separately verified contact. Never convert "could not check" into "clear."

Holder identity and privacy are design choices

A recipient's printed name is easy to read, but common names collide. Some programmes use an email-derived identifier; others use a DID or another opaque identifier. The signed subject field is the issuer's statement about a subject. It does not authenticate the person who forwarded the file. For a regulated placement, agree on a matching process with the university before accepting badges as the only evidence of identity.

A key challenge can show that someone controls the key named by a holder-binding method. You still need to connect that key to the person. Similarly, a hashed email is only checkable when the issuer supplies matching rules, including any salt or normalisation procedure. Avoid placing full birth dates or private work samples in public credentials simply to make matching convenient. If the badge contains evidence, make access intentional and give recipients clear instructions on what sharing reveals.

Selectively disclosing individual claims is possible with particular VC approaches, but support depends on the issuance format, proof suite, wallet and verifier. Do not tell a recipient that any ordinary signed badge can hide its subject or evidence on demand. Test the exact issuer-to-verifier journey before promising that property. In many programmes, the realistic near-term safeguard is a narrowly worded public credential and access-controlled detailed evidence.

Keep the verification dependencies after the issuer leaves

A saved file reduces dependence on the old vendor dashboard. It may still refer to the issuer's domain, a verification-method URL, contexts and a status service. Rotating keys does not rewrite credentials already issued; those credentials continue to name their old method. Retire a provider only after you have decided who maintains each public dependency and how long old badges must remain independently verifiable.

Assign owners to every verification URL

Give these dependencies an owner rather than treating them as a one-time export detail. A simple register can list each URL, its domain owner, purpose, hosting provider, expected lifetime, escalation contact, and an old badge you can use to test it. Review the register when you rotate a key, change a CDN, or transfer a domain. For a status endpoint, document how often the information changes and how you will alert verifiers to an outage. For a criteria URL, preserve the meaning that applied when the badge was earned; a redesigned website should not silently replace the historical rubric. Set up monitoring from outside the vendor's network, because a service can appear healthy in its own dashboard while being unreachable to recipients elsewhere.

Run the exit drill with an old badge

Try a specific exit drill: issue a badge today, download it, and record every externally fetched URL during an independent check. Disable access to the issuing dashboard, verify the original again, and test an older badge signed by a previous key. If you offer revocation, check a disposable revoked sample. A CSV of badge names and recipient email addresses will not pass this drill. The portability guide gives a more complete handover plan.

A practical decision for the laboratory badge

The coordinator receives the original credential, checks its detected format and proof, checks any available status and dates, and confirms the university's issuer identifier independently. They match the subject to the student through their existing admissions or placement process. Then they read the safety badge's criteria and any assessment result. If the criteria establish training attendance only, they request the current practical assessment required by the placement. If the status service is offline, they record that limitation and wait for an issuer response before allowing unsupervised work.

This process uses the VC model for what it provides: portable claims with independently testable integrity. The final decision still belongs to someone who knows the placement's rules. For the exact specification, start with 1EdTech Open Badges 3.0 and the W3C VC Data Model 2.0. For a concrete check, see how to validate an Open Badge.