Open Badges Specification

Final Release
Spec Version 3.0

Final Release

Document Version:	1.4.3
Date Issued:	April 22, 2026
Status:	This document is made available for adoption by the public community at large.
This version:	https://www.imsglobal.org/spec/ob/v3p0/main/
Latest version:	https://www.imsglobal.org/spec/ob/latest/main/
Errata:	https://www.imsglobal.org/spec/ob/v3p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: https://www.1edtech.org/sites/default/files/media/docs/2023/imsipr_policyFinal.pdf .

The following participating organizations have made explicit license commitments to this specification:

Org name	Date election made	Necessary claims	Type
Concentric Sky	October 24, 2019	No	RF RAND (Required & Optional Elements)
Arizona State University	June 21, 2022	No	RF RAND (Required & Optional Elements)
Temple University	June 10, 2022	No	RF RAND (Required & Optional Elements)
Credly	October 3, 2019	No	RF RAND (Required & Optional Elements)
Workday, Inc.	June 10, 2022	No	RF RAND (Required & Optional Elements)
RANDA Solutions	June 9, 2022	No	RF RAND (Required & Optional Elements)
Anthology	April 16, 2024	No	RF RAND (Required & Optional Elements)
Unicon	April 22, 2024	No	RF RAND (Required & Optional Elements)
Bowdoin College	June 11, 2022	No	RF RAND (Required & Optional Elements)
American Association of Collegiate Registrars and Admissions Officers (AACARO)	April 15, 2024	No	RF RAND (Required & Optional Elements)
Desire to Learn (D2L)	April 16, 2024	No	RF RAND (Required & Optional Elements)
Digital Knowledge EdTech Lab Inc.	April 24, 2024	No	RF RAND (Required & Optional Elements)
IQC Italian Quality Company	April 19, 2024	No	RF RAND (Required & Optional Elements)
Skybridge Skills	April 16, 2024	No	RF RAND (Required & Optional Elements)
Navigatr	April 25, 2024	No	RF RAND (Required & Optional Elements)
T3 Innovation Network, US Chamber of Commerce Foundation	April 25, 2024	No	RF RAND (Required & Optional Elements)
Territorium	April 23, 2024	No	RF RAND (Required & Optional Elements)
Western Governors University (WGU)	June 11, 2022	No	RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: https://www.1edtech.org/standards/specification-license.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions should be directed to [email protected] .

Trademark information: https://www.1edtech.org/about/legal

Abstract

This specification is a new version of the 1EdTech Open Badges Specification that aligns with the conventions of the Verifiable Credentials Data Model v2.0 for the use cases of Defined Achievement Claim and a Skill Claim. The credentials that are produced are easily be bundled into Comprehensive Learner Records and Verifiable Presentations. Portability and learner data privacy are improved by expanding the usage of cryptographic proofs/signatures, because this format will be compatible with a growing array of proof schemas that are developed for the Verifiable Credentials Data Model.

The target readers for this document are:

Business Leaders - the people who are responsible for identifying the business case for using verifiable digital credentials and badges
Solution Architects - the people who are responsible for the definition and design of systems, applications, and tools that are to be used to issue, exchange, and verify digital credentials and badges
Product Developers - the people who are adding functionality to issue, exchange, and verify digital credentials

The Open Badges Specification has several related documents and artifacts shown below. Together they make up the specification.

Open Badges Specification v3.0 ([OB-30]) - The main Open Badges Specification document.
Open Badges Implementation Guide v3.0 ([OB-IMPL-30]) - Provides information to lead you to successful implementation and certification of the Open Badges 3.0 specification.
Open Badges Specification Conformance and Certification Guide v3.0 ([OB-CERT-30]) - Specifies the conformance tests and certification requirements for this specification.

The Open API Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.

-- OpenAPI Specification

When two people communicate with one another, the conversation takes place in a shared environment, typically called "the context of the conversation". This shared context allows the individuals to use shortcut terms, like the first name of a mutual friend, to communicate more quickly but without losing accuracy. A context in JSON-LD works in the same way. It allows two applications to use shortcut terms to communicate with one another more efficiently, but without losing accuracy.

Simply speaking, a context is used to map terms to IRIs. Terms are case sensitive and any valid string that is not a reserved JSON-LD keyword can be used as a term.

-- JSON-LD 1.1

https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json

All JSON Schema can be found in § E.2 JSON Schema. JSON Schema files for credential and API schema verification are available online:

Note

The above schemas are based on the Verifiable Credentials Data Model v2.0. An issuer may also issue credentials following the previous version Verifiable Credentials Data Model v2.0. JSON schema matching that version are:

Verifiers may accept credentials following either schema using Schemas for verification support.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, NOT REQUIRED, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The <a href="#document-set">Conformance and Certification Guide</a> for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

Achievement Type: A vocabulary which describes the type of achievement.
Alignment: An alignment is a reference to an achievement definition, whether referenced in a resource outside the package or contained within the package.
Achievement: This is the content description of a credential that an assertion references. It contains metadata such as the name of the achievement, description, alignment of skills, etc. An Assertion asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.
Assertion: The core of both Open Badges and CLR is the assertion about achievement(s). Assertion properties are specific to one learner's achievement and specify metadata such as issuer, date of achievement, expiration data, as well as results and evidence that support the assertion. A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.
Claim: A statement about the Credential Subject. A claim may include associated evidence, results, or other metadata regarding a specific achievement, skill or assertion.
client: In a REST API, the client is the actor that initiates the DELETE, GET, or POST request. Also called a Consumer in the IMS Global Security Framework v1.1.
Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a verifiable credential.
Credential: A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified.
Credential Subject: Describes the claims being made by the Verifiable Credential. In the context of Open Badges and CLR is typically an individual but in the case of Open Badges, may be another entity type such as a course, book, or organization. Learners, Organizations and other entities can be explicit subclasses of Credential Subjects for purposes of business rules. [vc-data-model-2.0]
Decentralized Identifiers: A type of identifier for people, organizations and any other entity, where each identifier is controlled independently of centralized registries. [did-core] [did-use-cases]
Defined Achievement Claim: An assertion that the learner achieved a specific achievement.
DID URL: A DID plus any additional syntactic component that conforms to the definition in Section 3.2 DID URL Syntax of [DID-CORE]. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).
Evidence: Information supporting a claim such as a URL to an artifact produced by the Learner.
Issuer: The organization or entity that has made an assertion about a Credential Subject. The issuer of a DC Assertion is the authoritative source for that specific assertion.
Learner: The person who is the subject of the CLR and assertions contained in a CLR.
Linked Data Proof: A type of embedded signature proof.
Badge: A single assertion of an achievement that is packaged as a verifiable credential.
Organization: An organized group of one or more people with a particular purpose. [CEDS]
Person: A human being, alive or deceased, as recognized by each jurisdiction’s legal definitions. [CEDS]
Presentation: Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification.
Publisher: The organization or entity issuing the CLR (typically the educational institution or a 3rd-party agent). The publisher is either the issuer or has a trusted relationship with the issuer of all the assertions in the CLR.
Relying Third-Party: Also referred to as the "verifier" of a VC. This entity requests, verifies, and may consume data being presented.
REST API: A style of web API (Application Programming Interface) loosely based on HTTP methods (DELETE, GET, POST, and PUT) to access resources (e.g. CLRs) via a URL.
Result: Describes a possible achievement result. A result may contain the rubric level that was achieved.
Result Description: Describes a possible achievement result. A result description may contain a rubric.
Rich Skill Descriptor (RSD): A machine readable reference to a description of a skill located at a unique URL. [RSD]
Role: People have roles in organizations for specific periods of time. Roles are a time aware association between a person and an organization. [CEDS]
Rubric: Defines levels associated with the achievement definition (e.g. "approaches", "meets", and "exceeds").
server: In a REST API, the server is the actor that responds to a DELETE, GET, or POST request. Also called a Platform in the IMS Global Security Framework v1.1.
Skill: Measurable or observable knowledge, skill, or ability necessary to successful performance of a person.
Skill Assertion: An assertion that contains a "skill result."
Skill Claim: An assertion that the learner has the specified skill.
Subject: A person about which claims are made.
Validation: The process of assuring the verifiable credential or verifiable presentation meets the needs of the verifier and other dependent stakeholders. Validating verifiable credentials or verifiable presentations is outside the scope of this specification.
Verifiable Credential (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [vc-data-model-2.0].
Verifiable Presentation (VP): A tamper-evident presentation of one or more Verifiable Credentials of which cryptographic verification can be used to determine the trustworthiness of the authorship of the data. [vc-data-model-2.0]
Verification: The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.
Verifier: The entity that receives a verifiable credential or verifiable presentation and verifies the credential or presentation has not been tampered with.

This conceptual model describes Open Badges concepts and the relationship between those concepts. The data model in appendix § B.1 Credential Data Models below is the normative reference for the classes and properties that are used to implement the concepts.

The conceptual model is targeted for all § 1.1 Audiences, while the data model is targeted for Solution Architects and Product Developers.

In the diagram below, the concepts are shown in gray boxes (e.g. Assertion). Please see § 1.4 Terminology for definitions of the concepts.

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. The diagram includes labels that show the relationships between VC terminology and Open Badges terminology (e.g. Issuer is identified by the VC "issuer").

Diagram show the major conceptual components of an Open Badge Verifiable Credential — Figure 1 Diagram shows the major conceptual components of an Open Badge Verifiable Credential

I, issuer assert a claim about this Credential Subject that may describe an achievement, experience, membership, etc.,
- The assertion provides the identity of the issuer, issuance date, and instructions on how to cryptographically prove the issuer identity and that the assertion and claim contents have not been tampered with since issuance.
  - The claim must contain a single Credential Subject which identifies the recipient of the Open Badge.
  - The claim may also contain: evidence of the achievement, and other properties supporting the achievement description.
  - The Achievement description is described using properties that may be shared with the CLR including, name, description, criteria, etc.

This section is non-normative.

Verifiable Credentials (VCs) are a format that is used to publish a limitless variety of claims about a subject person or other entity, typically through a cryptographic proof. VCs can be collected and delivered as part of a presentation whereby authorship of each VC from the same or multiple issuers can be trusted via cryptographic verification.

These layers of cryptographic proof can provide security and privacy enhancements to Open Badges that were not available in version 2.0. Adoption of Verifiable Credentials will increase market penetration and use of Open Badges by addressing market needs for trustworthy machine-ready data to power connected ecosystems in education and workforce. This will unlock the door for Open Badges credentials to be included in a growing number of multi-purpose digital credential wallets entering the market. Stepping further into signed VCs and another associated technology, Decentralized Identifiers (DIDs) v1.0, unlocks increased longevity and resilience of Open Badges that can describe achievements even more expressively than they do today.

This specification changes the structure of the Open Badges Assertion class, to adopt the conventions of the Verifiable Credentials Data Model v2.0. This means that badges issued under this specification will not be conformant to all of the existing 2.x data model requirements.

Previous versions of an Open Badges Assertion, illustrated in the graphic below, structures its objects like this: An Assertion identifies a recipient with a "recipient" relationship to an IdentityObject that contains identifying properties. It identifies which badge it represents with a "badge" relationship to a BadgeClass. It identifies its verification information with a "verification" relationship to a VerificationObject. It identifies its issuer with an "issuer" relationship between the BadgeClass and the Issuer.

The Verifiable Credentials structure in this specification depicted below offers the same information with a slightly different structure: A Verifiable Credential identifies its recipient with a "credentialSubject" relationship to a subject class that is identified by an identifier. It identifies its issuer with an "issuer" relationship directly to an Issuer. The Credential claims the subject has met the criteria of a specific Achievement (also known as the BadgeClass in previous versions) with an "achievement" relationship to that defined achievement. And it identifies its verification information with a proof.

It can be risky to make breaking changes to a specification used as broadly as Open Badges, but there are a range of benefits to making this move now while the Verifiable Credentials ecosystem is young and growing fast. There are strong use cases for digital credentials for learning and skill achievements across the nexus of education and employment, as we have seen from the broad adoption of Open Badges and the proliferation of industry groups making connections between educational institutions and the employment market around digital credentials. Technical compatibility is in a more favorable position when faced with rapid ecosystem growth than competition between large communities issuing these learning credentials and other communities focused on different market verticals from government identity documents, commercial payments, and international trade, to name a few.

This specification opens a path forward for a unified concept of digital credentials in the 1EdTech community, collapsing the relevant differences between Open Badges and Comprehensive Learner Record (CLR), and addressing a clear set of single achievement use cases with a robust, flexible, and future-proof solution that can easily be integrated with the set-of-multiple credentials use cases familiar to CLR.

Below, we present a selection of benefits related to this restructuring of Open Badges, and compare the opportunities opened by becoming compatible with Verifiable Credentials to the limitations that the Open Badges community has encountered with previous versions of Open Badges and CLR.

Open Badges as VCs are designed to be issued and offered to learners who may accept them into their digital wallet. Wallets are software that runs on either the web or as a native app on a mobile device or desktop environment. A web wallet is another term to describe the application role known under [OB-20] as a "Host". There is an existing and growing ecosystem of deployed technology to support VCs; integration with these becomes possible with this specification. For example, a number of generic Verifiable Credential wallet implementations are available from a variety of vendors as native mobile apps. From a wallet, recipients may package their badges along with their other VCs into verifiable presentations. A presentation contains the credentials that the learner wishes to share with a relying party. The digital wallet application digitally signs the presentation using the key of the learner. The verifying third-parties can cryptographically verify that the presentation came unmodified directly from the credential holder as well as the integrity of each of the VCs included in the presentation as credentials signed by each of their respective issuers.

It is possible from a wallet to package credentials into a verifiable presentation in response to a request from a relying party who seeks credentials for a certain purpose. For example, a potential employer seeking to fill an internship role, may need to verify that a student is over 18, has completed a course on communication, and is a current student. A student could use their wallet to package three VCs (driver's license, course completion badge, and student ID) into a presentation that is signed by their private key. When the presentation is sent to the employer's website, the employer can verify that the VCs belong to the student and that the VCs are authentic.

The growing collection of VC wallets is an example of how adopting a Verifiable Credentials-based approach allows Open Badges to grow in impact and take advantage of existing momentum in the digital credentials space around tooling that is entering the market and heading towards maturity.

The Verifiable Credentials Data Model v2.0 specification describes how technologies can be used to present cryptographically verifiable and tamper-evident claims. Verifiable Credentials (VCs) can be verified through up-to-date and broadly interoperable schemas for verification. This can provide security and privacy enhancements to 1EdTech Open Badges that are not available in Open Badges 2.0.

Currently, Open Badges 2.0 data can be verified via either (a) publicly accessible hosted JSON badge data or (b) JWS digitally signed badges with a limited number of algorithms and key types, depending on the verification method chosen by the issuer. In order to keep up with evolving cryptographic standards without taking on the burden of writing cryptographic suites as a community not specializing in that function, adopting Verifiable Credentials proofs will allow experts to update algorithms to keep up with improvements to cryptography-breaking processing power.

Publicly hosted badge data has been the preferred method of many Open Badges issuers. This method can risk the privacy of badge recipients who are reliant on the issuers to host their data leaving them with no direct control over its accessibility. There is also the potential that data about individuals is publicly accessible without their knowledge. Most Open Badges don't contain significant amounts of personally identifiable information, but they are subject to correlation. This could lead to on-site identification, email spam, and also cause badges to be correlatable with other personally identifying data on the web.

Hosted badge data is also not tamper-evident since it is hosted on web servers typically as dynamically-generated JSON files populated by queries made to relational databases or static JSON files. This makes the data easy to change without any historic reference or preservation. This can be convenient for issuers but not assuring for relying third-parties seeking to put the data to use. Changes to badge metadata such as criteria, the issue date, and recipient email can reduce the perceived quality of data and reflect incorrect information about the learners' experiences. Digitally signed 2.0 badges provide more assurances and privacy than the hosted badges but are not commonly issued and are not interoperable with VC wallets.

There's been very little evidence that badge JSON data has been readily consumed by machines, but technologies and the education and workforce markets have evolved since Open Badges v2.0 was released in 2018. Machine learning and AI uses have expanded alongside blockchain and other decentralized technologies creating opportunity for connecting learners to opportunities, more accurate skills-based hiring, and updated curricula more equitably reflecting the needs of students. The market is demanding that the achievement data be trustworthy. This means that it should be accessible, protected, have integrity, and communicate what was intended including that the issuer and subjects of the data can be authenticated and that the data has not been tampered with since it was issued. Shifting Open Badges to align with the VC conventions to verify learner achievements meets these expectations and provides learners with more agency over their achievement data by giving them immediate access to it for as long as they need it, allowing them to choose which data they share, protecting it, and making it work with other credentials in and outside of education and workforce.

With Open Badges up to 2.0, email addresses have been used as identifiers far more commonly than the other available options. This has been problematic because email addresses may be used by more than one person, are often revoked when an individual leaves a job or school, are insecure, and aren't intended to be identifiers. Identifiers in VCs commonly are HTTP-based URLs, follow another scheme of IRI, or take the form of a Decentralized Identifier.

Decentralized identifiers (DIDs) [DID-CORE] are a type of identifier for people, organizations and any other entity, where each identifier is controlled independently of centralized registries. Each DID can be resolved through an operation described by its particular "DID Method" to reveal a DID document that describes the subject. Whereas previous versions of Open Badges required HTTP(s) identifiers for issuers and typically used email (or rarely URL) identifiers for learners, adoption of the Verifiable Credentials Data Model provides simple conventions for badge issuers and recipients to begin to use DIDs when they desire.

Verification of control of identifiers is an important concept within any type of digital credential, both with respect to the issuer and the subject (recipient) of the credential. For issuers, Open Badges has relied on its own bespoke rules for determining whether a hosted Assertion URL or cryptographic key URL is associated with an issuer profile identified by a particular URL. URLs used for recipient identifiers have no built-in mechanism for authentication. Email and telephone number based recipient identifier authentication are up to the relying party, but there are common methods for performing this task essential to establishing trusted proof of control of credentials presented by a subject.

DIDs typically offer cryptographic proof of control, based on authorized keys or other verification methods expressed in the associated DID Document. While these protocols are not broadly implemented across domains today, the structure provides a forward-looking flexible and extensible mechanism to build the types of protocols needed to connect credentials back to the identities of their issuers and subjects. The Open Badges community may ultimately recommend use of only a small number of these capabilities in early releases or recommend them only for experimental use, like with cryptographic proof methods. But this is still an important step, because there is no reason for the Open Badges community to be closed to interoperability through the protocols being developed for use by the wallets and services coming into being elsewhere by delaying the option to use DIDs for recipient and issuer identifiers.

As described below, it is possible for Open Badges and CLR to produce coordinated specs particularly if both specs are aligned with Verifiable Credentials. Discussion of the components of individual achievements can occur within the Open Badges workgroup, and discussion of more complex use cases necessitating needs for bundling and association of multiple achievements on behalf of a publisher can occur within the CLR group. The cross-pollination of members of each effort will create opportunities to coordinate and ensure that all important use cases for single assertions and bundles of associated assertions are well-handled. The openness of the Open Badges Specification can be preserved so that the broader community can continue to be aware of and connected to the official developments.

At the core, Open Badges and CLR have similar objectives with the primary difference being single vs a collection of credentials. A common assertion model ensures that Open Badges can be included in CLR collections and that both CLRs and Open Badges can be held separately by learners in their Verifiable Credential wallets.

Both Open Badges and CLR make assertions about achievements and conceptually share many similar properties. With some judicious analysis and renaming of some properties, it has been possible to have cross-alignment of achievement properties served by Open Badges and used by CLR. Examples include but are not limited to achievementType which describes the type of achievement being represented, and Result/ResultDescription which can describe possible levels of mastery associated to specific achievements. This will enrich Open Badges data and increase the perceived significance and usage of Open Badges to deliver verifiable single achievements such as certifications, licenses, courses, etc. Using a common model across [OB-30] and [CLR-20] specifications for the core ideas of assertion and achievement will enable the CLR specification to focus on the more complex requirements of bundling collected assertions and expressing the associations between the achievements.

The core claim enabled by Open Badges v3.0 is that of the AchievementCredential, a Verifiable Credential that makes the claim that a subject (usually a learner), has met criteria an issuer has defined for a named Achievement. Standardizing this method of recognizing an achievement allows for issuers across the education and employment ecosystem to create Verifiable Credentials with consistent properties, so that wallets and verifiers can build broadly reusable software to interpret a wide range of use cases that fit into the defined achievement model. Verifiers of AchievementCredentials that are aware of a specific defined achievement SHOULD ensure that the issued AchievementCredential is issued by an issuer they trust to recognize this achievement, usually the creator of the achievement.

In Open Badges and CLR, the issuer is assumed to be the creator. Over the years, the Open Badges community has requested capabilities to distinguish between the issuer and creator of a badge. This is because there are plenty of examples where the assessor is the issuer but not the creator of the badge. The Original Creator Extensions was a step in this direction but provides no properties to describe the eligibility of issuers trusted by the original creator to duplicate and issue their own assertions of the badge.

In order to open up a wide swath of use cases for shared issuing responsibility of common credentials, we can take advantage of the Verifiable Credentials Data Model to do more. Conveniently, an issuer property for the entity that is digitally signing the credential is included in the VC assertion. We may now separate the issuer from the creator of the Achievement/BadgeClass itself, and in the near term, we may open up use cases for creators to offer verifiable delegation of responsibility for achievement credential issuance. This will enable the use cases and give relying third-parties more contextual information about the achievement and the parties involved. When an Achievement does not include a reference to its creator, verifiers SHOULD interpret it as an entity associated with the credential issuer. Verifiers SHOULD ensure that they trust a particular credential's issuer to recognize the accomplishments described by the Achievement it contains. Verifiers SHOULD NOT trust that an issuer has accurately represented the creator or data of an achievement definition within a credential when that entity is authored by another party, but SHOULD understand that the data within the credential is the data the issuer wished to recognize, even if the verifier encounters a different representation of that data elsewhere.

Many of the use cases for Open Badges and CLR involve an issuer's own "defined achievements", where an issuer bundles the details of an educational opportunity, assessment, and criteria they offer using the Achievement data class. In previous versions of Open Badges, the creator of an Achievement (known as a "BadgeClass") was the only entity that could issue it, but in v3.0, the door opens to many issuers recognizing the same achievement based on their own assessment. This practice of shared achievements enables skill assertions, where multiple issuers use a shared achievement definition to recognize achievement of a skill with each issuer doing their own assessment. In addition, further recording of related skills, competencies, standards, and other associations are enabled by the alignment of an Achievement.

A Skill Assertion is an AchievementCredential asserting a subject holds an Achievement that is used by multiple issuers to recognize the same skill. The content of the Achievement, often with achievementType "Competency", is not specific to a learning opportunity or assessment offered by one specific provider only, but is designed to be generic to allow for assessment by any issuer. Verifiers of AchievementCredentials who are looking for a holder to demonstrate a specific Achievement SHOULD ensure that they trust the issuer of a credential to make this claim, because a credential may be considered valid as issued by any issuer, including self-issuance by the subject.

This section is non-normative.

The use cases below drive the design of Open Badges 3.0 specification.

Maya has completed an online course for an "Introduction to Web QA" at her local community college. The community college issues a course completion assertion. When Maya is ready to accept the assertion, she presents her wallet's location to the community college, which generates a request that Maya approves to receive the credential. Maya stores the assertion in her Verifiable Credentials enabled digital wallet with her other credentials.

Goal of the Primary Actor: Issue a verifiable credential to a student that she can use to take the next steps in her education journey.

Actors: Community college, Maya (student)

Preconditions for this Use Case:

Community college creates badge for course completion
Maya completes the course
Maya downloads and installs a VC enabled digital wallet
Maya has an identifier she uses for educational badges
Maya is able to connect her wallet to the community college's issuing platform (assuming community college is using a platform) through authentication with the platform
The community college has established an issuer profile, relevant cryptographic keys, and has published an Achievement corresponding to completion of the "Introduction to Web QA" course.
Maya has provided an identifier to the college that it has accepted (or controls an identifier that the college has assigned to her)

Flow of Events:

Maya completes course requirements, receives a grade and is marked as complete for the "Introduction to Web QA" course.
Maya provides or selects an identifier to use as her identifier for badges while enrolled at the community college, and proves the identifier represents her to the college if necessary, and through mechanisms appropriate to the identifier type.
The community college issues an assertion of the previously defined achievement to Maya's identifier and cryptographically signs it
Maya accepts the credential into her wallet.

Alternative Flows:

The badge is issued to a parent or guardian of the recipient
1. The school has Maya's parent or guardian identifier on record
2. Maya completes the course
3. The school issues an assertion to the parent or guardian identifier
4. The parent or guardian accepts the credential into their wallet

A professional development/training vendor Training, Inc. recognizes Dawson's mastery of a competency by issuing an assertion to Dawson's email address.

Goal of the Primary Actor: Training, Inc. wishes to provide a verifiable record that Dawson may use to present proof of competency-based professional development.

Actors: Training, Inc (professional development/training vendor), Dawson (student)

Preconditions for this Use Case:

Dawson is authenticated, associated with a particular email address to the vendor's platform.
The vendor has established an issuer profile, defined an Achievement and has the capability to create and deliver assertions to Dawson via Badge Connect

Flow of Events:

Dawson authenticates to the vendor platform, proving control of a chosen email address.
Dawson connects a Badge Connect backpack to the vendor platform, resulting in the platform holding an auth token on his behalf scoped to allow pushing assertions to his backpack.
Dawson engages with a learning opportunity, gains new knowledge, skills, and abilities, and successfully completes an assessment demonstrating mastery of a specific competency.
Training, Inc. creates an assertion of the achievement that recognizes the competency.
Training, Inc. transmits the assertion to Dawson's backpack via Badge Connect API.

Alternative Flows:

Training, Inc. bakes the assertion into a PNG or SVG image file and transmits the image to Dawson who imports the baked badge into his backpack
Training, Inc. encodes the assertion into a QR code transmits the QR code to Dawson who uses the backpack to scan the QR code and import the assertion

Maya registers for an advanced course and she is asked to provide proof that she completed a prerequisite course. From her wallet, Maya presents the course assertion as a verifiable presentation to the MOOC, which cryptographically verifies the issuer of the assertion, that Maya is the recipient, and that the assertion data has not been altered since it was issued. Upon verification, she is registered for the MOOC.

Editor's note

New to v3.0: Verifiable Credentials (VC) is a W3C specification that describes how to issue tamper-evident credentials that can be cryptographically verified. Maya's digital wallet has the capabilities to create a DID, read the VC data, and store it. From the wallet, Maya can present her credentials and prove that she is the recipient because it was issued to a DID that she created and has the digital keys that demonstrates her control of the Verifiable Credential (VC). This functionality is not specific to the Open Badges standard but using this verification functionality and using a decentralized identifier (DID) to identify the badge recipient instead of an email address is part of the v3.0 update. Maya's badge recognizes a course completion and being able to specify that in the badge is a new aspect of v3.0. As with the CLR, v3.0 will be able to specify the type of achievement that a badge is representing.

Goal of the Primary Actor: Register for advanced "Web QA" course

Actors: Maya, MOOC

Preconditions for this Use Case:

Maya completed prerequisite course
Issuer issued a verifiable assertion (i.e. completion of prerequisite course) to Maya
Maya has a VC-compatible wallet
Maya has received the VC representing her competion of the prerequisite course
The MOOC is capable of receiving the verifiable presentation of the badge

Flow of Events:

Maya authenticates to the MOOC platform
The MOOC platform requests a credential matching a certain criteria (completion of a prerequisite course option)
Maya prepares and transmits a presentation of her assertion to the MOOC platform
The MOOC platform verifies the assertion is valid and fitting its needs
The MOOC platform grants the authenticated user Maya access to the advanced course

Points of Failure:

Maya's wallet and the MOOC platform must be capable of establishing a transmission channel for the assertion.
The MOOC platform must be capable of expressing a request for a credential that matches the assertion that Maya holds.
There must be a mutual capability between the wallet and the MOOC platform to prove Maya's is represented by recipient identifier

After Jeremy takes his electrician licensure exam, he accesses the online system for his state's licensure department to see his results and download his license. After he proves his identity by presenting his government issued ID from his digital wallet, he is informed that he passed the exam. The electrician license badge is issued to the DID Jeremy provided and is stored in his digital wallet with his other digital credentials.

Editor's note

New to v3.0: Similar to Maya's course completion badge, Jeremy's electrician license badge is also issued to a DID that Jeremy provides from his wallet and can also be cryptographically verified following the Verifiable Credentials model. The government issued ID in this use case is not an Open Badge but because it is a Verifiable Credential it can be stored in the same wallet as the electrician's license badge demonstrating interoperability of the verification models.

From her school's LMS, Dr. Cara chooses which skills and competencies will be taught in her class. These skills and competencies are aligned with the rubric in the syllabus that is presented to her students. Once the students have successfully completed the course, Dr. Cara assesses each student's assignments and participation and selects which skills and competencies were met and at what level. The selection of skills and competencies triggers an issuing of a skill assertion for each one and includes the assessment results in the evidence and results. The skill assertions are associated with the student's IDs, the students are notified and informed how they can use these skill assessments to inform their choice of classes in the future.

Editor's note

New to v3.0: Single skill assertions are new to 3.0.

Syd is shifting careers after many years working in construction. In their digital wallet they had several skill badges describing their mastery of skills in construction but also in teamwork, communication, and organizational skills. Syd also had badges from some courses they'd taken in science and math over the last few years. After they uploaded the skill and course badges from their wallet to a career planning site, they were offered several opportunities to apply for work in software sales and cybersecurity.

Denise was offered a new job at a hospital as a physician's assistant. Before starting, her continuing education training and license to practice needed to be verified. The last time she switched hospitals, the verification process took three weeks. This time, she was able to provide her badges to prove her training and license. Within minutes her credentials were verified and she was issued a new digital staff credential.

Editor's note

New to v3.0: As with the other use case, this use case emphasizes that Open Badges v3.0 can recognize many different achievement types and be cryptographically verified following the Verifiable Credentials model.

Stacy has created a mobile app that demonstrates her abilities as a coder, designer, and product manager. She creates an account on a badging platform and designs the badge to include alignments to the skills that the badge recognizes. With her digital wallet app, she connects to the badging platform and issues this badge to herself which includes screenshots and a link to the mobile app as evidence. Stacy uses this badge and others like it as verifiable portfolio items.

Editor's note

New to v3.0: In previous versions of Open Badges, it was possible to make self-assertion badges and issue badges to peers, however the issuer profile properties were organization specific. With 3.0, the issue properties can be modified to reference either an organization or an individual. It could be considered that both the issuer and recipient profile have similar optional properties so that there is flexibility in describing both profiles. This way, an organization could also be described as the recipient.

Ralph has been issued a verifiable credential badge for his most recent position at the hospital where he works by the hospital. The badge contains alignments to the skills related to his role. He requests that his peers endorse the skills he has acquired. A platform is able to communicate this request to peers, facilitate review of the skills, and process the issuance of endorsement VC badges that reference the original badge, colleagues as endorsers, and Ralph as the recipient.

Editor's note

New to v3.0: In 2.0, an endorsement is its own type of assertion. In 3.0, an endorsement is its own type of credential. In the example above, the platform verifies the badge data and then acts as an issuer of endorsements on behalf of its users. It could also be that the platform uses AI to process the badge and sends an endorsement back to Ralph as a proof of acceptance and an evaluation of his badge.

Leo earned several badges while in highschool and graduates soon. The email address used as the recipient identity for these badges was an email address provided by his high school and he will no longer have access to it. Leo downloads a digital wallet and requests that the school reissue the badges to the identifier he created in the wallet.

The data model attributes the issuer of a VC and the creator of the badge class separately.

Standards Organization X (SOX) has created a number of badges related to competencies they certify. SOX wants to authorize an accredited, certified training organization (CTO) to issue their credentials. An Open Badge Platform manages the granting of issuing rights to CTO by SOX and can issue verifiable credentials where CTO is the issuer and SOX is the creator inside the badge class.

Employer receives a credential from a graduate. Employer, in addition to verifying the VC in general, can review and verify that SOX did in fact authorize CTO to issue this badge.

Gigantic State University is a badge issuer. It has awarded a badge to a student in the form of a verifiable credential. Some time after issuing the credential, GSU discovers academic misconduct on the part of the student and needs to revoke the credential's status. GSU updates a list of revoked credential IDs, noting the reason why it was revoked. Future verifications of the issued badge by consumers detect that the credential is now revoked and do not erroneously accept it.

Goal of the Primary Actor: Revoke a credential they have already awarded.

Actors: Credential issuer, Credential Subject, Consumer/Verifier

Preconditions for this Use Case:

Issuer creates a badge class
Issuer issues a credential to a subject
Credential references a revocation list
- Uses the credentialStatus property
- OB 3.0 standard comes to consensus on what to use
Issuer has access to a revocation list to update
Verification process of badge credentials checks associated list

An institution has issued hundreds of badges in the form of VCs. A situation has arisen that requires the badge class to be effectively deleted or purged from the ecosystem. It is impractical (and arguably inaccurate) to revoke each assertion with individual records in perpetuity. The institution would like to set a status such that the badge class itself is treated as invalid.

The Open Badges Implementation Guide v3.0 contains non-normative information on how to implement OB 3.0 and CLR 2.0.

Open Badges Specification Conformance and Certification Guide v3.0 - Specifies the conformance tests and certification requirements for this specification.

OpenBadgeCredentials can be exchanged as documents as defined in this section, or by using the Open Badges API. Documents can be exchanged as a text file, a web resource, or embedded in an image. The contents of an Open Badge document MUST meet the following criteria:

The contents of the file MUST represent exactly one OpenBadgeCredential
The OpenBadgeCredential MUST be serialized as JSON and JSON-LD (see § A. Serialization)
JSON exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].

Example 1: Sample OpenBadgeCredential file contents

Credential
Verifiable Credential (with proof)
Verifiable Credential (as JWT)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": ["Profile"],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Example University Degree",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": ["AchievementSubject"],
    "achievement": {
      "id": "https://example.com/achievements/21st-century-skills/teamwork",
      "type": ["Achievement"],
      "criteria": {
        "narrative": "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."
      },
      "description": "This badge recognizes the development of the capacity to collaborate within a group environment.",
      "name": "Teamwork"
    }
  },
  "credentialSchema": [{
    "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
    "type": "1EdTechJsonSchemaValidator2019"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Example University Degree",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "AchievementSubject"
    ],
    "achievement": {
      "id": "https://example.com/achievements/21st-century-skills/teamwork",
      "type": [
        "Achievement"
      ],
      "criteria": {
        "narrative": "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."
      },
      "description": "This badge recognizes the development of the capacity to collaborate within a group environment.",
      "name": "Teamwork"
    }
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2026-04-22T07:26:15Z",
      "verificationMethod": "https://example.edu/issuers/565049#z6MkhAVi8Yz4Fgd6piuHZuaKarYDcGGWdoy19JbLSxax6zUB",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z3V6yzJtjy9PFHp6yAvkzYRZyLMkTSwnz2dWkWdiKWVSdnQg989c78YpDpxbK1FB2GRRqfnbGe78fi6pFFXzijyq6"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "qJSN6vwVq77UbrOLOesWb_wFY9bsbcPcJWe56fkpGVdZn01s4F6lmf6wET2cBOz3BKt4ZC
DG5_XfG34PyqwNqT_-WdQp_GRhOacKkv4lBVjbHPuM7Qf6Na0IDV_LqKJ-jNe2F4v3LoV0Hp8uHv5gaF
86SO8YLbEdNsu6X2zcoRtWRC_Pc6wxTUy1xNoC86jmoU2c0F0JaYtyUNjUr-aTPEubkCOeMCn6WRsWHz
x0WigUk1Er5Fm-3ZbYTnOHyoT34xLW9drMV6xQCRvRqPWRkrfRjQRxStBolfm6xaqV6LM9v-M4fCnXoe
SHgDqj3H43kNn61yPY1qzeWuyyfOTnoQ"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Example University Degree",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "AchievementSubject"
    ],
    "achievement": {
      "id": "https://example.com/achievements/21st-century-skills/teamwork",
      "type": [
        "Achievement"
      ],
      "criteria": {
        "narrative": "Team members are nominated for this badge by their peers a
nd recognized upon review by Example Corp management."
      },
      "description": "This badge recognizes the development of the capacity to c
ollaborate within a group environment.",
      "name": "Teamwork"
    }
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achieve
mentcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "iss": "https://example.edu/issuers/565049",
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJxSlNONnZ3VnE3N1Vick9MT2VzV2Jfd0ZZOWJzYmNQY0pXZTU2ZmtwR1ZkWm4wMXM0RjZsbWY2d0VU
MmNCT3ozQkt0NFpDREc1X1hmRzM0UHlxd05xVF8tV2RRcF9HUmhPYWNLa3Y0bEJWamJIUHVNN1FmNk5h
MElEVl9McUtKLWpOZTJGNHYzTG9WMEhwOHVIdjVnYUY4NlNPOFlMYkVkTnN1NlgyemNvUnRXUkNfUGM2
d3hUVXkxeE5vQzg2am1vVTJjMEYwSmFZdHlVTmpVci1hVFBFdWJrQ09lTUNuNldSc1dIengwV2lnVWsx
RXI1Rm0tM1piWVRuT0h5b1QzNHhMVzlkck1WNnhRQ1J2UnFQV1JrcmZSalFSeFN0Qm9sZm02eGFxVjZM
TTl2LU00ZkNuWG9lU0hnRHFqM0g0M2tObjYxeVBZMXF6ZVd1eXlmT1Rub1EifX0.eyJAY29udGV4dCI6
WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwuaW1zZ2xv
YmFsLm9yZy9zcGVjL29iL3YzcDAvY29udGV4dC0zLjAuMy5qc29uIiwiaHR0cHM6Ly9wdXJsLmltc2ds
b2JhbC5vcmcvc3BlYy9vYi92M3AwL2V4dGVuc2lvbnMuanNvbiJdLCJpZCI6Imh0dHA6Ly9leGFtcGxl
LmVkdS9jcmVkZW50aWFscy8zNzMyIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIk9wZW5C
YWRnZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJz
LzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5In0sInZh
bGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSBE
ZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2
ZjFjMjc2ZTEyZWMyMSIsInR5cGUiOlsiQWNoaWV2ZW1lbnRTdWJqZWN0Il0sImFjaGlldmVtZW50Ijp7
ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9hY2hpZXZlbWVudHMvMjFzdC1jZW50dXJ5LXNraWxscy90
ZWFtd29yayIsInR5cGUiOlsiQWNoaWV2ZW1lbnQiXSwiY3JpdGVyaWEiOnsibmFycmF0aXZlIjoiVGVh
bSBtZW1iZXJzIGFyZSBub21pbmF0ZWQgZm9yIHRoaXMgYmFkZ2UgYnkgdGhlaXIgcGVlcnMgYW5kIHJl
Y29nbml6ZWQgdXBvbiByZXZpZXcgYnkgRXhhbXBsZSBDb3JwIG1hbmFnZW1lbnQuIn0sImRlc2NyaXB0
aW9uIjoiVGhpcyBiYWRnZSByZWNvZ25pemVzIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgY2FwYWNpdHkg
dG8gY29sbGFib3JhdGUgd2l0aGluIGEgZ3JvdXAgZW52aXJvbm1lbnQuIiwibmFtZSI6IlRlYW13b3Jr
In19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZCI6Imh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3Nw
ZWMvb2IvdjNwMC9zY2hlbWEvanNvbi9vYl92M3AwX2FjaGlldmVtZW50Y3JlZGVudGlhbF9zY2hlbWEu
anNvbiIsInR5cGUiOiIxRWRUZWNoSnNvblNjaGVtYVZhbGlkYXRvcjIwMTkifV0sImlzcyI6Imh0dHBz
Oi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3Jl
ZGVudGlhbHMvMzczMiIsInN1YiI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSJ9.BLFe87pQ1FrIMhMU_md6QElR6bour1egRffobq01-e3VWEtSOqXilQcKVh22gOInCeeGDpT0f2Y
brkP7KGLJfSls1Loju-BxFZzCD-H83XS7OpscIA1QS4eM8XWrj8SIdb9h06bEYiuHtWMJAQC6x9PWZk7
mmcKKGalOx4KhjY6dmylbXqQQyx05LsWTzuk-PmlfQPi-9KvphIqNGVrGle_32doIPqhzKue3T07xt_v
HG_rjPDbLMqhWq9oNKgTFGZk75NM3I2FBcVd6TGuPSzizLSuCxTt27AIFJy-rpyjXvIvRs_Anv1Ki-3R
VkdrfBcQK0_GmcDB8vxAQhT1KXQ

If the credential is signed using the § 8.2 JSON Web Token Proof Format (VC-JWT) the contents of the file MUST be the Compact JWS string formed as a result of signing the OpenBadgeCredential with VC-JWT. The file extension SHOULD be ".jws" or ".jwt".

If an embedded proof method is used instead, the contents of the file MUST be the JSON representation of the OpenBadgeCredential. The file extension SHOULD be ".json".

If the credential is signed using the § 8.2 JSON Web Token Proof Format (VC-JWT) the contents of the response MUST be the Compact JWS string formed as a result of signing the OpenBadgeCredential with VC-JWT. The Content-Type SHOULD be text/plain.

If an embedded proof method is used instead, the contents of the response MUST be the JSON representation of the OpenBadgeCredential. The Content-Type SHOULD be application/vc+ld+json, although generic representations such application/ld+json or application/json are also allowed.

OpenBadgeCredentials may be exchanged as image files with the credential encoded (baked) within. This allows the credential to be portable wherever image files may be stored or displayed.

"Baking" is the process of taking an OpenBadgeCredential and embedding it into the image, so that when a user displays the image on a page, software that is Open Badges aware can automatically extract that OpenBadgeCredential data and perform the checks necessary to see if a person legitimately earned the achievement within the image. The image MUST be in either PNG [PNG] or SVG [SVG11] format in order to support baking.

