How to Verify an Open Badge 3.0 (OB3) Credential

Open Badge 3.0 credentials are cryptographically signed — which means they can be verified by anyone, without contacting the issuing organization. But knowing how to verify one, and knowing what the results actually mean, isn't always obvious.

This guide covers everything: how to submit a credential for verification, what each check means, and how to interpret results including the less obvious ones.

What OB3 Verification Actually Checks

Verifying an OB3 credential isn't a single yes/no operation. There are five distinct checks, each testing something different:

1. Structure — Does the credential contain all the fields required by the OB3 specification? This includes @context, type, issuer, validFrom, and credentialSubject.achievement. A credential that fails this check wasn't issued correctly.

2. Context — Does the credential declare the right standard? OB3 credentials must reference both the W3C Verifiable Credentials context and the 1EdTech OB3 context. Without these, a verifier can't interpret the credential correctly.

3. Expiry — Is the credential still within its valid period? If an expiry date was set at issuance, this check confirms the credential hasn't passed it. Credentials with no expiry date always pass this check.

4. Issuer resolvable — Can the issuer's identity be confirmed? OB3 credentials reference the issuer via a DID (Decentralized Identifier). Verification fetches the issuer's public key from that DID endpoint. If the endpoint is unreachable, the credential's authenticity can't be confirmed — but this doesn't necessarily mean the credential is fake.

5. Signature — Is the cryptographic signature valid? Using the issuer's public key, verification confirms that the credential was signed by the stated issuer and hasn't been altered since issuance. This is the core trust guarantee of OB3.

How to Verify a Credential

Using the CertLister OB3 Validator

The CertLister OB3 Validator is a free tool that verifies any OB3 JWT credential from any issuer. It runs all five checks and displays results inline — no account required.

There are three ways to submit a credential:

Drop a file — If you have a .jwt file (downloaded from the issuer's verify page or from a badge platform), drag and drop it onto the validator. The file is read locally in your browser and never uploaded to a server.

Paste a credential URL — If you have a link to the credential (such as https://app.certlister.com/api/v1/public/credentials/CERT-123/ob3), paste it into the URL field and click Validate. The validator fetches the credential server-side to avoid browser CORS restrictions.

Paste the JWT string — If you have the raw credential text (a long string of the form xxxxx.yyyyy.zzzzz), paste it directly into the input field. The validator auto-detects JWT strings.

Once submitted, validation runs immediately. The five checks appear one by one as they complete — structural checks are instant, while the issuer and signature checks take a moment to fetch the issuer's DID document.

Reading the Results

VALID

All five checks passed. The credential is structurally correct, not expired, the issuer's identity was confirmed, and the cryptographic signature is intact. This is the strongest possible confirmation of authenticity.

The credential card displays the achievement name, description, criteria, issuer name and logo, recipient email, issue date, and expiry date (if set).

INVALID

One or more checks failed. The most common causes:

• Expired — the credential's expiry date has passed
• Tampered — the signature doesn't match the issuer's public key, meaning the credential was modified after signing
• Structural error — required fields are missing, indicating the credential wasn't issued according to the OB3 spec

An invalid credential should not be accepted as proof of the stated achievement.

UNVERIFIED

The credential's structure, context, and expiry are all valid, but the signature couldn't be checked. This happens when:

• The issuer's server is temporarily unavailable or timing out
• The issuer has changed their domain since the credential was issued
• The issuer uses a DID method that isn't supported (such as did:key or did:ion)

UNVERIFIED does not mean the credential is fake. It means the cryptographic proof couldn't be confirmed right now. If you need certainty, try again later or contact the issuing organization directly.

Common Situations

The credential file won't validate at all

If you see "Not a valid OB3 credential" immediately on upload, check the file format. OB3 JWT credentials are plain text files with a .jwt extension. If you have a .json file, it may be in JSON-LD format — a different OB3 serialization that requires a different validator. Try vc.1ed.tech for JSON-LD credentials.

The issuer check shows a warning about a rotated key

This means the signing key used in the credential is no longer present in the issuer's DID document. Issuers occasionally rotate keys for security reasons. The credential may still be authentic — contact the issuing organization to confirm.

jwt.io shows a key warning

This is expected and not an error. jwt.io expects the iss field to be an HTTPS URL pointing to an OIDC discovery endpoint. OB3 credentials use a did:web DID as the issuer, which jwt.io doesn't understand. Use a purpose-built OB3 validator instead of jwt.io for OB3 credentials.

Other Verification Tools

For Organizations Receiving Credentials

If you're an employer, institution, or training provider receiving OB3 credentials from applicants or participants, the verification process above applies directly.

A few things worth knowing:

The recipient's name is not in the credential itself. OB3 uses the recipient's email address as the identifier (for privacy reasons). The credential proves the email address earned the achievement — not a specific name. Cross-reference the credential's recipient email against the person's submitted contact details.

Valid credentials can't be faked. The cryptographic signature means any modification to the credential after issuance — including changing the recipient name, achievement title, or issuer — breaks the signature and produces an INVALID result. A VALID result is a strong guarantee of authenticity.

Credentials don't expire automatically in a wallet. An expiry date in the credential is informational — it's up to the verifier to decide how to treat expired credentials. Some credentials (like safety certifications) should be treated as invalid after expiry. Others (like degree certificates) are permanently valid and simply don't have an expiry date set.

Issuing OB3 Credentials with CertLister

If you're looking to issue OB3 credentials rather than verify them, CertLister includes OB3 issuance as part of the Pro plan. Every credential you issue can be downloaded as a signed .jwt file from the public verify page.

Recipients can verify their credential with any OB3-compatible tool — including the validator above. No extra setup required.

Start issuing OB3 credentials →