Open Badges 2.1 vs 3.0: an institutional decision guide

Separate the credential from the exchange API

Open Badges 2.1 defines the Badge Connect API. Applications use it to move Open Badges 2.0 assertions with the recipient’s authorization. Open Badges 3.0 defines a verifiable-credential model and an exchange API. Ask suppliers which parts they implement. The 1EdTech Open Badges overview explains how the versions relate.

A credential that looks correct in the issuing platform may fail in a recipient’s wallet or verification service. Record four requirements separately: credential format, exchange API, proof format, and status method. A proof is the cryptographic information a verifier uses to check a credential’s signature.

Compare the requirements

The Open Badges 2.0 specification, 2.1 specification, and 3.0 specification define these requirements. Version 2.0 already supports signed badges. Neither version label guarantees that a wallet can accept and verify a credential.

Test the systems your learners use

For a new credential program, start by evaluating 3.0 in the applications your learners need. If a required receiving application depends on 2.0 badges and 2.1 exchange, retain that path until you have a tested replacement.

For each workflow, name the issuer, receiving application, proof verifier, and status service. Create a test credential with fictional learner data that represents your program. Transfer it without administrator access to the issuing platform. Record which fields the receiving application preserves and which checks it performs.

If both versions must remain available, budget for two tested paths. Assign someone to maintain the older path and define the conditions for retiring it.

Inspect the public verification tests

Longsight develops CredTrail. CredTrail’s verification tests check credential format, signatures, dates, and status separately. We reviewed the test source on September 22, 2026. We did not run the tests for this comparison.

The following table maps those checks to tests you still need to run in an independent receiving application. JSON-LD means JavaScript Object Notation for Linked Data, the data format used in these examples.

These tests simulate database and credential-storage responses. They do not establish independent interoperability, production availability, 2.1 support, or certification.

Use the test structure in your procurement requirements. Require separate results for proof, required fields, dates, and current status so you can identify which check failed.

Preserve issued records during transition

Keep the original credential and its supporting records. If you change signed data, the original proof no longer verifies that data. A reissued credential needs a new proof and a documented relationship to the earlier award.

Before you change how you issue credentials, assign responsibility for existing issuer identifiers, public key locations, status services, evidence links, and learner access. Test a sample after you remove the original issuing system from the verification path. If verification still requires a service, record who maintains it and for how long in the contract.

Use the Open Badges governance guide to assign lifecycle responsibilities and the digital credential procurement guide to evaluate supplier evidence. Download the version decision worksheet to record your decision.

Define the tests required for approval

Require each receiving system to distinguish an authentic, active credential from an expired, revoked, altered, or temporarily unverifiable one. If a required network request fails, the system must not report successful verification.

Check the supplier’s current certification evidence against the exact product and role. The Open Badges 3.0 certification requirements include validation and status checks for specific roles. You must also test your content, receiving systems, privacy rules, and accessibility requirements.

Before you approve the transition, record passing results for every required workflow. Assign owners to remaining dependencies and document how they will respond to failures.