An iTXt chunk should be inserted into the PNG with keyword openbadgecredential.

If the credential is signed using the § 8.2 JSON Web Token Proof Format (VC-JWT) the text value of the chunk MUST be the Compact JWS string formed as a result of signing the OpenBadgeCredential with VC-JWT. Compression MUST NOT be used.

Example 2: An example of creating a chunk with VC-JWT proof (assuming an iTXt constructor)

var chunk = new iTXt({
  keyword: 'openbadgecredential',
  compression: 0,
  compressionMethod: 0,
  languageTag: '',
  translatedKeyword: '',
  text: 'header.payload.signature'
})

If an embedded proof method is used instead, the text value of the chunk MUST be the JSON representation of the OpenBadgeCredential. Compression MUST NOT be used.

Example 3: An example of creating a chunk with embedded proof (assuming an iTXt constructor)

var chunk = new iTXt({
  keyword: 'openbadgecredential',
  compression: 0,
  compressionMethod: 0,
  languageTag: '',
  translatedKeyword: '',
  text: '{
          "@context": [
            "https://www.w3.org/ns/credentials/v2",
            "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
          ],
          "id": "http://example.edu/credentials/3732",
          "type": ["VerifiableCredential", "OpenBadgeCredential"],
          "issuer": {
            "id": "https://example.edu/issuers/565049",
            "type": "Profile",
            "name": "Example University"
          },
          "validFrom": "2010-01-01T00:00:00Z",
          "credentialSubject": {
            "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
          },
          "proof": { }
        }'
})

