Open Badges version decision worksheet
Published by Longsight | September 22, 2026
Guide: https://www.longsight.com/compare/open-badges-2-1-vs-3-0/

Purpose
Use this worksheet to choose a credential format and exchange method after
you test the systems your learners need. It does not replace certification.
Use fictional learner identities and evidence. Keep student records out of
public test files and reports.

Decision and owners
Program / institution:
Decision owner / technical reviewer:
Review date / next review:
Proposed format for new credentials:
Exchange application programming interface (API) or other transfer method:
Supported proof formats and cryptographic suites:
Status method / expiration policy:
Reason to retain an older format or exchange path:
Owner and conditions for retiring each older path:

Required workflows
Complete this section for each receiving application.

Issuer product, version, configuration:
Receiving product, version, configuration:
Independent verifier, version:
Credential format / exchange API / proof / status method:
Credential identifier / SHA-256 checksum of the test file:
Expected achievement, issuer, subject, criteria, evidence, dates:
Transfer / display / export / proof / status results:
Result: PASS / FAIL / NOT TESTED
Evidence location / date / reviewer:
Limitation / person responsible for the fix / deadline:

Acceptance tests with fictional learner data
Run each applicable test in the issuing system and each required receiving
system. Record format, proof, dates, status, and user-visible results separately.
A proof is the cryptographic information used to check a credential's signature.

- Authentic and active: Issue a test credential. Transfer it to a receiving
  system, then download it. Verify it without the issuer's administrator account.
- Expired: Verify a credential after its validity period. Confirm that the
  receiving system reports expiration even if the signature remains valid.
- Revoked: Change status using the issuer's supported method. Verify an already
  downloaded copy. Record how long the receiving system takes to show the change
  and how cached results affect it.
- Suspended: If your institution requires suspension and the system supports
  it, verify before, during, and after suspension. Record whether the receiving
  system reports each state correctly.
- Altered: For a signed credential, change a signed achievement field without
  signing it again. Record the proof failure. For an unsigned hosted 2.0 badge,
  follow the hosted verification procedure instead.
- Missing data: Remove a required field and record the validation failure.
  For JSON-LD (JavaScript Object Notation for Linked Data) credentials, also test
  an undefined term. Record processing failures separately from status results.
- Key rotation: After you rotate a signing key, verify a credential issued with
  the previous key. Retain historical verification material as your policy requires.
- Dependency failure: In a controlled test environment, make a required key,
  status, or hosted-assertion service unavailable. Require an explicit failure
  or indeterminate result. Record whether the system retries the request.
- Platform exit: Transfer records and verify previously issued credentials.
  Record every service still required and who maintains it.

Migration and records
Original credentials retained at:
Reissuance policy and link between old and replacement award:
Historical public keys and discovery URLs maintained by:
Issuer identifiers, status URLs, and evidence links maintained by:
Learner identity mapping and consent reviewed by:
How learners retrieve credentials after graduation or account loss:
Export inventory / format / checksum / retention period:
Accessibility review scope and findings:

Supplier evidence
Claimed certification program / role / product version:
Official listing or registration evidence / checked date:
Independent interoperability report and exact participating versions:
Public source or test evidence and exact revision:
Claims not independently verified:

Approval
If a required workflow fails or remains untested, do not mark it as supported.
Accepted exceptions / owner / expiration date:
Fallback and rollback procedure:
Budget and staffing to support both versions, if required:
Approved transition date / approver / supporting evidence: