Open Badges 3.0 implementation: what the spec leaves to you
Open Badges 3.0 implementation means signing keys, a hosted revocation list and certification tests. What the spec covers and what it leaves to you.
An Open Badges 3.0 implementation is mostly a signing and hosting job, not a badge-design job. Since the final release in June 2026, every 3.0 badge is also a W3C Verifiable Credential, so you need issuer keys, a way for verifiers to find them, and a revocation list you publish. This post covers what the specification defines, what it leaves to you, and where its own documents disagree.
Open Badges 3.0 implementation starts with a signed credential, not an image
The cover page of the 1EdTech specification reads "Final Release", document version 1.4.5, issued June 29, 2026. Section 1.5 states the change that drives everything else: "Starting with this version of the Open Badges Specification, an Assertion is also a Verifiable Credential (VC) as defined by the Verifiable Credentials Data Model v2.0 specification."
That W3C data model became a W3C Recommendation on 15 May 2025, so the badge standard followed it by just over a year. The vocabulary moved too. The implementation guide describes OpenBadgeCredential as an alias of AchievementCredential, formerly Assertion in OB 2.0, and Achievement as the former BadgeClass. In practice, the object you store and deliver is now a signed credential document, and the image is one of several ways to carry it.
What is Open Badges 3.0, and what does it leave to the implementer?
Open Badges 3.0 is a data model, a REST API and a certification scheme. It is not a validation service. The specification says so directly: "Validating verifiable credentials or verifiable presentations is outside the scope of this specification." It does define what verification includes: that the credential conforms to the specification, that the proof method is satisfied, and that the status check succeeds if a status is present.
Two cautions from the same documents. The implementation guide is informative and, in its own words, "does not include any normative requirements". It also warns that tools "may only show a subset of the checks needed to consider OB/CLR valid". A green tick in a third-party validator is not evidence that you would pass certification.
How to implement Open Badges 3.0: six decisions in the order they bite
The implementation guide's issuer quickstart gives the shortest route to a working issuer. These are the decisions it forces, in the order we would make them.
- Decide where the issuer profile lives. The guide says the issuer "needs to have an associated key referenced from their profile, whether that profile is resolved via a DID or an HTTPS URL". It calls hosting the profile on an HTTPS URL tied to a did:web identifier "an easy choice for a web application".
- Pick the proof format. The guide says: "Either a JWT stack using RSA 256 (or RSA with larger key sizes) or an EdDSA stack using a JSON-LD linked data signature must be used to achieve conformance certification".
- Sign at delivery. According to the guide, "it is not necessary to sign the credential except when delivering it, via download, wallet integration, or OB/CLR REST API". That lets you keep signing in one delivery service rather than in every write path.
- Stand up revocation. The status mechanism is covered in its own section below.
- Choose how recipients get the credential. The guide describes a download option that yields a signed credential, and a REST API for transport. If the recipient presents no DID, it says to leave out credentialSubject.id and "instead include an identifier property referencing a known identifier".
- Run the certification tests. They define what "working" means, and they are covered further down.
One design note from us: choose the key-management route before you choose the algorithm. We have not tested any cloud key service against these suites, so check that yours supports the signature type you pick before you commit to it.
The guide's example and the certification list name different cryptosuites
The implementation guide's example issuer profile uses a verification method of type DataIntegrityProof with the cryptosuite "eddsa-rdf-2022". The certification guide says issuers opting for a Linked Data Proof "must use one of the following supported proof mechanisms": the Data Integrity EdDSA suite with the "eddsa-rdfc-2022" algorithm, or the Data Integrity ECDSA suite with the "ecdsa-sd-2023" algorithm. The names differ by one letter, and only one of them is on the certification list.
The two documents also frame the JWT route differently. The implementation guide accepts a JWT stack with RSA 256 for certification. In the sections of the certification guide we could read in full, only the two Linked Data suites are listed as supported proof mechanisms. We read both pages on 20 October 2026 and both guides are versioned documents that get revised, so check the live text. Until you have, take the suite name from the certification guide, not from the example.
A credential counts as revoked only if its status entry says so
The certification guide is exact about status. A credential is revoked "if the credentialStatus property is present, and the type of the CredentialStatus object is BitstringStatusListEntry, and the statusPurpose of the CredentialStatus object is revocation". It is expired "if the current date and time is after the validUntil".
That ties your implementation to the W3C Bitstring Status List v1.0, a Recommendation dated 15 May 2025. The status list is a separate document you have to publish and keep available. We did not find, in the pages we read, how a status bit is set or cleared, so the process around it is yours to design: who may revoke, how a revocation is recorded, and how quickly the list changes. For an HR or training platform that decision matters more than the encoding does.
The Open Badges 3.0 REST API matters only if you host for other systems
The specification's REST API has five operations: getCredentials, upsertCredential, getProfile, putProfile and getServiceDescription. Its security section lists the OAuth 2.0 Authorization Code Grant, dynamic client registration, token refresh and token revocation. The implementation guide says the API provides "dynamic client registration" to transport credentials, and the certification guide adds that it "uses OAuth 2.0 for authentication and granular resource-based permission scopes". We did not read the scope definitions.
If badges are issued and viewed inside a single application, you may never build this API. The certification guide even has an "Issuer Only" profile for issuers that do not meet its service-consumer write requirements. Build the API when another system needs to push or pull credentials on a learner's behalf.
Open Badges 3.0 vs 2.0 migration means re-issuing, and 2.x is not going away yet
Is Open Badges 3.0 backward compatible with 2.0? We could not confirm that from the sections we read. What the documents do show is a changed model: the old Assertion is now a Verifiable Credential, and the implementation guide lists "Re-issue an OB 2.0 Badge as an OB 3.0 Badge" among its use cases. Plan on re-issuing. The guide also has a section on migrating from OB 2.0, 2.1 and CLR 1.0 that we did not read in full, so read it before you scope the work.
On adoption, the evidence is thin. A vendor blog dated 24 March 2026 says "in 2026, Open Badges 2.0 remains the most widely used and accepted standard for issuing digital badges and certificates", but it gives no figures and no source. 1EdTech's own Open Badges page says it "offers Badge Connect certification for both Open Badges 2.1 and Open Badges 3.0", so the certifier has not retired the 2.x line. We found no published count of products certified for 3.0; the official directory appears to load its listing dynamically, so a count would need the live page. Treat any adoption percentage you see as unsourced until it names a denominator.
Certification asks you to show each role working, on video
The certification guide defines three roles. To certify, you run 1EdTech's conformance test suite, submit the results, and, in the guide's words, "you must be an 1EdTech Digital Credentials and Badges Alliance Member, an 1EdTech Affiliate Member, or 1EdTech Contributing Member". After approval you can claim certification and display the certified logo.
| Role | What it does | What you must show |
|---|---|---|
| Issuer | Creates credentials and delivers them to recipients | Issue a valid 3.0 badge to conformance@imsglobal.org and show on video how a recipient retrieves it |
| Displayer | Displays and verifies badges for viewers | Verify three badges (one valid, one expired, one revoked) and show the verification on video |
| Host | Aggregates and publicly hosts credentials for recipients | Import all formats and prove badge metadata survives export |
One gap worth knowing about: neither guide says an uncertified product may not describe itself as supporting Open Badges 3.0. Certification is a credential you earn, not a licence you need. Whether your buyers ask for it is a commercial question you can answer by asking them.
When Open Badges 3.0 is the wrong choice
If a credential never leaves your platform, a signed record in your own database does the job and avoids the key and status-list work. If you cannot commit to keeping the issuer profile and public key resolvable for as long as the credentials stay valid, a signed badge can become unverifiable, because verification depends on finding the issuer's key. And if a certified vendor already fits your volume, buying that product beats building the signing path yourself. 1EdTech describes its certified products directory as the official listing of products it has certified.
Build when the credential has to be portable and verifiable outside your system, and when your own data, such as training completion or role changes, is the trigger for issuing it.
What we have built, and what we have not
We have not shipped an Open Badges issuer, and we are not claiming to have. What we have built is the kind of platform that would sit on either side of one. Our Nomina HR and payroll platform has 13+ core modules and 5 user roles, and the Škoda Auto sales training platform serves 100+ dealerships. In systems like those, a training completion or a role change is a natural event to issue a credential from.
If you are scoping a credential service, the work sits in enterprise application development and API development and integrations: key custody, a delivery service, a status list and the event wiring to your HR or learning data. Settle two things before anything else, where the issuer profile lives and which proof format you sign with, because every later choice depends on them. Then read the implementation guide's sections on signing and migration on the live page, since those are the parts we could not verify word for word.
Frequently asked questions
Open Badges 3.0 is the 1EdTech standard for digital achievement credentials, issued as a final release, document version 1.4.5, on June 29, 2026. Under it an assertion is also a W3C Verifiable Credential, so each badge is a tamper-evident credential whose issuer can be cryptographically verified.
Implementing Open Badges 3.0 means publishing an issuer profile with a public key, signing each credential when you deliver it, publishing a status list for revocation, and giving recipients a download or API route. The implementation guide calls a did:web identifier an easy choice for web applications.
We could not confirm backward compatibility from the sections we read. The documents do show a changed model: the old Assertion is now a Verifiable Credential, and the implementation guide lists re-issuing a 2.0 badge as a 3.0 badge as a use case, so plan for re-issuing.
The implementation guide says an issuer needs either a JWT stack using RSA 256 or larger, or an EdDSA stack using a JSON-LD linked data signature, to achieve certification. The certification guide separately lists eddsa-rdfc-2022 and ecdsa-sd-2023 for issuers opting for Linked Data Proof.
Under the certification guide's verification rules, an Open Badges 3.0 credential counts as revoked when its credentialStatus is a BitstringStatusListEntry with a statusPurpose of revocation. It counts as expired once the current time passes validUntil. The W3C Bitstring Status List v1.0 became a Recommendation on 15 May 2025.
Open Badges 3.0 certification requires passing 1EdTech's conformance tests for each role you apply for, which are Issuer, Displayer and Host, and holding a qualifying 1EdTech membership. Some tests need video evidence. Neither certification page says an uncertified product cannot claim support.