An iTXt chunk with the keyword openbadgecredential MUST NOT appear in a PNG more than once. When baking an image that already contains credential data, the implementer may choose whether to pass the user an error or overwrite the existing chunk.

Parse the PNG datastream until the first iTXt chunk is found with the keyword openbadgecredential. The rest of the stream can be safely discarded. The text portion of the iTXt will either be the JSON representation of a § B.1.2 AchievementCredential or the Compact JWS string that was the result of signing the OpenBadgeCredential with § 8.2 JSON Web Token Proof Format.

First, add an xmlns:openbadges attribute to the <svg> tag with the value "https://purl.imsglobal.org/ob/v3p0". Directly after the <svg> tag, add an <openbadges:credential> tag.

If the credential is signed using the § 8.2 JSON Web Token Proof Format (VC-JWT) add a verify attribute to the <openbadges:credential> tag. The value of verify attribute MUST be the Compact JWS string formed as a result of signing the OpenBadgeCredential with VC-JWT.

Example 4: An example of a well baked SVG with VC-JWT proof

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:openbadges="https://purl.imsglobal.org/ob/v3p0"
  viewBox="0 0 512 512">
  <openbadges:credential verify="header.payload.signature"></openbadges:credential>

  <!-- rest-of-image -->
</svg>

If an embedded proof method is used instead, omit the verify attribute, and the JSON representation of the OpenBadgeCredential MUST go into the body of the tag, wrapped in <![CDATA[...]]>.

Example 5: An example of a well baked SVG with embedded proof

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:openbadges="https://purl.imsglobal.org/ob/v3p0"
  viewBox="0 0 512 512">
  <openbadges:credential>
    <![CDATA[
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
        ],
        "id": "http://example.edu/credentials/3732",
        "type": ["VerifiableCredential", "OpenBadgeCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": "Profile",
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
        },
        "proof": { }
      }
    ]]>
  </openbadges:credential>

  <!-- rest-of-image -->
</svg>

There MUST be only one <openbadges:credential> tag in an SVG. When baking an image that already contains OpenBadgeCredential data, the implementer may choose whether to pass the user an error or overwrite the existing tag.

Parse the SVG until you reach the first <openbadges:credential> tag. The rest of the SVG data can safely be discarded.

Open Badges can be exchanged using the API (application programming interface) defined here, or as documents.

This specification defines a RESTful API protocol to be implemented by applications serving in the roles of Client and Resource Server. The API uses OAuth 2.0 for authentication and granular resource-based permission scopes. Please see the Open Badges Specification Conformance and Certification Guide v3.0 for a list of which endpoints must be implemented for certification.

Note: Non-individual access

The API defined here is intended for Clients and servers that give individual users control over access to their resources. While system-to-system bulk transfers using OAuth 2.0 Client-Credentials Grant are expected to occur, it is out of scope for this version of the specification to define. Future versions of this specification may add explicit support for OAuth 2.0 Client-Credentials Grant.

In addition to the documentation in this section, there are OpenAPI files for the Open Badges API in both JSON and YAML format:

Figure 4 Diagram showing the major components of the Open Badges API

There are five key components to the API architecture.

User: This is the user that owns the resources (badges) that are on the resource server. Also called a Resource Owner.
Web Browser: This is the web browser the user interacts with.
Client: This is the web application that interacts with the resource server on behalf of the user. Also called Consumer in the IMS Global Security Framework v1.1.
Authorization Server: This is a server that implements the OAuth 2.0 endpoints on behalf of the resource server. In many systems, the authorization server and the resource server are combined.
Resource Server: This is the server that has the protected resources (badges). Also called Provider in the IMS Global Security Framework v1.1.

The role of each component during Registration, Obtaining Tokens, and Authenticating with Tokens are described below.

These endpoints are used to exchange OpenBadgeCredentials and Profile information.

All secure endpoint requests MUST be made over secure TLS 1.2 or 1.3 protocol.

All of the Secure REST Endpoints are protected by OAuth 2.0 access tokens as described in § 7. Open Badges API Security.

Each endpoint requires an access token with a specific Open Badges scope as shown below.

Operation	Scope
getCredentials	`https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.readonly` - Permission to read OpenBadgeCredentials for the authenticated entity.
upsertCredential	`https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.upsert` - Permission to create or update OpenBadgeCredentials for the authenticated entity.
getProfile	`https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.readonly` - Permission to read the profile for the authenticated entity.
putProfile	`https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.update` - Permission to update the profile for the authenticated entity.

Get issued OpenBadgeCredentials from the resource server for the supplied parameters and access token.

GET /ims/ob/v3p0/credentials?limit={limit}&offset={offset}&since={since}

Request header, path, and query parameters
Parameter	Parameter Type	Description	Required
`limit` (query)	`PositiveInteger`	The maximum number of OpenBadgeCredentials to return per page.	Optional
`offset` (query)	`NonNegativeInteger`	The index of the first AchievementCredential to return. (zero indexed)	Optional
`since` (query)	`DateTime`	Only include OpenBadgeCredentials issued after this timestamp.	Optional

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`GetOpenBadgeCredentialsResponse`	The set of OpenBadgeCredentials that meet the request parameters. Paging applies to the total number of OpenBadgeCredentials in the response.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 6: Sample getCredentials Request

GET /ims/ob/v3p0/credentials=2&offset=0 HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json

Example 7: Sample getCredentials Response (line breaks for clarity)

HTTP/1.1 200 OK
Content-Type: application/ld+json
X-Total-Count: 1
Link: <https://www.imsglobal.org/ims/ob/v3p0/credentials?limit=2&offset=1>; rel="next",
      <https://www.imsglobal.org/ims/ob/v3p0/credentials?limit=2&offset=0>; rel="last",
      <https://www.imsglobal.org/ims/ob/v3p0/credentials?limit=2&offset=0>; rel="first",
      <https://www.imsglobal.org/ims/ob/v3p0/credentials?limit=2&offset=0>; rel="prev"

{
  "compactJwsStrings": [
    "header.payload.signature",
    "header.payload.signature"
  ]
}

Create or replace an AchievementCredential on the resource server, appending it to the list of credentials for the subject, or replacing an existing entry in that list. The resource server SHOULD use the credential equality and comparison algorithm to compare and determine initial equality. The response code makes clear whether the operation resulted in a replacement or an insertion.

POST /ims/ob/v3p0/credentials

Allowed request content types
Content-Type Header	Content Type	Content Description	Content Required
application/json	`AchievementCredential`	If the AchievementCredential is not signed with the VC-JWT Proof Format, the request body MUST be a AchievementCredential and the `Content-Type` MUST be `application/vc+ld+json` or `application/json`.	Required
text/plain	`CompactJws`	If the AchievementCredential is signed with the VC-JWT Proof Format, the request body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`AchievementCredential`	The AchievementCredential was successfully replaced on the resource server. The response body MUST be the AchievementCredential in the request. If the AchievementCredential is not signed with the VC-JWT Proof Format, the response body MUST be a AchievementCredential and the `Content-Type` MUST be `application/vc+ld+json` or `application/json`.	Required
200	text/plain	`CompactJws`	The AchievementCredential was successfully replaced on the resource server. The response body MUST be the AchievementCredential in the request. If the AchievementCredential is signed with the VC-JWT Proof Format, the response body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required
201	application/json	`AchievementCredential`	The AchievementCredential was successfully created on the resource server. The response body MUST be the AchievementCredential in the request. If the AchievementCredential is not signed with the VC-JWT Proof Format, the response body MUST be a AchievementCredential and the `Content-Type` MUST be `application/vc+ld+json` or `application/json`.	Required
201	text/plain	`CompactJws`	The AchievementCredential was successfully created on the resource server. The response body MUST be the AchievementCredential in the request. If the AchievementCredential is signed with the VC-JWT Proof Format, the response body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required
304	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 8: Sample upsertCredential Request

POST /ims/ob/v3p0/credentials HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: text/plain
Content-Type: text/plain

header.payload.signature

Example 9: Sample upsertCredential Response

HTTP/1.1 200 OK
Content-Type: text/plain

header.payload.signature

Fetch the profile from the resource server for the supplied access token. Profiles that are received MAY contain attributes that a Host SHOULD authenticate before using in practice.

GET /ims/ob/v3p0/profile

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`Profile`	The matching profile.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 10: Sample getProfile Request

GET /ims/ob/v3p0/profile HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json

Example 11: Sample getProfile Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "@context": [
     "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University"
}

Update the profile for the authenticate entity.

PUT /ims/ob/v3p0/profile

Allowed request content types
Content-Type Header	Content Type	Content Description	Content Required
application/json	`Profile`	The request MUST include the entire Profile object. The resource server MAY respond with 400 BAD_REQUEST to reject data that is known immediately to not be acceptable by the platform, e.g. to reject a "telephone" property if the resource server cannot validate telephone numbers.	Required

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`Profile`	The matching profile. Successful request responses will be the same as GET Profile and may not include the patched values (as the resource server may be waiting for asynchronous processes to complete before accepting the value). The values may never become part of the published profile.	Required
202	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has been accepted for processing, but the processing has not been completed.	Required
304	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 12: Sample putProfile Request

PUT /ims/ob/v3p0/profile HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json
Content-Type: application/json

{
  "@context": [
     "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University",
  "phone": "111-222-3333"
}

Example 13: Sample putProfile Response

{
  "@context": [
       "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University",
  "phone": "111-222-3333"
}

Access to the discovery endpoint MUST NOT be protected. The Service Description Document (SDD) MUST be provided over HTTPS with TLS 1.2 or 1.3.

Fetch the Service Description Document from the resource server.

GET /ims/ob/v3p0/discovery

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`ServiceDescriptionDocument`	The service discovery document.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 14: Sample getServiceDescription request

GET /ims/ob/v3p0/discovery HTTP/1.1
Host: example.edu
Accept: application/json

Example 15: Sample getServiceDescription response

HTTP/1.1 200 OK
Content-Type: application/json

...
"components": {
    "securitySchemes": {
        "OAuth2ACG": {
            "type": "oauth2",
            "description": "OAuth 2.0 Authorization Code Grant authorization",
            "x-imssf-name": "Example Provider",
            "x-imssf-privacyPolicyUrl": "provider.example.com/privacy",
            "x-imssf-registrationUrl": "provider.example.com/registration",
            "x-imssf-termsOfServiceUrl": "provider.example.com/terms",
            "flows": {
                "authorizationCode": {
                    "tokenUrl": "provider.example.com/token",
                    "authorizationUrl": "provider.example.com/authorize",
                    "refreshUrl": "provider.example.com/token",
                    "scopes": {
                        "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.readonly" : "...",
                        "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.upsert" : "...",
                        "https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.readonly" : "...",
                        "https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.update" : "..."
                    }
                }
            }
        }
    },
    "schemas": {
        ...
    }
}
...

Pagination of getCredentials results is controlled by two query string parameters appended to the request. The response includes the following pagination headers.

Response Header	Description	Required
`X-Total-Count: <total_count>`	The resource server MUST include an `X-Total-Count` response header if the total result count is known. If the total result count is not known, the total count header MUST be ommitted.	Conditionally Required for `200 OK` Response
`Link: <pagination_links>`	The resource server MUST include a `Link` response header if the list of credentials in the response is incomplete; and MAY include the `Link` header if the response is complete.	Conditionally Required for `200 OK` Response

If present, the Link header MUST support all of the following link relations (rel values):

Relation	Description
next	The link relation for the immediate next page of results. This MUST appear when the current list response is incomplete.
last	The link relation for the last page of results. This MUST always appear.
first	The link relation for the first page of results. This MUST always appear.
prev	The link relation for the immediate previous page of results. This MUST appear when the offset is greater than zero.

Resource Servers MAY implement a Retry-After header to indicate a period of time to wait before attempting the request again.

If no Retry-After header is present and the response is non-2XX, it is recommended to retry the request in 30 minutes for an additional two attempts. After which, it MAY be desirable to alert the user that there is an issue with the connection (e.g. perhaps they need to reauthenticate or manually trigger the request when they believe services are back up).

The Open Badges API endpoints use the methods outlined in Section 4, "Securing Web Services" of the IMS Global Security Framework v1.1. Clients and servers that give individual users control over access to their resources MUST use the OAuth 2.0 Authorization Code Grant method.

Note: Non-individual access

Making a secured Open Badges API request using authorization code grant comprises three steps:

§ 7.1.1 Dynamic Client Registration - Share configuration information between the client and the server. This is typically done only once unless the registration is revoked.
§ 7.1.2 Obtaining Tokens - Obtain an authorization code using a choreography between the client, web browser, user, and authorization server. Then request an access token by sending a request, using the previously obtained authorization code, to the Access Token service endpoint.
§ 7.1.3 Authenticating with Tokens - Use the access token in the Authorization header of the API request.

To get started, the client and authorization server MUST share the four pieces of information shown below using the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] as described in this section.

client_id: This is the public identifier for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.
client_secret: This is the shared secret for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.
List of Scopes: The list of scopes that identify the set of endpoints for which access permission is being requested.
OAuth 2.0 Access Token Service Endpoint: The endpoint from which the approved, requesting client can obtain an access token.

If the client and authorization server support Token Revocation, they should also share:

OAuth 2.0 Revocation Service Endpoint: The endpoint a client can use to revoke an access token.

There are two steps to dynamic client registration:

Request a Service Description Document (SDD) from the resource server
Register with the authorization server

Sequence diagram for registration — Figure 5 Sequence diagram for dynamic client registration

The client only needs to register a client_id with the authorization server once. Each user will use the same client_id when they request their own authorization code.

To start the registration process, the user supplies the client with the resource server's base URL. When presented with an unknown resource server the client MUST request the resource server's Service Description Document (SDD) at the path {baseUrl}/ims/ob/v3p0/discovery. Rate-limited access to this endpoint is RECOMMENDED. An example request for an SDD takes the form of:

Example 16: Sample request for a service description document

GET /tenant/ims/ob/v3p0/discovery HTTP/1.1
Host: 1edtech.org
Accept: application/json

Access to the discovery endpoint MUST NOT be protected. The SDD MUST be provided over HTTPS with TLS 1.2 or 1.3.

The response to this request is the SDD supplied as a JSON encoded payload. The structure and format of this payload MUST follow that of the OpenAPI 3.0 Specification [OPENAPIS-3.0]. The SDD supplied MUST be a profiled version of the OpenAPI 3.0 (JSON) file provided with this specification (see § 1.2.1 OpenAPI 3.0 Files). The profiled version contains all of the details about the supported set of service end-points, the supported optional data fields, definitions of the proprietary data fields supplied using the permitted extension mechanisms, definitions of the available proprietary endpoints, and information about the security mechanisms.

The x-imssf-privacyPolicyUrl property is inserted into the securitySchemes within the components section of the OpenAPI file structure. This is an 1EdTech controlled extension to the OpenAPI specification.

Property Name	Type	Description	Required
`x-imssf-privacyPolicyUrl`	URL	A fully qualified URL to the resource server's privacy policy.	Required

The x-imssf-image and x-imssf-privacyPolicy properties are inserted into the info section of the OpenAPI file structure. These are also 1EdTech controlled extensions to the OpenAPI specification. Also note that the standard title and termsOfService property is required in a Service Description Document. These may be displayed to the user during the registration process.

Property Name	Type	Description	Required
`x-imssf-image`	URI	An image representing the resource server. May be a Data URI or the URL where the image may be found.	Optional
`x-imssf-privacyPolicyUrl`	URL	A fully qualified URL to the resource server's privacy policy.	Required
`title`	String	The name of the resource server.	Required
`termsOfService`	URL	A fully qualified URL to the resource server's terms of service.	Required

Example 17: Sample response with a Service Discovery Document

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

...
"info": {
  "x-imssf-image": "https://1edtech.org/logo",
  "x-imssf-privacyPolicyUrl": "https://1edtech.org/privacy",
  "title": "Example",
  "termsOfService": "https://1edtech.org/tos",
  ...
},
...
"components": {
  "securitySchemes": {
    "OAuth2ACG": {
      "type": "oauth2",
      "description": "OAuth 2.0 Authorization Code Grant authorization",
      "x-imssf-registrationUrl": "1edtech.org/registration",
      "flows": {
        "authorizationCode": {
          "tokenUrl": "1edtech.org/token",
          "authorizationUrl": "1edtech.org/authorize",
          "refreshUrl": "1edtech.org/token",
          "scopes": {
            "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.upsert" : "...",
            "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.readonly" : "...",
            "https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.readonly" : "...",
            "https://purl.imsglobal.org/spec/ob/v3p0/scope/profile.update" : "..."
          }
        }
      }
    }
  },
  "schemas": {
    ...
  }
}
...

Upon receiving a SDD from a resource server, the client SHOULD respect the Cache-Control and Expires headers if present in the response and configure local cache to match the directives it declares. If directives include one of no-cache, no-store, the client SHOULD NOT cache the data for future interactions. If directives include max-age or if an Expires header is present, the client SHOULD cache the SDD data, if valid, up to the expiration indicated, either at the time indicated by the Expires header or max-age seconds from request time.

An Etag header MAY be offered with the SDD response. If so, after a resource's declared expiration, a client MAY include an If-None-Match header containing the value of the Etag to check if the resource is still fresh. If so the resource server may return a 304 Not Modified response status code, and a new Expires or Cache-Control header MAY be included, which the client SHOULD use to update the cache expiration.

With the Registration URL in hand (the value of the x-imssf-registrationUrl property of the SDD), the client SHOULD post a registration request to the authorization server. The registration request MUST comply with OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. The registration request MUST NOT require an Initial Access Token. Use of the 'Software Statement' is NOT RECOMMENDED. The client registration request is sent to the Client Registration URL. The request MUST be sent using HTTPS with TLS 1.2 or 1.3 protocol.

The properties of the JSON body MUST be implemented as described in the following table. All URLs MUST use HTTPS (e.g. https://1edtech.org/logo.png) and all URLs MUST have the same hostname. All required properties MUST be present in the registration request in order for it to be accepted by the authorization server. Arrays MUST be used even when a single value is to be sent.

Name	Type	Description	Required
`client_name`	String	The human-readable name of the client application.	Required
`client_uri`	URL	A page that which describes the client application.	Required
`logo_uri`	URL	The logo of the client application. If present, the authorization server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file.	Required
`tos_uri`	URL	The human-readable Terms of Service for the client application that describes a contractural relationship between the end-user and the client that the end-user accepts when authorizing the client.	Required
`policy_uri`	URL	The human-readable Privacy Policy for the client application that describes how the deployment organization collects, uses, retains, and discloses personal data.	Required
`software_id`	String	A unique idenfitier assigned by the client application developer or software published used by registration endpoints to identify the client application to be dynamically registered. As described in [rfc7591], it SHOULD remain the same for all instances of the client application software.	Required
`software_version`	String	A version identifier string for the client application software identifies by `software_id`. The value of `software_version` SHOULD change on any update to the client application software identified by the same `software_id`.	Required
`redirect_uris`	URL[]	Array of redirection URI strings for use in the OAuth 2.0 flow.	Required
`scope`	String	In the registration request, this is a string containing a space-separated list of scope values that this client application may include when requesting access tokens. If omitted, the authorization server MAY register a client application with a default set of scopes. In the registration response, this is a list of scopes the authorization server supports. The list of scopes that can be requested are shown in § 6.2.1 Scopes.	Required
`token_endpoint_auth_method`	String	String indicator of the requested authentication method for the token endpoint. In this specification only "client_secret_basic" is allowed: "client_secret_basic": The client application uses the HTTP Basic authentication method as defined in OAuth 2.0. If omitted, the default is "client_secret_basic".	Optional
`grant_types`	String[]	Array of OAuth 2.0 grant type strings. In this specification only "authorization_code" and refresh_token" are allowed: "authorization_code": The authorization code grant type defined in OAuth 2.0. "refresh_token": The refresh token grant type defined in OAuth 2.0. If omitted, the default behavior is that the client will use only the "authorization_code" grant type.	Optional
`response_types`	String[]	Array of OAuth 2.0 response type strings. In this specification only "code" is allowed: "code": The authorization code response type defined in OAuth 2.0. If omitted, the default is that the client will use only the "code" response type.	Optional
`contacts`	String[]	Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client application. Privacy constraints MUST be supported as applicable.	Optional

Example 18: Sample registration request

  POST /connect/register HTTP/1.1
  Host: auth.1edtech.org
  Accept: application/json
  Content-Type: application/json; charset=utf-8

  {
    "client_name": "Example Client Application",
    "client_uri": "https://client.1edtech.org/",
    "logo_uri": "https://client.1edtech.org/logo.png",
    "tos_uri": "https://client.1edtech.org/terms",
    "policy_uri": "https://client.1edtech.org/privacy",
    "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1",
    "software_version": "v4.0.30319",
    "redirect_uris": [
      "https://client.1edtech.org/Authorize"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "grant_types": [
      "authorization_code",
      "refresh_token"
    ],
    "response_types": [
      "code"
    ],
    "scope": "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.readonly https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.upsert offline_access"
}

If the authorization server accepts the registration request, it will store the information provided in the request and respond HTTP 201 Created with a registration response that includes a set of client credentials for the client application to use when requesting access tokens. All the information provided by the client application MUST be returned to the client application, including modifications to the properties as the authorization server deems necessary. An example response looks like this:

Example 19: Sample registration response

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8

{
  "client_id": "4ad36680810420ed",
  "client_secret": "af7aa0d679778e12",
  "client_id_issued_at": 1565715850,
  "client_secret_expires_at": 1597338250,
  "client_name": "Example Client Application",
  "client_uri": "https://client.1edtech.org/",
  "logo_uri": "https://client.1edtech.org/logo.png",
  "tos_uri": "https://client.1edtech.org/terms",
  "policy_uri": "https://client.1edtech.org/privacy",
  "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1",
  "software_version": "v4.0.30319",
  "redirect_uris": [
    "https://client.1edtech.org/Authorize"
  ],
  "token_endpoint_auth_method": "client_secret_basic",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "scope": "https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.readonly https://purl.imsglobal.org/spec/ob/v3p0/scope/credential.upsert offline_access"
}

The following table describes the properties present in the client registration response that were not included in the request. These are all REQUIRED properties.

Name	Type	Description	Required
`client_id`	String	An OAuth 2.0 client identifier string. The value SHOULD NOT be currently valid for any other registered client.	Required
`client_secret`	String	An OAuth 2.0 client secret string.	Required
`client_id_issued_at`	NonNegativeInteger	The time at which the client_id was issued. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of issuance.	Required
`client_secret_expires_at`	NonNegativeInteger	The time at which the `client_secret` will expire. MAY be 0 for no expiration. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.	Required

When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object describing the error in the response body. The properties used are:

Name	Type	Description	Required
`error`	RegistrationError	The error.	Required
`error`	ASCII String	Human-readable ASCII text description of the error used for debugging.	Optional

Figure 6 Sequence diagram for obtaining access tokens when using the ACG flow

Obtaining an access token using an authorization code has two steps:

First obtain an authorization code using a choreography between the client, web browser, user, and authorization server - § 7.1.2.1 Authorization Request
Then request an access token using the authorization code - § 7.1.2.3 Access Token Request

Once obtained, the client can freely re-use the access token up until the token's expiry time, so that the client need not repeat steps of obtaining an authorization code and requesting an access token for every API request. Token refresh is also available (see § 7.2.1 Token Refresh Request).

After the client application is registered with the authorization server as described in § 7.1.1 Dynamic Client Registration, the client application then MAY initiate an authorization request as described in Section 4.2 of the IMS Security Framework [SEC-11] by redirecting the user to the authorizationUrl as declared in the resource server's Service Description Document (SDD).

In the OAuth 2.0 Security Best Practices document [OAUTH2-SBP] the use of Proof Key for Code Exchange (PKCE) [RFC7636] is recommended in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response. When using 1EdTech specifications, PKCE MUST be used to protect Authorization Code Grant based access. The PKCE has two stages:

First the client MUST supply a code_challenge and code_challenge_method in the request for an authorization code. The authorization server is responsible for associating the code_challenge with the issued authorization code.
Then the client MUST supply the code_verifier in the Access Token Request, and the authorization server verifies the code_verifier.

Parameter Name	Type	Description	Required
`response_type`	String	Value MUST be set to "code".	Required
`client_id`	String	The client application identifier. MUST be the `client_id` provided in the Dynamic Client Registration § 7.1.1.2 Register with Authorization Server response.	Required
`redirect_uri`	URL	The client application's redirection endpoint. MUST match one of the `redirect_uris` in the § 7.1.1 Dynamic Client Registration request. Although this is optional in the IMS Security Framework [SEC-11], it is REQUIRED by this specification.	Required
`scope`	String	The scope of the authorization request. The authorization server is responsible for validating the scopes identified in the request and the response MUST include a scope parameter which confirms this list or comprises a subset of the services requested.	Required
`state`	String	An opaque value used by the client application to maintain state between the request and callback. The authorization server includes this value when redirecting the web browser back to the client. This parameter MUST be used for preventing cross-site request forgery.	Required
`code_challenge`	String	This is BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).	Required
`code_challenge_method`	String	This MUST have a value of "S256" to indicate the SHA256 code verifier transformation method is used.	Required

All of the authorization request parameters are encoded in the authorization request as query string parameters. The request MUST be made by redirecting the browser to the OAuth 2.0 Authorization endpoint. The request MUST use HTTPS with TLS 1.2 or 1.3 protocol.

Example 20: Sample ACG authorization request (line breaks for clarity)

HTTP/1.1 302 Found
Location: https://auth.1edtech.org/authorize?
  client_id=4ad36680810420ed
  &response_type=code
  &scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%ob%2Fv3p0%2Fscope%2Fcredential.readonly%20offline_access
  &redirect_uri=https%3A%2F%client.1edtech.org%2FAuthorize
  &state=26357667-94df-4a14-bcb1-f55449ddd98d
  &code_challenge=XeDw66i9FLjn7XaecT_xaFyUWWfUub02Kw118n-jbEs
  &code_challenge_method=S256

If the redirect_uri matches a known client_id, the authorization server SHOULD present a UI asking the user to authenticate themself and grant the access request. The authorization server SHOULD display the client_name, client_uri, logo_uri, tos_uri, and policy_uri collected during Dynamic Client Registration to the user to help them decide whether to grant the access request.

If the user authorizes the client application to access their resources with the requested scopes, the authorization server MUST redirect the browser back to the redirect_uri with the code, scope, and state query string parameters.

The Authorization Code MUST be used only once. A lifetime for the authorization code of 600 seconds (10 minutes) is RECOMMENDED. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

Parameter Name	Type	Description	Required
`code`	String	The authorization code.	Required
`scope`	String	The authorized scope for the access request (this MAY be a subset of the scopes in the request). The value is a space delimited set of scopes.	Required
`state`	String	The opaque value supplied by the client to maintain state between the request and callback.	Required

Example 21: Sample ACG authorization response (line breaks for clarity)

HTTP/1.1 302 Found
Location https://client.1edtech.org/Authorize?
  code=dcf95d196ae04d60aad7e19d18b9af755a7b593b680055158b8ad9c2975f0d86
  &scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%ob%2Fv3p0%2Fscope%2Fcredential.readonly%20offline_access
  &state=26357667-94df-4a14-bcb1-f55449ddd98d

If the

You are here

Open Badges Specification

Abstract

1. Introduction

1.1 Audiences

1.2 Document Set

1.2.1 OpenAPI 3.0 Files

1.2.2 JSON-LD Context File

1.2.3 JSON Schema

1.3 Conformance Statements

1.4 Terminology

1.5 Conceptual Model

2. Overview

2.1 What is the problem this solves for?

2.2 What does adopting Verifiable Credentials entail?

2.3 Benefits and Opportunities

2.3.1 Interoperability with Digital Wallets, Verifiable Presentations, and Learner Experiences

2.3.2 Verifiable Credentials Support Increases Learner Data Privacy and Trustworthiness of Open Badges

2.3.3 Decentralized Identifiers and Self-Sovereign Identity

2.3.4 Aligning Open Badges and CLR with Common Assertion and Achievement Models

2.4 Achievement Credentials

2.4.1 Differentiating Issuers and Achievement Creators

2.5 Skill Assertions

3. Use Cases

3.1 Assertion Issuance to Wallet

3.2 Assertion Issuance Without a Wallet

3.3 Recipient Presentation of Assertion

3.4 License Issuance

3.5 Single Skill Assertion

3.6 Mapping Skills

3.7 Verifying Continuing Education

3.8 Self-assertion

3.9 Endorsement

3.10 Re-issue a <= 3.0 Badge to a 3.0 Badge

3.11 Authorization to Issue Given by Creator to Issuer

3.12 Revocation of an Issued Credential

3.13 Badge Class Status

4. Getting Started

4.1 Implementation Guide

4.2 Conformance and Certification

5. Open Badges Document Formats

5.1 File Format

5.2 Web Resource

5.3 Baked Badge

5.3.1 PNG

5.3.1.1 Baking

5.3.1.2 Extracting

5.3.2 SVG

5.3.2.1 Baking

5.3.2.2 Extracting

6. Open Badges API

6.1 Architecture

6.2 Secure REST Endpoints

6.2.1 Scopes

6.2.2 getCredentials

6.2.2.1 Request

6.2.2.2 Responses

6.2.3 upsertCredential

6.2.3.1 Request

6.2.3.2 Responses

6.2.4 getProfile

6.2.4.1 Request

6.2.4.2 Responses

6.2.5 putProfile

6.2.5.1 Request

6.2.5.2 Responses

6.3 Service Discovery Endpoint

6.3.1 getServiceDescription

6.3.1.1 Request

6.3.1.2 Responses

6.4 Paging

6.5 Retry Behavior

7. Open Badges API Security

7.1 Using OAuth 2.0 Authorization Code Grant

7.1.1 Dynamic Client Registration

7.1.1.1 Request the Service Description Document

7.1.1.2 Register with Authorization Server

7.1.2 Obtaining Tokens

7.1.2.1 Authorization Request

7.1.2.2 Authorization Response