- 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.
-
-
- IMS 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 IMS's procedures with respect
- to rights in IMS specifications can be found at the IMS Intellectual
- Property Rights webpage:
-
- http://www.imsglobal.org/ipr/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)
-
-
Digital Knowledge
-
October 11, 2019
-
No
-
RF RAND (Required & Optional Elements)
-
-
Washington State Board for Community and Technical Colleges (WSBCTC)
- 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 IMS 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.
-
This is a proposal to recharter the Open Badges Workgroup to develop a new version of the IMS Global Open Badges Specification to align it to the conventions of the W3C Verifiable Credentials Data Model for the use cases of Defined Achievement Claim and a Skill Claim. The credentials that would be produced under this proposal could easily be bundled into Comprehensive Learner Records and Verifiable Presentations. Portability and learner data privacy may be 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.
-
-
1. Introduction
1.1 Audiences
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
-
1.2 Document Set
The Open Badges Specification has several related documents and artifacts shown below. Together they make up the 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.
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.
- 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 Conformance and Certification Guide
- for this specification may introduce greater normative constraints than
- those defined here for specific service or implementation categories.
-
1.4 Terminology
-
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.
-
-
Claim: A statement about the Credential Subject. A claim may include associated evidence, results, or other metadata regarding a specific achievement, skill or assertion.
Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a verifiable credential.
-
-
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]
-
-
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]
-
-
Digital Credential Achievement (DC 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 Open Badge asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.
-
-
Digital Credential Assertion (DC Assertion): The core of both Open Badges and CLR is the assertion about achievement(s). DC 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.
-
-
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.
-
-
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]
-
-
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").
Skill Assertion: An assertion that contains a "skill result."
-
-
Verifiable Credential (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [vc-data-model].
-
-
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]
-
-
1.5 Conceptual Model
This conceptual model describes Open Badges concepts and the relationship between those concepts. The data model in appendix § B.2 org.1edtech.ob.v3p0.model 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 v1.1 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").
-
- Figure 1 Diagram show 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.
-
-
-
-
-
-
-
2. Overview
This section is non-normative.
2.1 What is the problem this solves for?
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. The presentation can also be cryptographically signed to demonstrate that the holder has assembled and sent the collection of VCs.
These layers of cryptographic proof can provide security and privacy enhancements to Open Badges that are not yet available in version 2.0. Adoption of Verifiable Credentials can 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 can 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), unlocks increased longevity and resilience of Open Badges that can describe achievements even more expressively than they do today.
2.2 What does adopting Verifiable Credentials entail?
This proposal is for a reasonable change to the structure of the Open Badges Assertion class, to adopt the conventions of the Verifiable Credential Data Model. This means that badges issued under the proposed version would not be conformant to all of the existing 2.x data model requirements.
An existing 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.
-
- Figure 2 Open Badges 2.0 Diagram
-
The proposed Verifiable Credentials structure 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 BadgeClass (also known by its CLR alias as an "Achievement") with a "hasCredential" relationship to that defined achievement. It identifies its verification information with a "proof" relationship to an instance of a proof that follows a standardized schema.
-
- Figure 3 Open Badges 3.0 Proposed Diagram
-
2.3 Benefits and Opportunities
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 proposal opens a path forward for a unified concept of digital credentials in the IMS Global community, collapsing the relevant differences between Open Badges and 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 Comprehensive Learner Record.
Below, we present a selection of benefits related to the proposed 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 today's version of Open Badges and CLR.
2.3.1 Interoperability with Digital Wallets, Verifiable Presentations, and Learner Experiences
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 2.0 as a "Host". There is an existing and growing ecosystem of deployed technology to support VCs; integration with these becomes possible if Open Badges adopts VCs along the lines of this proposal. 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. Protocols and interoperability around making and fulfilling requests are still at an early stage, but when these technologies are tested in the wild, it would be a good idea to already have educational credentials claim schemas available for the claim types ("defined achievement" and "skill assertion") possible to make with Open Badges.
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.
2.3.2 Verifiable Credentials Support Increases Learner Data Privacy and Trustworthiness of Open Badges
The W3C Verifiable Credentials Data Model 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 IMS Global 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 allows 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 issuedOn 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 2.0 was released 4 years ago. 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.
2.3.3 Decentralized Identifiers and Self-Sovereign Identity
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) 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.
2.3.4 Aligning Open Badges and CLR with Common Assertion and Achievement Models
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 is 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 Open Badges and CLR 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.
2.3.5 Differentiating Issuers and Creators
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 is 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 must do more. Conveniently, an issuer property for the entity that is digitally signing the credential is included in the VC assertion. Because of this, the issuer property referenced in the BadgeClass is redundant. This property is a logical placement for new properties to describe a creator(s) and the eligibility of potential outside issuers to share or have delegated responsibility for badge issuance. This will enable the use cases and give relying third-parties more contextual information about the achievement and the parties involved.
2.4 Skill Assertions
Many of the use cases for Open Badges and CLR involve describing "defined achievements" with the Achievement/BadgeClass data class. These achievements may sometimes be aligned to skills or competencies, as a means of indicating that those who earn them have achieved the aligned skills. As part of this proposal, we also introduce the concept of a Skill Assertion, showing how the Open Badges Specification can be expanded to assert achievement of single skills in a more flexible manner that is complementary to these use cases and that opens up a wide range of new use cases. A Skill Assertion offers a lightweight structure for issuers to make a claim that a learner has a skill, with a particular assessment result if desired.
A Skill Assertion is an Open Badges assertion that contains a "skill result." The idea of a skill result fits perfectly with the concept from CLR of a Result that is paired against the ResultDescription defined in an Achievement/BadgeClass, but a skill result targets a skill that may have been defined by a third-party organization, such as an industry group. This is a separate claim that may be composed alongside a "hasCredential" claim that identifies which Achievement/BadgeClass criteria has been met, or it could appear in an Open Badges Verifiable Credential without the defined achievement claim. This means that an issuer could easily make an assertion that a learner has achieved the criteria of a certain badge, or that they have achieved a specific skill, or both (whether or not the skill is specifically identified in the alignments of the badge).
The following diagram shows how these concepts are connected for a use case in which an issuer asserts that a credential subject has achieved a particular skill, using a "results" claim to establish a relationship with a Result class that identifies which skill is recognized and may describe other aspects of the skill achievement, such as the level at which it was assessed and a degree of confidence. Specific use cases for how this data needs to be consumed will drive the specific skill-specific properties of the Result class that may be added to give issuers the options they need. In this example, a Skill Definition that is identified by a unique URL at which information about the skill is published is referenced by the Result. This pattern, named by the Open Skills Network as a Rich Skill Descriptor (RSD), makes it possible for skills to be precisely referenced in other entities, such as credentials. Here, the RSD was published by an industry organization, and included in this credential by a different issuer. There is no need for the skill author and the credential issuer to have a pre-existing or discoverable relationship in order for a Skill Assertion to be valid. Evidence may also be included, just like in any Assertion.
-
- Figure 4 Skill Assertion with Evidence Diagram
-
The notion of skill results can be combined with a defined achievement assertion claim "hasCredential". In this example, the same Skill Assertion appears, but additional criteria that the learner has met is described in the Achievement/BadgeClass as in many of our other examples. The Achievement aligns to the same skill that is recognized, but the Result allows the issuer to describe specifics about the assessment results relative to the skill.
-
- Figure 5 Defined Achievement Assertion with Skill Result Diagram
-
The inclusion of Skill Assertion claims makes a natural, ergonomic fit with defined achievement claims and evidence claims. Business logic to process each of the available claims can look for just the data a relying party needs, and extraneous claims do not get in the way.
-
-
3. Use Cases
This section is non-normative.
The use cases below drive the design of Open Badges 3.0 specification.
3.1 Revocation of an Issued Credential
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.
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
-
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.2 Online Course Completion Assertion Issuance to Wallet
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.
-
Post-Conditions/Success Criteria:
Points of Failure:
3.3 Assertion Issuance without mobile VC Wallet (email)
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.
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.
-
Post-Conditions/Success Criteria:
Points of Failure:
3.4 Assertion Issuance to Custodian/Guardian Wallet (custodian/guardian)
Kalamazoo Elementary School holds a schoolwide spelling bee and recognizes the achievement of a minor student, Maddie, for winning third place in said spelling bee. Kalamazoo delivers the assertion to Maddie's guardian, Cole, to maintain the assertion until such a time that Maddie can take control of that assertion.
Goal of the Primary Actor: Kalamazoo K-12 wishes to award an assertion that Maddie may eventually use, with the understanding that she may not be able to control a wallet on her own behalf today.
Actors: Kalamazoo K-12 district (issuer), Maddie (student), Cole (guardian)
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.5 Assertion Issuance without Wallet (QR code)
Jade takes a Standard First Aid course offered by a Red Cross authorized training company, ABC Corp., and receives a printed certificate including their name and certificate number to show that they are certified for SFA + CPR valid for 3 years. The certificate also includes a QR code that is a representation of an OB 3.0 assertion embedded with Jade's name, certificate number, and expiry date. Jade's employer then scans the QR code and verifies that Jade is now qualified to be a first aid attendant in the office (which gives Jade a $2/hr raise).
Goal of the Primary Actor: To be able to show that they hold current certification for SFA from the Red Cross which qualifies them to be a workplace first aid attendant and gives them a raise for the extra job role.
Actors: Organisation that does Red Cross training, course participant, participant's employer
Preconditions for this Use Case:
-
The Red Cross has defined an Achievement for the certification.
-
The vendor is authorized by the Red Cross to do training and issue certification certificates for the SFA and CPR courses.
-
The vendor has established an issuer profile and has the capability to create and print certificates.
-
The participant's employer has an application that can view and verify VCs that are printed as QR codes.
-
Flow of Events:
-
Jade shows a piece of government issued ID to the vendor while taking the course.
-
Jade completes and passes the SFA + CPR first aid course.
-
ABC Corp. prints out a wallet sized and wall sized certificate to say that Jade is certified.
-
The certificate is presented to Jade's employer and Jade gets an additional work role due to being qualified as a workplace first aid attendant.
-
Post-Conditions/Success Criteria:
Points of Failure:
3.6 Recipient Presentation of 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
-
Post-Conditions/Success Criteria:
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
-
3.7 License Issuance
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.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.8 Mapping Skills
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.
Editor's note
-New to v3.0: In addition to badges recognizing courses, this use case mentions skill badges. In v3.0, a badge can claim that the recipient has attained a single skill. The assertion references a Rich Skill Descriptor (RSD) instead of a badge class. Skill badges can also be cryptographically verified following the Verifiable Credentials model and stored in digital wallets.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.9 Verifying Continuing Education
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.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.10 Self-assertion
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.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.11 Endorsement
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 badge. This could be the same in 3.0 but also, an endorsement could be a response from a verifier. In the example above, the platform verifies the badge the data and then acts as an issuer of endorsements on behalf of its users. This would be closer to how endorsements are used in 2.0 but applicable to 3.0. 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.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.12 Single Skill Assertion
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. They do not require a badge class, badge image, etc.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.13 Re-issue a <= 3.0 Badge to a 3.0 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.
Editor's note
-New to v3.0: The use of VC wallets, and decentralized identifiers are different in 3.0.
-
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.14 Badge Class Status
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.
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
3.15 Authorization to Issue Given by Creator to Issuer
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.
Goal of the Primary Actor:
Actors:
Preconditions for this Use Case:
Flow of Events:
Post-Conditions/Success Criteria:
Points of Failure:
-
-
4. Getting Started
This section is non-normative.
4.1 New to Open Badges
If you are new to Open Badges, please start here.
Note
-@@@TBD
-
4.2 Migrating from Open Badges 2.x
If you are migrating from Open Badges 2.0 [OB-20] or 2.1 [OB-21] to OB 3.0, please start here.
Note
-@@@TBD
-
4.2.1 Differences Between Version 2.0 and 3.0
4.2.2 Differences Between Version 2.1 and 3.0
-
-
5. Open Badges Document Formats
Open Badges can be exchanged as JSON-LD documents as defined in this section, or by using the Open Badges API. Open Badges documents can be exchanged as a file or web resource, displayed as a QR code, or embedded in an image. The contents of an Open Badge document MUST meet the following criteria:
JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].
-
5.2 Web Resource
When the id of an Assertion is a URL, a GET request to that URL MUST return JSON representing an AssertionCredential as described above.
-
The Content-TypeSHOULD be application/json or application/ld+json.
-
The content MUST be encoded using UTF-8 [RFC3629].
-
5.3 QR Code Format
Some Assertions are quite long. Due to the large size of the resulting JSON string, the string MUST be compressed prior to rendering the QR Code. To ensure interoperability, the string MUST be compressed using Concise Binary Object Representation (CBOR) [RFC8949].
Issue 2
- Is this even practical?
-
5.4 Image Format
Issue 3: Baking an ObPresentation
-
- Can an ObPresentation be baked into an image? What are the implications?
-
-
Assertions may be exchanged as image files with assertions encoded within. This allows assertions to be portable wherever image files may be stored or displayed.
"Baking" is the process of taking an AssertionCredential and embedding it into the image, so that when a user displays the image on a page, software that is Open Badges or CLR-aware can automatically extract that Assertion 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 or SVG format in order to support baking.
An iTXt chunk with the keyword openbadgesMUST NOT appear in a PNG more than once. When baking an image that already contains assertion data, the implementor may choose whether to pass the user an error or overwrite the existing chunk.
5.4.1.1.2 Extracting
Parse the PNG datastream until the first iTXt chunk is found with the keyword openbadges. The rest of the stream can be safely discarded. The text portion of the iTXt will be the JSON representation of a #org.1edtech.ob.v3p0.assertioncredential.class.
5.4.1.2 SVGs
5.4.1.2.1 Baking
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:assertion> tag.
The JSON representation of the AssertionCredentialMUST go into the body of the tag, wrapped in <![CDATA[...]]>.
There MUST be only one <openbadges:assertion> tag in an SVG. When baking an image that already contains assertion data, the implementor may choose whether to pass the user an error or overwrite the existing tag.
5.4.1.2.2 Extracting
Parse the SVG until you reach the first <openbadges:assertion> tag. The rest of the SVG data can safely be discarded.
-
-
-
-
-
6. Open Badges API
-
-
- Open Badges can be exchanged using the API (application programming interface) defined here, or as
- documents.
-
The HTTP scheme (which MUST be "https"), domain name, and any other path
- elements required by the resource server (e.g. "https://example.com/tenant").
-
- 'Misdirected Request' - The request was not made over secure TLS 1.2 or 1.3 protocol.
-
-
Required
-
-
-
-
-
Response Headers
-
-
-
-
-
Response Header
-
Description
-
Required
-
-
-
-
-
Content-Type: application/ld+json
-
The content type MUST be application/ld+json.
-
Required
-
-
-
X-Total-Count: <total_count>
-
- The resource serverMUST 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 serverMUST include a
- Link response
- header if the list of assertions 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.
-
-
-
-
-
-
Sample Response
-
-
-
- Example 5: Sample getAssertions Response (line breaks for clarity)
-
- If the resource server is holding an Assertion with the same id, it will be updated. Otherwise
- the Assertion will be created and held by the resource server. Note that "created" is not the same
- as "issued". The resource server will simply store the Assertion in the request payload as a
- resource.
-
The HTTP scheme (which MUST be "https"), domain name, and any other path
- elements required by the resource server (e.g. "https://example.com/tenant").
-
Update the Profile on the resource server for the authenticated entity.
-
- The request SHOULD only include profile identifier properties to be added to the profile, not any existing data.
- The values may never become part of the published profile.
-
- 'OK' - The Profile will be updated. The response payload MUST 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 values).
-
- 'Bad Request' - The request was invalid or cannot be served. The exact error should be explained
- in the response payload. A resource serverMAY 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 Provider cannot validate telephone numbers.
-
- Receivers of requests 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 recipient 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).
-
-
-
-
-
-
-
-
-
-
7. Open Badges API Security
-
- In scenarios where the learner or another third party is the user that owns the resources (badges),
- there will not be a pre-established trust relationship. Therefore you MUST use of OAuth 2.0 Authorization
- Code Grant.
-
- § 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.
-
- To get started, the client and authorization serverMUST share the four pieces of information
- shown below using the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] as described in this
- section.
-
- 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.
-
-
-
Request the Service Description Document
-
-
- 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 clientMUST 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 12: Sample request for a service description document
-
- 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 for the Badge Connect API). 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 IMS controlled
- extension to the OpenAPI specification.
-
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 IMS 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.
-
- Upon receiving a SDD from a resource server, the clientSHOULD 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 clientSHOULD 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 clientMAY 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 clientSHOULD use to update the
- cache expiration.
-
-
-
Register with Authorization Server
-
-
- With the Registration URL in hand (the value of the x-imssf-registrationUrl property of
- the SDD), the clientSHOULD 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://example.com/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.
-
- The logo of the client application. If present, the authorization serverSHOULD
- display this image to the end-user during approval. The value of this field MUST point
- to a valid image file.
-
- 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.
-
- The human-readable Privacy Policy for the client application that describes how the
- deployment organization collects, uses, retains, and discloses personal data.
-
- 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.
-
- A version identifier string for the client application software identifies by
- software_id. The value of software_versionSHOULD change on
- any update to the client application software identified by the same
- software_id.
-
- 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 serverMAY 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 § Scopes.
-
- Array of strings representing ways to contact people responsible for this client,
- typically email addresses. The authorization serverMAY make these contact addresses
- available to end-users for support requests for the client application. Privacy
- constraints MUST be supported as applicable.
-
- 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:
-
- The following table describes the properties present in the client registration response that were
- not included in the request. These are all REQUIRED properties.
-
- 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.
-
- 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:
-
- 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 § Token Refresh Request).
-
-
-
Authorization 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 IMS specifications, PKCE MUST be used to protect Authorization Code Grant based
- access. The PKCE has two stages:
-
-
- First the clientMUST 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 clientMUST supply the code_verifier in the Access Token Request, and
- the authorization server verifies the code_verifier.
-
- 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.
-
- 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.
-
- 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.
-
- 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 16: Sample ACG authorization request (line breaks for clarity)
-
- If the redirect_uri matches a known client_id, the authorization serverSHOULD present a UI asking the user to authenticate themself and grant the access
- request. The authorization serverSHOULD 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 serverMUST 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 serverMUST 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.
-
- If the authorization server does not recognize the client applications's redirection
- endpoint from a prior connection with this client application, the authorization server
- SHOULD inform the user of the error and MUST NOT automatically redirect to the web browser
- to the invalid redirection URI.
-
-
- If the user denies the authorization request or if the request fails for reasons other than a
- missing or invalid redirection URI, the authorization server informs the client by adding
- the following parameters to the query component of the redirection URI.
-
- Human-readable ASCII [RFC20] text providing additional information, used to assist the
- client developer in understanding the error that occurred. Values for the
- "error_description" parameter MUST NOT include characters outside the set %x20-21 /
- %x23-5B / %x5D-7E.
-
- A URI identifying a human-readable web page with information about the error, used to
- provide the client developer with additional information about the error. Values for the
- "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include
- characters outside the set %x21 / %x23-5B / %x5D-7E.
-
- The opaque value supplied by the client to maintain state between the request and
- callback.
-
-
Required
-
-
-
-
-
- Example 18: Sample authorization error response
-
HTTP/1.1302 Found
-Location: https://client.example.com/cb?error=access_denied&state=xyz
-
-
-
Access Token Request
-
- With the supplied code, the client application SHOULD attempt to exchange the
- code for an access_token. The client application makes an
- authorization grant POST request to the tokenUrl as declared in the resource server's Discovery Document. The HTTP POST request MUST include a Basic authorization header with
- the client_id and client_secret provided in the registration response. The
- body of the token request MUST include the following form fields:
-
- If the authorization server grants this request (see Section 5.1 in [RFC6749] for the detailed
- description), it returns HTTP 200 OK status code with content type "application/json"
- consisting of a JSON object containing the access token and its expiry lifetime (IMS recommends a
- default expiry lifetime of 3600 seconds, one hour, for access tokens), optionally a refresh token,
- and confirms the set of scopes supported by the access token:
-
- The lifetime in seconds of the access token. For example, the value "3600" denotes that
- the access token will expire in one hour from the time the response was generated. IMS
- recommends a default expiry lifetime of 3600 seconds, one hour, for access tokens. If
- omitted, the authorization server SHOULD provide the expiration time via other means or
- document the default value.
-
- The authorization serverMAY decide not to issue an access token. This could be because the
- request scopes are invalid, the credentials from the client may be invalid, etc. In this case the
- authorization serverMUST return an HTTP 400 Bad Request status code with content
- type "application/json" consisting of a JSON object describing the error in the response body. The
- properties used to describe the error are:
-
- Human-readable ASCII [RFC20] text providing additional information, used to assist the
- client developer in understanding the error that occurred. Values for the
- "error_description" parameter MUST NOT include characters outside the set %x20-21 /
- %x23-5B / %x5D-7E.
-
- A URI identifying a human-readable web page with information about the error, used to
- provide the client developer with additional information about the error. Values for the
- "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include
- characters outside the set %x21 / %x23-5B / %x5D-7E.
-
-
Optional
-
-
-
-
-
- Example 21: Sample access token error response
-
- After obtaining an access_token and optionally a refresh_token using the
- method above, a client application MAY issue request that access resources controlled by the
- user on the resource server using the access_token in the HTTP Authorization header
- [RFC2617] with a Bearer Token [RFC6750]. For example, a "getAssertions"
- would look like this:
-
- The recommended value of the access token's expires_in attribute is 3600 i.e. one hour. This
- means that the validity of the access token expires one hour after the time it was issued.
-
-
- When requesting an access token as part of the Authorization Code Grant process, an authorization server
- MAY return a 'Refresh Token'. The refresh token can be used to obtain an access token using the same
- authorization grant: this is described in Section 6 of [RFC6749]. The use of the Refresh Token avoids the
- choreography for obtaining the credentials to gain access to the authorization server.
-
-
- An Authorization Server is NOT REQUIRED to support token refresh.
-
-
-
Token Refresh Request
-
-
- If the access_token is expired or about to expire, and the client application received
- a refresh_token, the client application can use OAuth 2.0 Token Refresh to get a new
- access_token and refresh_token.
-
-
- The client makes a refresh POST request to the token endpoint by adding the following parameters
- using the "application/x-www-form-urlencoded" format in the HTTP request entity-body:
-
- The scope of the access request. The requested scope MUST NOT include any scope not
- originally granted by the user, and if omitted is treated as equal to the scope
- originally granted by the user.
-
-
Required
-
-
-
-
-
- Example 23: Sample ACG token refresh request (line breaks for clarity)
-
- There may be deployments in which revocation of an access token is useful. The Token Revocation process is
- based upon [RFC7009]. The client requests the revocation of a particular token by making an HTTP POST
- request (using TLS) to the token revocation endpoint URL. Note that [RFC7009] states that implementations
- MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens.
-
-
-
Token Revocation Request
-
-
- The client constructs the request by including the following parameters using the
- "application/x-www-form-urlencoded" format in the HTTP request entity-body:
-
- The authorization server responds with HTTP 200 OK status code if the token has been
- revoked successfully or if the client submitted an invalid token.
-
-
- When the request for revocation is rejected, the authorization server returns an error response as
- described earlier in § Access Token Error Response with an error code of "unsupported_token_type".
-
-
-
-
-
-
-
-
8. Data Integrity
This section describes mechanisms for ensuring the authenticity and integrity of AssertionCredential documents and payloads. For general information about data integrity, please see Data Integrity 1.0.
8.1 Proofs
A data integrity proof is comprised of information about the proof, parameters required to verify it, and the proof value itself. Please see the Proof class for details.
To ensure interoperability, this specification requires conforming implementations support ...
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.
-
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).
-
Holder: The entity that makes a presentation. The holder may also be the issuer or subject of one or more credentials in the presentation.
-
Linked Data Proof: A type of embedded signature proof.
-
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.
The data model can be encoded in Javascript Object Notation (JSON) [RFC8259] by mapping property types in the Data Model to JSON types as follows:
-
Numeric values representable as [IEEE-754] MUST be represented as a Number type.
-
Boolean values MUST be represented as a Boolean type.
-
Sequence values MUST be represented as an Array type.
-
Unordered sets of values MUST be represented as an Array type.
-
Sets of properties MUST be represented as an Object type.
-
Other values MUST be represented as a String type.
-
When serializing the JSON, these rules MUST be followed:
-
Properties defined as a single value in the Data Model MUST be represented as a single value, not a JSON Array.
-
Properties defined as an Array MUST be represented as a JSON Array, NOT as a single value.
-
Properties defined as a Class and not a Primitive or Derived Type MUST be represented as an JSON Object, NOT as a URI.
-
Properties that have a null value or empty value MUST be ommitted from the serialized JSON. This includes empty Arrays.
-
A.2 JSON-LD
[JSON-LD] is a JSON-based format used to serialize Linked Data. The syntax is designed to easily integrate into deployed systems already using JSON, and provides a smooth upgrade path from JSON to [JSON-LD]. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.
Instances of the data model are encoded in [JSON-LD] in the same way they are encoded in JSON (Section § A.1 JSON), with the addition of the @context property. The JSON-LD context is described in detail in the [JSON-LD] specification and its use is elaborated on in Section § C. Extensions.
- Though this specification requires that a @context property be present, it is not required that the value of the @context property be processed using JSON-LD. This is to support processing using plain JSON libraries, such as those that might be used when the verifiable credential is encoded as a JWT. All libraries or processors MUST ensure that the order of the values in the @context property is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.
-
OpenAPI Specification. Darrell Miller; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Uri Sarid; Tony Tam; Jason Harmon. OpenAPI Initiative. URL: https://www.openapis.org/
\ No newline at end of file
diff --git a/extensions/aceExtension/v1p0/microsite/ob-ace-v1p0.md b/extensions/aceExtension/v1p0/microsite/v1p0.md
similarity index 99%
rename from extensions/aceExtension/v1p0/microsite/ob-ace-v1p0.md
rename to extensions/aceExtension/v1p0/microsite/v1p0.md
index 12bb55db..48a36e0f 100644
--- a/extensions/aceExtension/v1p0/microsite/ob-ace-v1p0.md
+++ b/extensions/aceExtension/v1p0/microsite/v1p0.md
@@ -3,7 +3,7 @@ author: 1Edtech Consortium
category: Extension
title: Open Badges American Council for Education (ACE) Extension
shortcode: OB-ACE-10
-status: Candidate Final Public
+status: PublicCandidateFinal
lastUpdated: 2025-10-09
version: '1.0'
nature: normative
diff --git a/extensions/assessmentExtension/v2p0/microsite/ob-assess-v2p0.md b/extensions/assessmentExtension/v2p0/microsite/v2p0.md
similarity index 99%
rename from extensions/assessmentExtension/v2p0/microsite/ob-assess-v2p0.md
rename to extensions/assessmentExtension/v2p0/microsite/v2p0.md
index f1ec8e1d..bf59345b 100644
--- a/extensions/assessmentExtension/v2p0/microsite/ob-assess-v2p0.md
+++ b/extensions/assessmentExtension/v2p0/microsite/v2p0.md
@@ -3,11 +3,11 @@ author: 1Edtech Consortium
category: Extension
title: Open Badges Assessment Extension
shortcode: OB-ASSESSMENT-20
-status: Candidate Final Public
+status: PublicCandidateFinal
lastUpdated: 2025-07-08
version: '2.0'
nature: normative
-docType: spec
+docType: specification
contributors:
- name: Nate Otto
affiliation: Skybridge Skills
diff --git a/extensions/issuerAccreditationExtension/v2p0/index.html b/extensions/issuerAccreditationExtension/v2p0/index.html
index d665ee8e..49424ec4 100644
--- a/extensions/issuerAccreditationExtension/v2p0/index.html
+++ b/extensions/issuerAccreditationExtension/v2p0/index.html
@@ -22,11 +22,11 @@
specTitle: "Open Badges Issuer Accreditation Extension",
shortName: "ob-accred",
specStatus: "Base Document",
- specDate: "July 24th, 2024",
+ specDate: "April 2nd, 2025",
specVersion: "2.0",
specNature: "normative",
specType: "spec",
- docVersion: "1.0",
+ docVersion: "1.1",
contributors: _contributors,
localBiblio: _localBiblio,
skipCertGuideConformanceRef : true,
@@ -216,6 +216,11 @@
Version History
July 24th, 2024
Initial release.
+
+
Base Document 1.1
+
April 2nd, 2025
+
Set multiplicity of accreditations to 0..*.
+
diff --git a/extensions/issuerAccreditationExtension/v2p0/microsite/ob-issuer-v2p0.md b/extensions/issuerAccreditationExtension/v2p0/microsite/v2p0.md
similarity index 99%
rename from extensions/issuerAccreditationExtension/v2p0/microsite/ob-issuer-v2p0.md
rename to extensions/issuerAccreditationExtension/v2p0/microsite/v2p0.md
index fde22660..974ec801 100644
--- a/extensions/issuerAccreditationExtension/v2p0/microsite/ob-issuer-v2p0.md
+++ b/extensions/issuerAccreditationExtension/v2p0/microsite/v2p0.md
@@ -3,11 +3,11 @@ author: 1Edtech Consortium
category: Extension
title: Open Badges Issuer Accreditation Extension
shortcode: OB-ACCRED-20
-status: Base Document
+status: Final
lastUpdated: 2024-07-24
version: '2.0'
nature: normative
-docType: spec
+docType: specification
contributors:
- name: Nate Otto
affiliation: Skybridge Skills
diff --git a/extensions/issuerAccreditationExtension/v2p0/ob-accred_v2p0.lines b/extensions/issuerAccreditationExtension/v2p0/ob-accred_v2p0.lines
index 9dfae0e4..914ac4a7 100644
--- a/extensions/issuerAccreditationExtension/v2p0/ob-accred_v2p0.lines
+++ b/extensions/issuerAccreditationExtension/v2p0/ob-accred_v2p0.lines
@@ -3,7 +3,7 @@ Model ob-accred 2024-09-12 2.0 "s:IMS Base Document" "t:Open Badges Issuer Accre
Package MainClasses DataModel
Class IssuerAccreditationProfile Unordered false [] "Profile extension with accreditation information."
- Property accreditations AccreditationProfile 0..1 "d:listing of accreditations."
+ Property accreditations AccreditationProfile 0..* "d:listing of accreditations."
Class AccreditationProfile Unordered false [] "Profile extension with detailed information about an accrediting organization."
Property type IRI 1 "d:MUST be the IRI 'AccreditationProfile'."
diff --git a/ob_next/README.md b/ob_next/README.md
deleted file mode 100644
index 5dfdf775..00000000
--- a/ob_next/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# OB Next Collection Box
-
-This folder is a place to store files related to **potential** new features of future versions of the Open Badges specification as approved by the IMS OB Project Group.
diff --git a/ob_next/dids-in-badges.md b/ob_next/dids-in-badges.md
deleted file mode 100644
index 6a5e0303..00000000
--- a/ob_next/dids-in-badges.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Introduction
-
-## Design Goals and Rationale
-
-This draft proposal adds to the [Open Badges specification](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html) to enable recipients of badges to use [Decentralized Identifiers (DIDs)](https://w3c.github.io/did-core/) in their [IdentityObject](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#IdentityObject). The use of DIDs will enable recipients to use a cryptographically verifiable pseudonymous identifier in their issued Badges. For other stakeholders such as Issuers or Consumers DIDs enable cryptographic verification capabilities to ensure control of the Recipient over their badges.
-
-## Use Cases
-
-_This section is non-normative._
-
-* A recipient of a Badge wants to use a DID as a pseudonymous identifier.
-
-* A candidate recipient of a Badge provides their DID to a Badge Issuer
-
-* A Badge Issuer generates a DID for a recipient
-
-* An Issuer leverages DID infrastructure to cryptographically verify that a recipient controls a DID identifier.
-
-* A Consumer leverages DID infrastructure to cryptographically verify that a recipient controls a Badge.
-
-
-## Terminology
-
-The following terms are used throughout this document:
-
-* *Badge Issuer*: A service that allows for the creation of [BadgeClasses](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#BadgeClass) and the subsequent issuing of [Assertions](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Assertion) to recipients that conform to the Open Badges specification. Beginning with Open Badges 2.0, the candidate platform must issue a valid [Baked Badge](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Baking) and demonstrate how the recipient retrieves the Badge.
-
-* *Badge Displayer*: An application that displays verified badges to viewers. Beginning with Open Badges 2.0, the candidate platform must display a minimum set of badge metadata and support viewer-initiated verification of a Badge.
-
-* *Badge Host*: An application that can import, aggregate, and publicly host [Assertions](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Assertion) for recipients. It also supports export of Badges at user request. Beginning with Open Badges 2.0, the candidate platform must be able to import all formats of Open Badges as well as prove that Badge metadata is not lost upon export of the badge.
-
-* *DID*: [Decentralized Identifiers (DIDs)](https://w3c.github.io/did-core/) are a type of identifier that enables a verifiable, decentralized digital identity.
-
-* *ID*: Unique [IRI](https://tools.ietf.org/html/rfc3987) for the [Assertion](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Assertion). If using [Hosted Verification](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#HostedBadge), this should be the [URI](https://tools.ietf.org/html/rfc3986) where the assertion is accessible. For [Signed Assertions](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#SignedBadge), it is recommended to use a [UUID in the urn:uuid namespace](https://tools.ietf.org/html/rfc4122).
-
-# Value Proposition
-
-## What Is a DID?
-
-[Decentralized Identifiers](https://w3c.github.io/did-core), or DIDs, "are a new type of identifier to provide verifiable, decentralized digital identity." In brief, DIDs are URLs, often backed by a distributed ledger, that can be resolved to a "DID Document" containing cryptographic key material of which the "controller" can prove ownership. The identity provides a mechanism for trustable interactions with the subject of a DID.
-
-Unlike email addresses — controlled by a provider such as Google, Apple, or another corporation, or telephone numbers — controlled by telecom companies such as a Verizon, AT&T, and regulated by government agencies, DIDs are intended to be controlled by individual entities (individuals or organizations). This restriction is applied by the source the DID is backed with, which could be a centralized website (see: [did:github](https://github.com/decentralized-identity/github-did)), or a public decentralized blockchain (see: [did:btcr](https://w3c-ccg.github.io/didm-btcr)). DIDs enable high-trust interactions by leveraging public key cryptography.
-
-DIDs are a key piece of decentralized infrastructure that are called out specifically in the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) and [Identity Hub](https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md) specifications among many others in the Self Sovereign and Digital Identity space.
-
-An example DID document, [taken from the spec](https://w3c.github.io/did-core/#example-2-minimal-self-managed-did-document), is provided below:
-```
-{
- "@context": "https://www.w3.org/ns/did/v1",
- "id": "did:example:123456789abcdefghi",
- "authentication": [{
- "id": "did:example:123456789abcdefghi#keys-1",
- "type": "RsaVerificationKey2018",
- "controller": "did:example:123456789abcdefghi",
- "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
- }],
- "service": [{
- "id":"did:example:123456789abcdefghi#vcs",
- "type": "VerifiableCredentialService",
- "serviceEndpoint": "https://example.com/vc/"
- }]
-}
-```
-
-A corresponding example Verifiable Credential, where the subject (who the credential is issued to) is a DID:
-
-```
-{
- "@context": [
- "https://www.w3.org/2018/credentials/v1",
- "https://www.w3.org/2018/credentials/examples/v1"
- ],
- "id": "http://example.edu/credentials/3732",
- "type": ["VerifiableCredential", "UniversityDegreeCredential"],
- "credentialSubject": {
- "id": "did:example:123456789abcdefghi",
- "degree": {
- "type": "BachelorDegree",
- "name": "Bachelor of Science and Arts"
- }
- },
- "proof": { ... }
-}
-```
-
-
-## How Does Someone Get a DID?
-
-There are two paths to get a DID: claim one yourself or join an Identity Platform that facilitates DIDs. A list of DID methods that are in development is [provided by the W3C](https://w3c.github.io/did-spec-registries/#did-methods). At present, there are over 50 DID methods! Each DIDs can be [“resolved”](https://w3c.github.io/did-core/#resolution) to a DID Document expressing information about the holder by resolvers that support the relevant DID method. Multiple DID resolution services have arisen, one such is hosted by the [DIF here](https://dev.uniresolver.io/).
-
-Typically, recipients will get a DID upon joining an Identity Platform supporting DIDs. There are a number of companies currently in or joining the Identity space to facilitate individuals getting DIDs. To obtain more information on a specific DID method, and how to attain a DID for that method, it is recommended to go to the [DID registry](https://w3c.github.io/did-spec-registries/#did-methods) and find the method-specific documentation.
-
-Recipients can have a single DID or multiple DIDs for greater privacy. DID management typically requires extensive infrastructure. When looking to claim a DID it is important to consider what a DID method, and Identity Platform provide for you: what security practices are being followed, what is the backing store for the DID, who makes up the organization(s) controlling the DID method, what are the legal implications of claiming such a DID, what DID operations are supported, and what control are you giving up, if any, in claiming a certain DID?
-
-## Why DIDs Make Open Badges Better
-
-The benefits of adding DIDs to Open Badges can be broken into three key points: security, portability, and interoperability.
-
-As of Open Badges v2.0, trust in Open Badges is obtained in two ways: signed assertions and hosting. Both are viable methods that allow for trusted interactions with Badges allowing Badges to be transmitted as JWTs and trust to be derived from a web host, often over TLS. Adding DIDs to Badges would allow new trust interactions. One could challenge a recipient to prove they control a DID, or, a Badge can be wrapped in a [Verifiable Presentation](https://w3c.github.io/vc-data-model/#presentations-0). Adding DIDs to Badges could even invite new signed assertion mechanisms using [Linked Data Proofs](https://w3c-ccg.github.io/ld-proofs). Giving DIDs to recipients enables individual attestation by design. Giving DIDs to issuers enables trusted issuance of Badges to trusted parties.
-
-Portability is the next important point. Most often, today, we see Badges in a Badge-host backpack. By adopting DIDs, Badges become more _[self sovereign](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)_ meaning that individuals can take control of their data without having to trust a corporation or other intermediary. With DIDs in a Badges, combined with innovations like the Badge Connect API, Badges could move freely between backpacks or other digital wallets a user controls.
-
-If we consider corporate email addresses, we find another portability benefit of moving to DIDs. With a corporate email address an individual may be issued an achievement in the form of a Badge that represents some training completed. Sometimes, this training may be useful to future employers; however, once an individual leaves a company they likely do not have access to their corporate email address, and consequently lose access to their Badge. If the Badge, instead, was issued to a DID, the individual would retain control of their DID and achievement independent of their employer. This is one such example, though many more can be imagined, that show the strength of user-centric identity that is decentralized and portable.
-
-Another strong benefits to DIDs is that they themselves are cryptographically verifiable. There are up-and-coming challenge protocols to better facilitate verifiability, but the concept is straight from a security textbook: if you claim to control a private key, I can challenge you to prove that control if I know your public key. DIDs expose public keys for exactly this purpose. Unlike email addresses, where other schemes like email-verification-links or seperate multi-factor-auth (MFA) solutions are needed, DIDs are verifiable out of the box.
-
-The last main benefit of adding DIDs to Open Badges is interoperability. Open Badges are an excellent technology for displaying achievement. There are other technologies that have complementary strengths like [Verifiable Credentials](https://w3c.github.io/vc-data-model), which aren't so user friendly or visually appealing, but do contain trusted data in a similar way to Badges. Verifiable Credentials are one of many technologies utilizing DIDs, that could interoperate with Open Badges should they share the same recipient type. Tie-ins to other DID-infrastructure both strengthens the capabilities and reach of Open Badges, while simultaneously building a stronger decentralized ecosystem.
-
-DIDs in Badges give new optionality to issuers and recipients operating in the Badging ecosystem, enabling, if one wishes, high-trust interactions, tie-in to other up-and-coming standards, and contributes to a narrative of user-centric data.
-
-## Considerations for DIDs in Open Badges
-
-Though Decentralized Identifiers are an official W3C specification, they have yet to see widespread adoption. Drawbacks in this sense are similar to drawbacks for all new, or up-and-coming technologies. We believe this drawback is minimized by the endorsement of the DID specification by the W3C, and a number of prominent technology companies and enthusiasts.
-
-Additionally, introducing DIDs welcomes complexity around trust interactions and dealing with cryptographic operations. It is not trivial to properly implement systems that handle key management, signing, and verification. Much dilligence and attention must be paid to properly adhereing to security standards and guidelines, and keeping an eye on the space for potential vulnerabilities, leaks, and the advancement of the technology at hand.
-
-Related to the previous point is the fact that not all DID methods are created equal. For example, if we take a look at the [did:key](https://w3c-ccg.github.io/did-method-key/) method we can see it is a fairly lightweight DID. The method is legitimate, and has appropriate uses, but, it lacks _key rotation_, _deactivation_, and numerous other properties of robustness that other DID methods offer. It may not be the best choice when advocating for _durable_ DIDs. This same scrutiny should be applied to all DID methods that implementers choose to support when incorporating DIDs in Badges.
-
-The proposal as it stands is an optional addition to the specification. Those who do not choose to uptake it will still be compliant with the Open Badge standard. However, as we see an increase in mobility for Badges, with the Connect API, there may be uptake required for Badging Platforms to support DIDs in Badges.
-
-# Sample Changes to Open Badge Specification
-
-## Modified Profile Identifier Properties
-When [Profiles](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Profile) are referenced elsewhere in the Open Badges Specification, they may be identified precisely by dereferenceable id, such as when a [BadgeClass](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#BadgeClass) links to an issuer Profile by its id URL. Other times, such as when identifying the recipient of an [Assertion](https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Assertion), Profiles may be identified by the value of a specific property unique to the individual or organization represented in a Profile. All properties that serve as profile identifiers must have values with a string datatype.
-
-Properties considered serviceable identifiers include:
-
-**email**
-
-**url**
-
-**telephone**
-
-**id**
-
-Many platforms that allow badge issuers and recipients to establish their identities as Profiles support only [email](https://schema.org/email) as an identifier property.
diff --git a/ob_next/roadmap.md b/ob_next/roadmap.md
deleted file mode 100644
index c73df9af..00000000
--- a/ob_next/roadmap.md
+++ /dev/null
@@ -1,68 +0,0 @@
-
-# Roadmap
-
-This document outlines the steps we believe are required to gain acceptance of DIDs in Open Badges along with usecases that align with the roadmap.
-
-
-## Tasks
-
-Tasks define tangible work items that accomplish use cases and progress the timeline.
-
- Task | Notes | Status |
-|-----------------|----------------|----------|
-| Document "What is a DID" | Present in [did-in-badges](dids-in-badges.md) | Draft |
-| Document "How to get a DID" | Present in [did-in-badges](dids-in-badges.md) | Draft |
-| Document DIDs in Badges Value Proposition | Present in [did-in-badges](dids-in-badges.md) | Draft |
-| Document Spec Changes | Present in [did-in-badges](dids-in-badges.md) | Draft |
-| Pilot Program Proposal | Propose a pilot program with a pilot roadmap, check-ins with IMS staff and workgroup, identified low-risk high-reward items, and piloting principles | TODO |
-| Extension Example | Example Extension/Additional Properties Approach AND Example next version “pure OB 2.2” of what this could look like. | TODO |
-
-
-## Use Cases
-
-The use cases listed below are what we believe to be the enumeration of problems to be solved in adding DIDs to Open Badges. The order reflect current prioritization and is subject to change.
-
- Capability | Complexity | Potential Value | Priority |
-|-----------------|----------------|-------------------|----------|
-| Prove ownership of a DID as a potential recipient | lg | lg | 1 |
-| Provide a proof that a particular host account is held by the holder of a particular DID | lg | lg | 1 |
-| Determine if a DID-based issuer identity is a trustworthy representation of a real-world (“meatspace”) organization | lg | lg | 1 |
-| Award a badge to a DID-based recipient | sm | md | 2 |
-| Claim a DID as a recipient and present it to issuer & host | med | med | 2 |
-| Include DID-based profile identification in Badge Connect APIs | med | med | 3 |
-| Use a DID as an issuer identifier, tied to signing keys for assertions | med | lg | 3 |
-| Describe a Badge Connect service (SIOP?) that I use in my DID document | med | med | 3 |
-
-## Timeline
-
-The timeline proposed is broken into three stages of three month intervals. The timeline is subject to changes.
-
-### Stage 1
-
-**August 2020 - October 2020**
-
-- Recipient brings a DID to an Issuer platform. Issuer platform verifies their control of DID
-- Alternatively an Issuer can generate DID for a Recipient
-- Consumer trusts Issuer validation for a Recipient’s control of DID
-- Create first draft of the specification
-- Create supporting documentation for working with DIDs
-- Create working sample as an OB Extension
-
-### Stage 2
-
-**October 2020 - December 2020**
-
-- Look to standardize on technical standard (e.g. OIDC SIOP) for Issuers to validate Recipient control of DID
-- Support DIDs in Badge Connect
-- Look for two Badge Platforms to trial use of DIDs
-- Refine supported DIDs based on experiences from Stage 1
-- Update draft specification
-
-### Stage 3
-
-**December 2020 - February 2021**
-
-- Look to standardize on technical standard for Open Badge stakeholders (Backpacks, Displayers, Consumers) to validate Recipient control of DID
-- Finalize specification
-- Create compliance tooling
-- Make it into OB v.Next
diff --git a/ob_next/use-cases.md b/ob_next/use-cases.md
deleted file mode 100644
index 0230fc71..00000000
--- a/ob_next/use-cases.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Open Badges Next Use Cases
-
-This document contains use cases submitted by the members of the Open Badges Workgroup for consideration in the next
-version of the Open Badges Specification. Each use case contains a title, user stories and/or information about a
-specific problem or opportunity, information about the motivation or importance, and a description of a
-specification-level capability or restriction that could serve the use case when implemented in the ecosystem. New use
-cases may be submitted by pull request. All information submitted must be compatible with IMS Global intellectual
-property rights policies for open implementation of specifications resulting from the contribution.
-
-When the next version of the specification is assigned a version number and drafted as draft documents, selected use
-cases from this document will be incorporated, and this document will be deleted.
-
-## Describe a Rubric in a Badgeclass and associated Results in an Assertion
-As an Issuer, I would like to augment a BadgeClass with a Rubric, which is a matrix of Rubric Criteria and Performance
-Levels at which learners or recipients may be expected to perform.
-
-I would like to augment an Assertion of a BadgeClass that features a Rubric with a Result, which describes how a
-particular learner or recipient performed in terms of an achieved Performance Level for one or more Rubric Criteria in
-the BadgeClass that this Assertion recognizes.
-
-The related Comprehensive Learner Record specification added the concept of
-[ResultDescription](https://www.imsglobal.org/sites/default/files/spec/clr/v1p0/InfoModel/clr_InfoModel.html#Data_ResultDescription)
-and [Result](https://www.imsglobal.org/sites/default/files/spec/clr/v1p0/InfoModel/clr_InfoModel.html#Data_Result) to
-CLR Achievements (BadgeClass) and Assertions, respectively. This concept is a natural fit with the matching Open Badges
-classes and could be imported into the Open Badges Specification to enable badge issuers to describe the available
-performance levels that assessments may recognize for a BadgeClass and the performance levels particular learners
-achieved. Each ResultDescription has an identifier that is unique within the BadgeClass, and each Result in the
-Assertion identifies which ResultDescription it applies to and which achievedLevel applies.
-
-This introduces the concept that an assertion may recognize an achievement that has not yet "passed" a threshold
-"required level". The mere existence of an Assertion may no longer be enough to recognize that the Issuer's desired
-criteria have been met to the full satisfaction of the Issuer, only that at least some progress toward those criteria
-was made. This may pose complications with systems whose existing logic relies on the existence of an assertion.
-Specific guidance for interpretation by inspectors or consumers should be provided in the specification for how such
-assertions should be interpreted.
-
-The value of incorporating Rubrics into Open Badges comes from the ability to better describe achievement at a more
-granular level. This potentially results in capabilities like understanding how an individual's skill has improved over
-time across multiple Assertions of the same BadgeClass. Additionally, application forms and assessment forms within
-applications that serve issuers might be automatically generated from Rubric data.
diff --git a/ob_v3p0/api.html b/ob_v3p0/api.html
index d08770b7..7bb17aed 100644
--- a/ob_v3p0/api.html
+++ b/ob_v3p0/api.html
@@ -34,13 +34,13 @@
diff --git a/ob_v3p0/cert/displayer.md b/ob_v3p0/cert/displayer.md
index 4f392d62..841738d2 100644
--- a/ob_v3p0/cert/displayer.md
+++ b/ob_v3p0/cert/displayer.md
@@ -8,7 +8,7 @@ An Open Badges Displayer is an application that displays and verifies badges for
The tests within this section refer to possible values of the status of a badge. The meaning of these values and how to determine them from a credential is defined in sections 9.1 and 9.2 of [[OB-30]]. As a quick summary:
- - A Credential is revoked if the \`credentialStatus\` property is present, and the \`type\` of the CredentialStatus object is "1EdTechRevocationList".
+ - A Credential is revoked if the \`credentialStatus\` property is present, and the \`type\` of the CredentialStatus object is "BitstringStatusListEntry", and the \`statusPurpose\` of the CredentialStatus object is "revocation".
- A Credential is expired if the current date and time is after the \`validUntil\`.
### Tests {#display-tests}
diff --git a/ob_v3p0/cert/ob-cert-v3p0.html b/ob_v3p0/cert/ob-cert-v3p0.html
index e040dd0f..e48d1afb 100644
--- a/ob_v3p0/cert/ob-cert-v3p0.html
+++ b/ob_v3p0/cert/ob-cert-v3p0.html
@@ -23,9 +23,9 @@
specNature: "normative", // spec nature is "normative" or "informative"
specType: "cert", // spec type is "main", "cert", "impl", "errata" or other agreed upon string
specVersion: "3.0",
- docVersion: "1.3",
+ docVersion: "1.4",
specStatus: "Final Release",
- specDate: "December 12, 2025",
+ specDate: "April 17, 2026",
contributors: _contributors,
localBiblio: _localBiblio,
iprs: _iprs,
@@ -123,6 +123,14 @@
Revision History
Added JSON-LD Safe mode requirement for issuer certification profile.
+
+
Final
+
1.4
+
April 17, 2026
+
+ Updated revocation mechanism in Displayer certification profile.
+
+
diff --git a/ob_v3p0/common_credentials.lines b/ob_v3p0/common_credentials.lines
index df97d15b..0f41cf31 100644
--- a/ob_v3p0/common_credentials.lines
+++ b/ob_v3p0/common_credentials.lines
@@ -471,7 +471,7 @@ Package SharedApiDataModels DataModel
Package SharedApiSecurityDataModels DataModel
- Class ServiceDescriptionDocument Unordered false [] "The Service Description Document (SDD) is a machine readable document that contains the description of the service features supported by the Provider/Platform. The SDD is an OpenAPI 3.0 (JSON) [[OPENAPIS-3.0]] structured document that MUST be a profiled version of the OpenAPI 3.0 (JSON) file provided provided with this specification. This 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." "n:Only a subset of the object properties are shown here."
+ Class ServiceDescriptionDocument Unordered false [] "The Service Description Document (SDD) is a machine readable document that contains the description of the service features supported by the Provider/Platform. The SDD is an OpenAPI 3.0 (JSON) [[OPENAPIS-3.0]] structured document that MUST be a profiled version of the OpenAPI 3.0 (JSON) file provided with this specification. This 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." "n:Only a subset of the object properties are shown here."
Property openapi String 1 "This string MUST be the semantic version number of the OpenAPI Specification version that the OpenAPI document uses. The openapi field SHOULD be used by tooling specifications and clients to interpret the OpenAPI document. This is not related to the API info.version string."
Property info OpenApiInfo 1 "Information about the API and the [=resource server=]." "n:The proprietary fields `x-imssf-image` and `x-imssf-privacyPolicyUrl` are found here."
Property components OpenApiComponents 1 "Holds a set of reusable objects for different aspects of the OAS." "n:The proprietary field `x-imssf-registrationUrl` is found in the `securitySchemes` components."
diff --git a/ob_v3p0/errata/errata.md b/ob_v3p0/errata/errata.md
index 16c7d909..fb62a79d 100644
--- a/ob_v3p0/errata/errata.md
+++ b/ob_v3p0/errata/errata.md
@@ -26,12 +26,14 @@ Previous versions of the context file will remain accessible, in order to keep b
#### version 3.0.3
+
- `@id` of `image` in `Achievement` now points to `https://purl.imsglobal.org/spec/vc/ob/vocab.html#image`
- `@id` of `achievement` in `AchievementSubject` now points to `https://purl.imsglobal.org/spec/vc/ob/vocab.html#achievement`
- `@id` of `image` in `AchievementSubject` now points to `https://purl.imsglobal.org/spec/vc/ob/vocab.html#image`
- `@id` of `image` in `Profile` now points to `https://purl.imsglobal.org/spec/vc/ob/vocab.html#image`
#### version 3.0.2
+
- Added `@protected` to all `@context`.
- `"@type": "xsd:string"`` was removed where it appears. This is the default type, but in rare cases, processing systems handle an explicit declaration of this type differently from allowing the default. For VCs, it is considered more reliable to just allow the default to be applied.
- `id` and `type`` aliases are redeclared in every context. This avoids a narrow type of attack where somebody might place a context that redeclares these terms in between the top layer and a class-specific layer of a credential, changing the values of these terms within the class implementation.
@@ -72,3 +74,10 @@ algorithm to use in Open Badges. Concretely, it stated:
This statement may not follow the security requirements of the future as
the securing mechanisms evolve over time. Therefore, the specific list of
allowed proof formats have been extracted out the [[[OB-CERT-30]]].
+
+### Typography Errors
+
+Section [B.4.1 Service Description Document](https://www.imsglobal.org/spec/ob/v3p0#servicedescriptiondocument)
+contains an extra `provided` in its description:
+
+> ...profiled version of the OpenAPI 3.0 (JSON) file _provided provided_ with this specification...
diff --git a/ob_v3p0/errata/ob_err_v3p0.html b/ob_v3p0/errata/ob_err_v3p0.html
index dc797508..8932d1fb 100644
--- a/ob_v3p0/errata/ob_err_v3p0.html
+++ b/ob_v3p0/errata/ob_err_v3p0.html
@@ -37,9 +37,9 @@
specNature: 'informative', // spec nature is "normative" or "informative"
specType: 'errata', // spec type is "main", "cert", "impl", "errata" or other agreed upon string
specVersion: '3.0',
- docVersion: '1.3',
+ docVersion: '1.4',
specStatus: "Final Release",
- specDate: 'July 17, 2024',
+ specDate: 'February 25, 2026',
contributors: _contributors,
localBiblio: _localBiblio
}
@@ -108,6 +108,14 @@
Revision History
Fixed typography errors in the errata document.
+
+
Version 3.0 Final
+
1.4
+
February 25, 2026
+
+ Added typography errors in the errata document.
+
{
@@ -99,7 +99,8 @@
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3732",
"type": [
@@ -134,28 +135,30 @@
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
"type": "1EdTechCredentialRefresh"
},
- "proof": [
- {
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
- "proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
- }
- ]
+ "proof": [{
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z27zr9VnabHMVwHsrqu9j8mSmm6Yp2cJCrMcg4Cownc8h7kw4qwMkxFHdg8h4CVYVK1TGd1vgoPBgFkQodMtjWQ8f"
+ }]
},
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3733",
"type": [
@@ -190,8 +193,11 @@
}
],
"credentialStatus": {
- "id": "https://state.gov/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://state.gov/credentials/3732",
@@ -199,12 +205,12 @@
},
"proof": [
{
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:25:59Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC",
- "proofPurpose": "assertionMethod",
- "proofValue": "z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC"
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z4TUqPBaJx7Ld3QMxMy25dRU29fAPEwemPEUEZSRDS979nUKtfon7zu6ocgRyRCniXE9heY46NKPzwbFdqmKbUhkG"
}
]
}
@@ -263,7 +269,8 @@
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3734",
"type": [
@@ -298,8 +305,11 @@
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -308,11 +318,11 @@
"proof": [
{
"type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "proofValue": "z3R4NfPDo67k5AXBqCLcqsFo9grbWND3zkQYSvBRFwYZ1JjZE5z4FBnpFNrckzSvDHPekBsyy5z8RL4H3J9r5VUGF"
}
]
}
@@ -512,7 +522,8 @@
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3735",
"type": [
@@ -547,8 +558,11 @@
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -557,11 +571,11 @@
"proof": [
{
"type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "proofValue": "z3PbutAvPaLRfYRqSex4XcAcpBqj3Vhx5vxpCxtngeTuXoutFUx3yRf7J7yrc1vL8oksMWt7FVAa4ryd9XLpnKdQA"
}
]
}
@@ -602,7 +616,8 @@
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3736",
"type": [
@@ -637,8 +652,11 @@
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -646,12 +664,12 @@
},
"proof": [
{
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
- "proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z3KqayPvBkJ196JzwYTgjuxZTYd7XQFSCauLg3Lo2xZKCcQTewydijTwfTouadyf2jBVYqAZg1CWXnug5JZkivUP6"
}
]
}
@@ -709,8 +727,11 @@
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
diff --git a/ob_v3p0/microsites/spec/ob-v3p0.md b/ob_v3p0/microsites/v3p0.md
similarity index 94%
rename from ob_v3p0/microsites/spec/ob-v3p0.md
rename to ob_v3p0/microsites/v3p0.md
index e3d6f02e..236afeee 100644
--- a/ob_v3p0/microsites/spec/ob-v3p0.md
+++ b/ob_v3p0/microsites/v3p0.md
@@ -4,7 +4,7 @@ category: Specification
title: Open Badges Specification
shortcode: OB-30
status: Final
-lastUpdated: November 6, 2025
+lastUpdated: 2025-11-06
version: '3.0'
nature: normative
docType: specification
@@ -104,123 +104,131 @@ contributors:
role: Editor
ipDisclosures:
- organization: Concentric Sky
- date: October 24, 2019
+ date: 2019-10-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Arizona State University
- date: June 21, 2022
+ date: 2022-06-21
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Temple University
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Credly
- date: October 3, 2019
+ date: 2019-10-03
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Workday, Inc.
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: RANDA Solutions
- date: June 9, 2022
+ date: 2022-06-09
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Anthology
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Unicon
- date: April 22, 2024
+ date: 2024-04-22
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Bowdoin College
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
- organization: American Association of Collegiate Registrars and Admissions Officers (AACARO)
- date: April 15, 2024
+ date: 2024-04-15
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Desire to Learn (D2L)
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Digital Knowledge EdTech Lab Inc.
- date: April 24, 2024
+ date: 2024-04-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: IQC Italian Quality Company
- date: April 19, 2024
+ date: 2024-04-19
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Skybridge Skills
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Navigatr
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: T3 Innovation Network, US Chamber of Commerce Foundation
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Territorium
- date: April 23, 2024
+ date: 2024-04-23
claim: false
type: RF RAND (Required & Optional Elements)
- organization: 'Western Governors University (WGU) '
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
releases:
- version: "Candidate Final"
docVersion: "1.0"
- date: July 14, 2022"
+ date: 2022-07-14
comments: "Open Badges 3.0 first Candidate Final release"
- version: "Candidate Public Final"
docVersion: "1.0.1"
- date: "February 9, 2023"
+ date: 2023-02-09
comments: "Open Badges 3.0 first Candidate Public Final release"
- version: "Final"
docVersion: "1.0"
- date: "May 27, 2024"
+ date: 2024-05-27
comments: "Open Badges 3.0 Final Release"
- version: "Final"
docVersion: "1.1"
- date: "July 26, 2024"
+ date: 2024-07-26
comments: "Fixed some typos. See [[OB-ERRATA-30]]\nAdded [[VC-DATA-MODEL-1.1]] compatible JSON schema in Document Set"
- version: "Final"
docVersion: "1.2"
- date: "Dec 23, 2024"
+ date: 2024-12-23
comments: "Clarified proof mechanism and algorithm selection. See [[OB-ERRATA-30]]"
- version: "Final"
docVersion: "1.3"
- date: "October 9, 2025"
+ date: 2025-10-09
comments: "Updated JSON Schemas with support for [[JSON-LD11-API]] compaction process\nDeprecated [[VCRL-10]] in favour of [[vc-bitstring-status-list]]"
- version: "Final"
docVersion: "1.4"
- date: "October 14, 2025"
+ date: 2025-10-14
comments: "Credential Status' id is an optional field as defined at [[vc-data-model-2.0]]"
- version: "Final"
docVersion: "1.4.1"
- date: "November 6, 2025"
+ date: 2025-11-06
comments: "Updated JSON-LD Context, adding the term `jti`"
+ - version: "Final"
+ docVersion: "1.4.2"
+ date: 2026-04-17
+ comments: "Updated CredentialStatus of all examples to BitstringStatusListEntry"
+ - version: "Final"
+ docVersion: "1.4.3"
+ date: 2026-04-22
+ comments: "Fixed links to OpenAPI files in Open Badges API section"
---
-@spec/abstract.md
+@standards/v3p0/spec/abstract.md
-@spec/introduction.md
+@standards/v3p0/spec/introduction.md
-@spec/overview.md
+@standards/v3p0/spec/overview.md
-@spec/usecases.md
+@standards/v3p0/spec/usecases.md
-@spec/gettingstarted.md
+@standards/v3p0/spec/gettingstarted.md
-@spec/docformat.md
+@standards/v3p0/spec/docformat.md
# Open Badges API
@@ -232,8 +240,8 @@ The API defined here is intended for [=Clients=] and [=servers=] that give indiv
In addition to the documentation in this section, there are [OpenAPI](#docs-openapi) files for the Open Badges API in both JSON and YAML format:
-* [JSON OpenAPI File](https://purl.imsglobal.org/spec/ob/v3p0/schema/openapi/imsob_v3p0.json)
-* [YAML OpenAPI File](https://purl.imsglobal.org/spec/ob/v3p0/schema/openapi/imsob_v3p0.yaml)
+* [JSON OpenAPI File](https://purl.imsglobal.org/spec/ob/v3p0/schema/openapi/ob_v3p0_oas.json)
+* [YAML OpenAPI File](https://purl.imsglobal.org/spec/ob/v3p0/schema/openapi/ob_v3p0_oas.yaml)
## Architecture
@@ -974,11 +982,11 @@ When the request for revocation is rejected, the [=authorization server=] return
-@spec/integrity.md
+@standards/v3p0/spec/integrity.md
-@spec/verification.md
+@standards/v3p0/spec/verification.md
-@spec/equality-and-comparison.md
+@standards/v3p0/spec/equality-and-comparison.md
# Verifiable Credentials Extensions
@@ -993,7 +1001,7 @@ This standard references four VC Extensions:
> **Note**: The 1EdTech extensions are designed to work with any [=verifiable credential=] and may be contributed to the [[VC-EXTENSION-REGISTRY]] in the future.
-@spec/serialization.md
+@standards/v3p0/spec/serialization.md
# Data Models
@@ -1070,7 +1078,7 @@ title: Verification Support Data Models
The data models in this section are used by the [[[#verification-and-validation]]] process for supporting older credentials created with [[VC-DATA-MODEL-1.1]].
-@spec/extending.md
+@standards/v3p0/spec/extending.md
# Examples
@@ -1117,7 +1125,7 @@ In this example, all required and optional properties are populated.
> **Note**: The endorsements were signed by different issuers and provided to the issuer of this OpenBadgeCredential.
```obv3p0 org.1edtech.ob.v3p0.achievementcredential.class
-{
+ {
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
@@ -1210,7 +1218,8 @@ In this example, all required and optional properties are populated.
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3732",
"type": [
@@ -1245,28 +1254,30 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
"type": "1EdTechCredentialRefresh"
},
- "proof": [
- {
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
- "proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
- }
- ]
+ "proof": [{
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z27zr9VnabHMVwHsrqu9j8mSmm6Yp2cJCrMcg4Cownc8h7kw4qwMkxFHdg8h4CVYVK1TGd1vgoPBgFkQodMtjWQ8f"
+ }]
},
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3733",
"type": [
@@ -1301,8 +1312,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://state.gov/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://state.gov/credentials/3732",
@@ -1310,12 +1324,12 @@ In this example, all required and optional properties are populated.
},
"proof": [
{
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:25:59Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC",
- "proofPurpose": "assertionMethod",
- "proofValue": "z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC"
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z4TUqPBaJx7Ld3QMxMy25dRU29fAPEwemPEUEZSRDS979nUKtfon7zu6ocgRyRCniXE9heY46NKPzwbFdqmKbUhkG"
}
]
}
@@ -1374,7 +1388,8 @@ In this example, all required and optional properties are populated.
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3734",
"type": [
@@ -1409,8 +1424,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -1419,11 +1437,11 @@ In this example, all required and optional properties are populated.
"proof": [
{
"type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "proofValue": "z3R4NfPDo67k5AXBqCLcqsFo9grbWND3zkQYSvBRFwYZ1JjZE5z4FBnpFNrckzSvDHPekBsyy5z8RL4H3J9r5VUGF"
}
]
}
@@ -1623,7 +1641,8 @@ In this example, all required and optional properties are populated.
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3735",
"type": [
@@ -1658,8 +1677,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -1668,11 +1690,11 @@ In this example, all required and optional properties are populated.
"proof": [
{
"type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "proofValue": "z3PbutAvPaLRfYRqSex4XcAcpBqj3Vhx5vxpCxtngeTuXoutFUx3yRf7J7yrc1vL8oksMWt7FVAa4ryd9XLpnKdQA"
}
]
}
@@ -1713,7 +1735,8 @@ In this example, all required and optional properties are populated.
{
"@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/context-3.0.3.json",
+ "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/endorsementcredential/3736",
"type": [
@@ -1748,8 +1771,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -1757,12 +1783,12 @@ In this example, all required and optional properties are populated.
},
"proof": [
{
- "type": "DataIntegrityProof",
- "cryptosuite": "eddsa-rdf-2022",
- "created": "2022-05-26T18:17:08Z",
- "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
- "proofPurpose": "assertionMethod",
- "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
+ "type": "DataIntegrityProof",
+ "created": "2010-01-01T19:23:24Z",
+ "verificationMethod": "https://accrediter.edu/issuers/565049#z6MkqHLdLYHwKr169xzu9qvH1cq94pUjeQpfrPU5Xv3MtNzt",
+ "cryptosuite": "eddsa-rdfc-2022",
+ "proofPurpose": "assertionMethod",
+ "proofValue": "z3KqayPvBkJ196JzwYTgjuxZTYd7XQFSCauLg3Lo2xZKCcQTewydijTwfTouadyf2jBVYqAZg1CWXnug5JZkivUP6"
}
]
}
@@ -1820,8 +1846,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://1edtech.edu/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://1edtech.edu/credentials/3732",
@@ -1868,8 +1897,11 @@ In this example, all required and optional properties are populated.
}
],
"credentialStatus": {
- "id": "https://state.gov/credentials/3732/revocations",
- "type": "1EdTechRevocationList"
+ "id": "https://1edtech.edu/credentials/revocationList#23",
+ "type": "BitstringStatusListEntry",
+ "statusPurpose": "revocation",
+ "statusListIndex": 23,
+ "statusListCredential": "https://1edtech.edu/credentials/revocationList"
},
"refreshService": {
"id": "http://state.gov/credentials/3732",
diff --git a/ob_v3p0/microsites/cert/ob-cert-v3p0.md b/ob_v3p0/microsites/v3p0/cert.md
similarity index 87%
rename from ob_v3p0/microsites/cert/ob-cert-v3p0.md
rename to ob_v3p0/microsites/v3p0/cert.md
index ce4df5c5..9405fc9f 100644
--- a/ob_v3p0/microsites/cert/ob-cert-v3p0.md
+++ b/ob_v3p0/microsites/v3p0/cert.md
@@ -4,7 +4,7 @@ category: Certification
title: Open Badges Specification Conformance and Certification Guide
shortcode: OB-CERT-30
status: Final
-lastUpdated: December 12, 2025
+lastUpdated: 2025-12-12
version: '3.0'
nature: normative
docType: conformance
@@ -104,108 +104,108 @@ contributors:
role: Editor
ipDisclosures:
- organization: Concentric Sky
- date: October 24, 2019
+ date: 2019-10-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Arizona State University
- date: June 21, 2022
+ date: 2022-06-21
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Temple University
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Credly
- date: October 3, 2019
+ date: 2019-10-03
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Workday, Inc.
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: RANDA Solutions
- date: June 9, 2022
+ date: 2022-06-09
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Anthology
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Unicon
- date: April 22, 2024
+ date: 2024-04-22
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Bowdoin College
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
- organization: American Association of Collegiate Registrars and Admissions Officers (AACARO)
- date: April 15, 2024
+ date: 2024-04-15
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Desire to Learn (D2L)
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Digital Knowledge EdTech Lab Inc.
- date: April 24, 2024
+ date: 2024-04-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: IQC Italian Quality Company
- date: April 19, 2024
+ date: 2024-04-19
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Skybridge Skills
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Navigatr
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: T3 Innovation Network, US Chamber of Commerce Foundation
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Territorium
- date: April 23, 2024
+ date: 2024-04-23
claim: false
type: RF RAND (Required & Optional Elements)
- organization: 'Western Governors University (WGU) '
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
releases:
- version: Candidate Public Final
docVersion: 1.0
- date: November 10, 2022
+ date: 2022-11-10
comments: Open Badges 3.0 first Candidate Public Final release
- version: Final
docVersion: 1.0
- date: May 27, 2024
+ date: 2024-05-27
comments: Open Badges 3.0 Final Release
- version: Final
docVersion: 1.1
- date: Dec 23, 2024
+ date: 2024-12-23
comments: Added supported proof mechanisms for Issuer.\nAdded supported proof mechanisms for Displayer. Removed invalid Host tests.
- version: Final
docVersion: 1.2
- date: July 11, 2025
+ date: 2025-07-11
comments: Added ECDSA Cryptosuite ecdsa-sd-2023 to Issuer and Displayer supported proof mechanisms.
- version: Final
docVersion: 1.3
- date: December 12, 2025
+ date: 2025-12-12
comments: Added JSON-LD Safe mode requirement for issuer certification profile.
---
-@cert/abstract.md
+@standards/v3p0/cert/abstract.md
-@cert/introduction.md
+@standards/v3p0/cert/introduction.md
-@cert/conformance.md
+@standards/v3p0/cert/conformance.md
-@cert/issuer.md
+@standards/v3p0/cert/issuer.md
-@cert/displayer.md
+@standards/v3p0/cert/displayer.md
-@cert/host.md
+@standards/v3p0/cert/host.md
diff --git a/ob_v3p0/microsites/cert/abstract.md b/ob_v3p0/microsites/v3p0/cert/abstract.md
similarity index 86%
rename from ob_v3p0/microsites/cert/abstract.md
rename to ob_v3p0/microsites/v3p0/cert/abstract.md
index 14e6d3b9..fef20bbf 100644
--- a/ob_v3p0/microsites/cert/abstract.md
+++ b/ob_v3p0/microsites/v3p0/cert/abstract.md
@@ -1,3 +1,12 @@
+---
+title: "Abstract"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Abstract for the Open Badges 3.0 certification document"
+---
+
## Abstract
Open Badges are visual symbols of accomplishments packed with verifiable metadata according to the Open Badges specification. The Open Badges 3.0 specification [[OB-30]] defines the properties necessary to define an achievement and award it to a recipient, as well as procedures for verifying badge authenticity and “baking” badge information into portable image files. It includes term definitions for representations of data in Open Badges and defines an API for exchanging badge information. These term definitions appear in the current Open Badges JSON-LD Context File.
diff --git a/ob_v3p0/microsites/cert/conformance.md b/ob_v3p0/microsites/v3p0/cert/conformance.md
similarity index 93%
rename from ob_v3p0/microsites/cert/conformance.md
rename to ob_v3p0/microsites/v3p0/cert/conformance.md
index c97dddd1..e2d46bce 100644
--- a/ob_v3p0/microsites/cert/conformance.md
+++ b/ob_v3p0/microsites/v3p0/cert/conformance.md
@@ -1,3 +1,12 @@
+---
+title: "Conformance and Certification"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Overview of Open Badges 3.0 conformance and certification requirements"
+---
+
## Conformance and Certification
The goal of 1EdTech certification for Open Badges [[OB-30]] is to ensure interoperable implementations of badging systems that generate and issue digital badges as well as those that host and display badges.
diff --git a/ob_v3p0/microsites/cert/displayer.md b/ob_v3p0/microsites/v3p0/cert/displayer.md
similarity index 83%
rename from ob_v3p0/microsites/cert/displayer.md
rename to ob_v3p0/microsites/v3p0/cert/displayer.md
index 93176a83..d8670cae 100644
--- a/ob_v3p0/microsites/cert/displayer.md
+++ b/ob_v3p0/microsites/v3p0/cert/displayer.md
@@ -1,3 +1,12 @@
+---
+title: "Open Badges 3.0 Displayer Service Conformance"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Displayer service conformance requirements for Open Badges 3.0 certification"
+---
+
## Open Badges 3.0 Displayer Service Conformance {#displayer-conformance}
An Open Badges Displayer is an application that displays and verifies badges for viewers. The candidate platform must support viewer-initiated verification of a badge.
@@ -6,7 +15,7 @@ An Open Badges Displayer is an application that displays and verifies badges for
The tests within this section refer to possible values of the status of a badge. The meaning of these values and how to determine them from a credential is defined in sections 9.1 and 9.2 of [[OB-30]]. As a quick summary:
- - A Credential is revoked if the `credentialStatus` property is present, and the `type` of the CredentialStatus object is "1EdTechRevocationList".
+ - A Credential is revoked if the \`credentialStatus\` property is present, and the \`type\` of the CredentialStatus object is "BitstringStatusListEntry", and the \`statusPurpose\` of the CredentialStatus object is "revocation".
- A Credential is expired if the current date and time is after the `validUntil`.
### Tests {#display-tests}
diff --git a/ob_v3p0/microsites/cert/host.md b/ob_v3p0/microsites/v3p0/cert/host.md
similarity index 97%
rename from ob_v3p0/microsites/cert/host.md
rename to ob_v3p0/microsites/v3p0/cert/host.md
index a1e10ef4..37f82a63 100644
--- a/ob_v3p0/microsites/cert/host.md
+++ b/ob_v3p0/microsites/v3p0/cert/host.md
@@ -1,3 +1,12 @@
+---
+title: "Open Badges 3.0 Host Service Conformance"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Host service conformance requirements for Open Badges 3.0 certification"
+---
+
## Open Badges 3.0 Host Service Conformance {#host-conformance}
An Open Badges **Host** is an application that can aggregate and publicly host OpenBadgeCredential for recipients. It also supports export of badges at user request. The candidate platform must be able to import all formats of Open Badges as well as prove that badge metadata is not lost upon export of the badge. The candidate platform must also meet [[[#service-provider-write]]] requirements and accept an AchievementCredential or a Profile from an Issuer application. And meet [[[#service-consumer-read]]] and [[[#service-provider-read]]] requirements for exchanging AchievementCredentials with other Host applications.
diff --git a/ob_v3p0/microsites/cert/introduction.md b/ob_v3p0/microsites/v3p0/cert/introduction.md
similarity index 95%
rename from ob_v3p0/microsites/cert/introduction.md
rename to ob_v3p0/microsites/v3p0/cert/introduction.md
index a3caf712..204a90cc 100644
--- a/ob_v3p0/microsites/cert/introduction.md
+++ b/ob_v3p0/microsites/v3p0/cert/introduction.md
@@ -1,3 +1,12 @@
+---
+title: "Introduction"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Introduction for Open Badges 3.0 certification"
+---
+
## Introduction
### Conformance Statements {#conformance}
diff --git a/ob_v3p0/microsites/cert/issuer.md b/ob_v3p0/microsites/v3p0/cert/issuer.md
similarity index 94%
rename from ob_v3p0/microsites/cert/issuer.md
rename to ob_v3p0/microsites/v3p0/cert/issuer.md
index 0dafab89..59a00183 100644
--- a/ob_v3p0/microsites/cert/issuer.md
+++ b/ob_v3p0/microsites/v3p0/cert/issuer.md
@@ -1,3 +1,12 @@
+---
+title: "Open Badges 3.0 Issuer Service Conformance"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Issuer service conformance requirements for Open Badges 3.0 certification"
+---
+
## Open Badges 3.0 Issuer Service Conformance {#issuer-conformance}
A Open Badges **Issuer** is an application that allows for the creation of OpenBadgeCredentials and the subsequent delivery of OpenBadgeCredentials to recipients that conform to the Open Badges Specification. The candidate platform must issue a valid badge and demonstrate how the badge is retrieved by the recipient. The candidate platform may also meet Service Consumer (Write) requirements and can send an AchievementCredential or a Profile to a product that conforms to Service Provider (Write) requirements.
diff --git a/ob_v3p0/microsites/errata/ob-err-v3p0.md b/ob_v3p0/microsites/v3p0/errata.md
similarity index 94%
rename from ob_v3p0/microsites/errata/ob-err-v3p0.md
rename to ob_v3p0/microsites/v3p0/errata.md
index 98c18231..838a0359 100644
--- a/ob_v3p0/microsites/errata/ob-err-v3p0.md
+++ b/ob_v3p0/microsites/v3p0/errata.md
@@ -4,7 +4,7 @@ category: Specification
title: Open Badges Errata
shortcode: OB-ERRATA-30
status: Final
-lastUpdated: July 17, 2024
+lastUpdated: 2024-07-17
version: '3.0'
nature: informative
docType: errata
@@ -105,24 +105,24 @@ contributors:
releases:
- version: Version 3.0 Candidate Final
docVersion: 1.0
- date: March 6, 2023
+ date: 2023-03-06
comments: Added changes in context.json file
- version: Version 3.0 Final
docVersion: 1.0
- date: June 17, 2024
+ date: 2024-06-17
comments: Added typography errors
- version: Version 3.0 Final
docVersion: 1.1
- date: July 26, 2024
+ date: 2024-07-26
comments: Added typography errors
- version: Version 3.0 Final
docVersion: 1.2
- date: Dec 23, 2024
+ date: 2024-12-23
comments: Consolidated with version 1.2 of the specification.\nClarified proof mechanism and algorithm selection.
- version: Version 3.0 Final
docVersion: 1.3
- date: June 16, 2025
+ date: 2025-06-16
comments: Fixed typography errors in the errata document.
---
-@errata/errata.md
+@standards/v3p0/errata/errata.md
diff --git a/ob_v3p0/microsites/errata/errata.md b/ob_v3p0/microsites/v3p0/errata/errata.md
similarity index 96%
rename from ob_v3p0/microsites/errata/errata.md
rename to ob_v3p0/microsites/v3p0/errata/errata.md
index bf465999..ad6feeea 100644
--- a/ob_v3p0/microsites/errata/errata.md
+++ b/ob_v3p0/microsites/v3p0/errata/errata.md
@@ -1,3 +1,12 @@
+---
+title: "Errata for Open Badges 3.0 Specification"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Errata for the Open Badges 3.0 specification"
+---
+
## Errata for Open Badges 3.0 Specification
### Context file
diff --git a/docs/images/figure01-openbadges-2.0-diagram.png b/ob_v3p0/microsites/v3p0/images/figure01-openbadges-2.0-diagram.png
similarity index 100%
rename from docs/images/figure01-openbadges-2.0-diagram.png
rename to ob_v3p0/microsites/v3p0/images/figure01-openbadges-2.0-diagram.png
diff --git a/ob_v3p0/microsites/v3p0/images/ob30-concept.png b/ob_v3p0/microsites/v3p0/images/ob30-concept.png
new file mode 100644
index 00000000..ce31fa1b
Binary files /dev/null and b/ob_v3p0/microsites/v3p0/images/ob30-concept.png differ
diff --git a/ob_v3p0/microsites/impl/ob-impl-v3p0.md b/ob_v3p0/microsites/v3p0/impl.md
similarity index 97%
rename from ob_v3p0/microsites/impl/ob-impl-v3p0.md
rename to ob_v3p0/microsites/v3p0/impl.md
index 56d59be9..369f7e63 100644
--- a/ob_v3p0/microsites/impl/ob-impl-v3p0.md
+++ b/ob_v3p0/microsites/v3p0/impl.md
@@ -4,7 +4,7 @@ category: Guide
title: Open Badges Implementation Guide
shortcode: OB-IMPL-30
status: Final
-lastUpdated: Apr 7th, 2025
+lastUpdated: 2025-04-07
version: '3.0'
nature: informative
docType: guide
@@ -28,151 +28,151 @@ contributors:
role: Editor
ipDisclosures:
- organization: Concentric Sky
- date: October 24, 2019
+ date: 2019-10-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Arizona State University
- date: June 21, 2022
+ date: 2022-06-21
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Temple University
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Credly
- date: October 3, 2019
+ date: 2019-10-03
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Workday, Inc.
- date: June 10, 2022
+ date: 2022-06-10
claim: false
type: RF RAND (Required & Optional Elements)
- organization: RANDA Solutions
- date: June 9, 2022
+ date: 2022-06-09
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Anthology
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Unicon
- date: April 22, 2024
+ date: 2024-04-22
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Bowdoin College
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
- organization: American Association of Collegiate Registrars and Admissions Officers (AACARO)
- date: April 15, 2024
+ date: 2024-04-15
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Desire to Learn (D2L)
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Digital Knowledge EdTech Lab Inc.
- date: April 24, 2024
+ date: 2024-04-24
claim: false
type: RF RAND (Required & Optional Elements)
- organization: IQC Italian Quality Company
- date: April 19, 2024
+ date: 2024-04-19
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Skybridge Skills
- date: April 16, 2024
+ date: 2024-04-16
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Navigatr
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: T3 Innovation Network, US Chamber of Commerce Foundation
- date: April 25, 2024
+ date: 2024-04-25
claim: false
type: RF RAND (Required & Optional Elements)
- organization: Territorium
- date: April 23, 2024
+ date: 2024-04-23
claim: false
type: RF RAND (Required & Optional Elements)
- organization: 'Western Governors University (WGU) '
- date: June 11, 2022
+ date: 2022-06-11
claim: false
type: RF RAND (Required & Optional Elements)
releases:
- version: Version 3.0 IMS Candidate Final
docVersion: 1.0
- date: November 10, 2022
+ date: 2022-11-10
comments: Covers Issuer, Displayer, and Host conformance and certification.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.1
- date: June 20, 2023
+ date: 2023-06-20
comments: Updated Linked Data Proof to the new EdDSA Cryptosuite v2022 [[VC-DI-EDDSA]].
- version: Version 3.0 IMS Candidate Final
docVersion: 1.2
- date: July 14, 2023
+ date: 2023-07-14
comments: New version of the context.json (`context-3.0.2.json`) file. See [[OB-ERRATA-30]] for detailed changes
- version: Version 3.0 IMS Candidate Final
docVersion: 1.3
- date: September 8, 2023
+ date: 2023-09-08
comments: Reorganized some sections of the document to highlight Issuer, Displayer and Host roles.\nAdded recommended practice for including additional info of the recipient of a credential.\nAdded recommended practice for supporting old cryptosuites.\nAdded test vector data for signing Open Badges and Comprehensive Learner Record.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.4
- date: September 22, 2023
+ date: 2023-09-22
comments: Added a section about including older Open Badges in CLR 2.0.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.5
- date: November 9, 2023
+ date: 2023-11-09
comments: Added a section about issuer's key provenance.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.6
- date: December 13, 2023
+ date: 2023-12-13
comments: New version of the context.json (`context-3.0.3.json`) file. See [[OB-ERRATA-30]] for detailed changes
- version: Version 3.0 IMS Candidate Final
docVersion: 1.7
- date: December 15, 2023
+ date: 2023-12-15
comments: Added sections about alignment of achievements with non-1EdTech vocabularies, such Credential Engine.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.8
- date: January 26, 2023
+ date: 2023-01-26
comments: Language of related achievement now uses the new attribute `inLanguage` instead of `@language`.
- version: Version 3.0 IMS Candidate Final
docVersion: 1.9
- date: April 2, 2024
+ date: 2024-04-02
comments: Upgraded to [[VC-DATA-MODEL-2.0]]
- version: Version 3.0 IMS Candidate Final
docVersion: 1.10
- date: October 1, 2024
+ date: 2024-10-01
comments: Added section about extensions.\nAdded section about privacy.
- version: Final Release
docVersion: 1.0
- date: December 23, 2024
+ date: 2024-12-23
comments: Clarified proof mechanism and algorithm selection.
- version: Final Release
docVersion: 1.1
- date: February 12, 2025
+ date: 2025-02-12
comments: Reorganization.\nClarified some paragraphs.
- version: Final Release
docVersion: 2.0
- date: April 7, 2025
+ date: 2025-04-07
comments: Fixed some typos.
---
-@impl/introduction.md
+@standards/v3p0/impl/introduction.md
-@impl/getting-started.md
+@standards/v3p0/impl/getting-started.md
-@impl/recommended-practices.md
+@standards/v3p0/impl/recommended-practices.md
-@impl/reference-impls.md
+@standards/v3p0/impl/reference-impls.md
-@impl/conformance.md
+@standards/v3p0/impl/conformance.md
-@impl/migrating.md
+@standards/v3p0/impl/migrating.md
-@impl/extensions.md
+@standards/v3p0/impl/extensions.md
-@impl/help.md
+@standards/v3p0/impl/help.md
## Linked Data Proof Test Vector for Open Badges 3.0
diff --git a/ob_v3p0/microsites/impl/conformance.md b/ob_v3p0/microsites/v3p0/impl/conformance.md
similarity index 93%
rename from ob_v3p0/microsites/impl/conformance.md
rename to ob_v3p0/microsites/v3p0/impl/conformance.md
index bb16818f..6a8e4c3a 100644
--- a/ob_v3p0/microsites/impl/conformance.md
+++ b/ob_v3p0/microsites/v3p0/impl/conformance.md
@@ -1,3 +1,12 @@
+---
+title: "Conformance and Certification"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Conformance and certification for Open Badges 3.0 implementations"
+---
+
## Conformance and Certification{.informative}
The [[OB-CERT-30]] covers the specific requirements that implementers must cover
diff --git a/ob_v3p0/microsites/impl/extensions.md b/ob_v3p0/microsites/v3p0/impl/extensions.md
similarity index 96%
rename from ob_v3p0/microsites/impl/extensions.md
rename to ob_v3p0/microsites/v3p0/impl/extensions.md
index 918bd99b..d8c68ed7 100644
--- a/ob_v3p0/microsites/impl/extensions.md
+++ b/ob_v3p0/microsites/v3p0/impl/extensions.md
@@ -1,3 +1,12 @@
+---
+title: "Open Badges Extensions"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Open Badges 3.0 extensions"
+---
+
## Open Badges Extensions{#informative}
[Open Badges 3.0](/ob/specifications/ob-v3p0#extending) and [Comprehensive Learner Record 2.0](http://www.imsglobal.org/spec/clr/v2p0#extending) allows extensibility in several ways: data model, extensible enumerated vocabularies and API.
diff --git a/ob_v3p0/microsites/impl/getting-started.md b/ob_v3p0/microsites/v3p0/impl/getting-started.md
similarity index 99%
rename from ob_v3p0/microsites/impl/getting-started.md
rename to ob_v3p0/microsites/v3p0/impl/getting-started.md
index ca5c4bff..3d8fd322 100644
--- a/ob_v3p0/microsites/impl/getting-started.md
+++ b/ob_v3p0/microsites/v3p0/impl/getting-started.md
@@ -1,3 +1,12 @@
+---
+title: "Getting Started (for Developers)"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Getting started guide for Open Badges 3.0 developers"
+---
+
## Getting Started (for Developers){.informative}
It may seem like an overwhelming task to implement Open Badges 3.0 or CLR 2.0,
diff --git a/ob_v3p0/microsites/impl/help.md b/ob_v3p0/microsites/v3p0/impl/help.md
similarity index 83%
rename from ob_v3p0/microsites/impl/help.md
rename to ob_v3p0/microsites/v3p0/impl/help.md
index 4a9b774e..9e6955fc 100644
--- a/ob_v3p0/microsites/impl/help.md
+++ b/ob_v3p0/microsites/v3p0/impl/help.md
@@ -1,3 +1,12 @@
+---
+title: "Getting Help"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Getting help with Open Badges 3.0 implementations"
+---
+
## Getting Help{.informative}
If you have questions or need help with implementing Open Badges 3.0 or
diff --git a/ob_v3p0/microsites/impl/introduction.md b/ob_v3p0/microsites/v3p0/impl/introduction.md
similarity index 98%
rename from ob_v3p0/microsites/impl/introduction.md
rename to ob_v3p0/microsites/v3p0/impl/introduction.md
index 732375d0..43ce68c8 100644
--- a/ob_v3p0/microsites/impl/introduction.md
+++ b/ob_v3p0/microsites/v3p0/impl/introduction.md
@@ -1,3 +1,12 @@
+---
+title: "Introduction"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Introduction to the Open Badges 3.0 implementation guide"
+---
+
## Introduction
The 1EdTech digital credentials specifications, Open Badges and Comprehensive
diff --git a/ob_v3p0/microsites/impl/migrating.md b/ob_v3p0/microsites/v3p0/impl/migrating.md
similarity index 98%
rename from ob_v3p0/microsites/impl/migrating.md
rename to ob_v3p0/microsites/v3p0/impl/migrating.md
index 27e18641..3518e863 100644
--- a/ob_v3p0/microsites/impl/migrating.md
+++ b/ob_v3p0/microsites/v3p0/impl/migrating.md
@@ -1,3 +1,12 @@
+---
+title: "Migrating from OB 2.0, OB 2.1, and CLR 1.0"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Migration guide for Open Badges 3.0"
+---
+
## Migrating from OB 2.0, OB 2.1, and CLR 1.0{#informative}
Open Badges 3.0 and Comprehensive Learner Record 2.0 are major releases, and
diff --git a/ob_v3p0/microsites/impl/recommended-practices.md b/ob_v3p0/microsites/v3p0/impl/recommended-practices.md
similarity index 99%
rename from ob_v3p0/microsites/impl/recommended-practices.md
rename to ob_v3p0/microsites/v3p0/impl/recommended-practices.md
index f79aa677..8b5725a6 100644
--- a/ob_v3p0/microsites/impl/recommended-practices.md
+++ b/ob_v3p0/microsites/v3p0/impl/recommended-practices.md
@@ -1,3 +1,12 @@
+---
+title: "Recommended Practices"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Recommended practices for Open Badges 3.0 implementations"
+---
+
## Recommended Practices{.informative}
Conformance certification ensures consistency across an important but focused
diff --git a/ob_v3p0/microsites/impl/reference-impls.md b/ob_v3p0/microsites/v3p0/impl/reference-impls.md
similarity index 82%
rename from ob_v3p0/microsites/impl/reference-impls.md
rename to ob_v3p0/microsites/v3p0/impl/reference-impls.md
index 69f7d7f7..9948f13d 100644
--- a/ob_v3p0/microsites/impl/reference-impls.md
+++ b/ob_v3p0/microsites/v3p0/impl/reference-impls.md
@@ -1,3 +1,12 @@
+---
+title: "Using Reference Implementations"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Reference implementations for Open Badges 3.0"
+---
+
## Using Reference Implementations{.informative}
The Reference Implementation is an 1EdTech implementation of Open Badges 3.0 and
diff --git a/ob_v3p0/microsites/spec/abstract.md b/ob_v3p0/microsites/v3p0/spec/abstract.md
similarity index 77%
rename from ob_v3p0/microsites/spec/abstract.md
rename to ob_v3p0/microsites/v3p0/spec/abstract.md
index ef5a5114..891b5361 100644
--- a/ob_v3p0/microsites/spec/abstract.md
+++ b/ob_v3p0/microsites/v3p0/spec/abstract.md
@@ -1,3 +1,12 @@
-# Abstract
+---
+title: "Abstract"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Abstract for the Open Badges 3.0 specification"
+---
+
+## Abstract
This specification is a new version of the [1EdTech Open Badges Specification](https://www.imsglobal.org/activity/digital-badges) that aligns with the conventions of the [[VC-DATA-MODEL-2.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.
diff --git a/ob_v3p0/microsites/spec/docformat.md b/ob_v3p0/microsites/v3p0/spec/docformat.md
similarity index 97%
rename from ob_v3p0/microsites/spec/docformat.md
rename to ob_v3p0/microsites/v3p0/spec/docformat.md
index e30a82fe..bec927f6 100644
--- a/ob_v3p0/microsites/spec/docformat.md
+++ b/ob_v3p0/microsites/v3p0/spec/docformat.md
@@ -1,4 +1,13 @@
-# Open Badges Document Formats {#docformat}
+---
+title: "Open Badges Document Formats"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Document formats for Open Badges 3.0 credentials"
+---
+
+## Open Badges Document Formats {#docformat}
[OpenBadgeCredentials](#org.1edtech.ob.v3p0.achievementcredential.class) can be exchanged as documents as defined in this section, or by using the [Open Badges API](#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:
@@ -8,7 +17,7 @@
## Example: Sample OpenBadgeCredential file contents
-```obv3p0 org.1edtech.ob.v3p0.achievementcredential.class preventAdditionalProperties=true"
+```obv3p0 org.1edtech.ob.v3p0.achievementcredential.class preventAdditionalProperties=true
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
diff --git a/ob_v3p0/microsites/spec/equality-and-comparison.md b/ob_v3p0/microsites/v3p0/spec/equality-and-comparison.md
similarity index 95%
rename from ob_v3p0/microsites/spec/equality-and-comparison.md
rename to ob_v3p0/microsites/v3p0/spec/equality-and-comparison.md
index e2bb4a50..05060fd2 100644
--- a/ob_v3p0/microsites/spec/equality-and-comparison.md
+++ b/ob_v3p0/microsites/v3p0/spec/equality-and-comparison.md
@@ -1,4 +1,13 @@
-# Credential equality and comparison algorithm{#credential-equality-and-comparison}
+---
+title: "Credential equality and comparison algorithm"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Credential equality and comparison for Open Badges 3.0"
+---
+
+## Credential equality and comparison algorithm{#credential-equality-and-comparison}
Credential equality and comparison is the process to determine whether a [=verifiable credential=] is semantically equivalent to another one.
diff --git a/ob_v3p0/microsites/spec/extending.md b/ob_v3p0/microsites/v3p0/spec/extending.md
similarity index 97%
rename from ob_v3p0/microsites/spec/extending.md
rename to ob_v3p0/microsites/v3p0/spec/extending.md
index 3b6fbb81..f4640957 100644
--- a/ob_v3p0/microsites/spec/extending.md
+++ b/ob_v3p0/microsites/v3p0/spec/extending.md
@@ -1,3 +1,12 @@
+---
+title: "Extending and Profiling the Standard"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Extending and profiling the Open Badges 3.0 standard"
+---
+
## Extending and Profiling the Standard {#extending}
This standard can be extended in three ways:
diff --git a/ob_v3p0/microsites/spec/gettingstarted.md b/ob_v3p0/microsites/v3p0/spec/gettingstarted.md
similarity index 55%
rename from ob_v3p0/microsites/spec/gettingstarted.md
rename to ob_v3p0/microsites/v3p0/spec/gettingstarted.md
index 8edd5750..fc1a9949 100644
--- a/ob_v3p0/microsites/spec/gettingstarted.md
+++ b/ob_v3p0/microsites/v3p0/spec/gettingstarted.md
@@ -1,4 +1,13 @@
-# Getting Started
+---
+title: "Getting Started"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Getting started with the Open Badges 3.0 specification"
+---
+
+## Getting Started
## Implementation Guide
diff --git a/ob_v3p0/microsites/spec/integrity.md b/ob_v3p0/microsites/v3p0/spec/integrity.md
similarity index 98%
rename from ob_v3p0/microsites/spec/integrity.md
rename to ob_v3p0/microsites/v3p0/spec/integrity.md
index fa0c0a03..cd21cc00 100644
--- a/ob_v3p0/microsites/spec/integrity.md
+++ b/ob_v3p0/microsites/v3p0/spec/integrity.md
@@ -1,4 +1,13 @@
-# Proofs (Signatures) {#data-integrity}
+---
+title: "Proofs (Signatures)"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Data integrity proofs and signatures for Open Badges 3.0"
+---
+
+## Proofs (Signatures) {#data-integrity}
This section describes mechanisms for ensuring the authenticity and integrity of OpenBadgeCredentials. At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a [=credential=] to be a [=verifiable credential=]; that is, to be [=verifiable=]. In order to pass 1EdTech conformance tests, issuers MUST use a proof mechanism supported by the 1EdTech conformance test suite. See more about [Selecting proof methods and crypto algorithms](impl#selecting-proof-methods-and-crypto-algorithms) in the Implementation Guide.
diff --git a/ob_v3p0/microsites/spec/introduction.md b/ob_v3p0/microsites/v3p0/spec/introduction.md
similarity index 98%
rename from ob_v3p0/microsites/spec/introduction.md
rename to ob_v3p0/microsites/v3p0/spec/introduction.md
index dc26ea9f..a45b7f95 100644
--- a/ob_v3p0/microsites/spec/introduction.md
+++ b/ob_v3p0/microsites/v3p0/spec/introduction.md
@@ -1,4 +1,13 @@
-# Introduction
+---
+title: "Introduction"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Introduction for the Open Badges 3.0 specification"
+---
+
+## Introduction
## Audiences
@@ -195,7 +204,7 @@ In the diagram below, the concepts are shown in gray boxes (e.g. Assertion). Ple
Starting with this version of the Open Badges Specification, an Assertion is also a Verifiable Credential (VC) as defined by the [[vc-data-model-2.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 shows the major conceptual components of an Open Badge Verifiable Credential*
diff --git a/ob_v3p0/microsites/spec/overview.md b/ob_v3p0/microsites/v3p0/spec/overview.md
similarity index 98%
rename from ob_v3p0/microsites/spec/overview.md
rename to ob_v3p0/microsites/v3p0/spec/overview.md
index 5e608938..ea8ef830 100644
--- a/ob_v3p0/microsites/spec/overview.md
+++ b/ob_v3p0/microsites/v3p0/spec/overview.md
@@ -1,4 +1,13 @@
-# Overview{.informative}
+---
+title: "Overview"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Overview of the Open Badges 3.0 specification"
+---
+
+## Overview{.informative}
## What is the problem this solves for?
@@ -13,11 +22,11 @@ This specification changes the structure of the Open Badges [Assertion](#achieve
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.
-
+
## Benefits and Opportunities
diff --git a/ob_v3p0/microsites/spec/serialization.md b/ob_v3p0/microsites/v3p0/spec/serialization.md
similarity index 96%
rename from ob_v3p0/microsites/spec/serialization.md
rename to ob_v3p0/microsites/v3p0/spec/serialization.md
index 95fae19c..8ba3b3fc 100644
--- a/ob_v3p0/microsites/spec/serialization.md
+++ b/ob_v3p0/microsites/v3p0/spec/serialization.md
@@ -1,4 +1,13 @@
-# Serialization
+---
+title: "Serialization"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Serialization formats for Open Badges 3.0"
+---
+
+## Serialization
The data model as described in Appendix [[[#data-models]]] is the canonical structural representation of an Open Badges [=verifiable credential=] ([AchievementCredential](#org.1edtech.ob.v3p0.achievementcredential.class)). All serializations are representations of that data model in a specific format. This section specifies how the data model is realized in JSON-LD and plain JSON.
diff --git a/ob_v3p0/microsites/spec/usecases.md b/ob_v3p0/microsites/v3p0/spec/usecases.md
similarity index 98%
rename from ob_v3p0/microsites/spec/usecases.md
rename to ob_v3p0/microsites/v3p0/spec/usecases.md
index 11e711fd..1943378f 100644
--- a/ob_v3p0/microsites/spec/usecases.md
+++ b/ob_v3p0/microsites/v3p0/spec/usecases.md
@@ -1,4 +1,13 @@
-# Use Cases{.informative}
+---
+title: "Use Cases"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Use cases for the Open Badges 3.0 specification"
+---
+
+## Use Cases{.informative}
The use cases below drive the design of Open Badges 3.0 specification.
diff --git a/ob_v3p0/microsites/spec/verification.md b/ob_v3p0/microsites/v3p0/spec/verification.md
similarity index 97%
rename from ob_v3p0/microsites/spec/verification.md
rename to ob_v3p0/microsites/v3p0/spec/verification.md
index a6ec90b7..95451938 100644
--- a/ob_v3p0/microsites/spec/verification.md
+++ b/ob_v3p0/microsites/v3p0/spec/verification.md
@@ -1,4 +1,13 @@
-# Verification and Validation
+---
+title: "Verification and Validation"
+docType: "segment"
+status: "Final"
+author: "1Edtech Consortium"
+lastUpdated: 2023-08-10
+description: "Verification and validation for Open Badges 3.0 credentials"
+---
+
+## Verification and Validation
[=Verification=] is the process to determine 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. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.
diff --git a/ob_v3p0/ob_v3p0.html b/ob_v3p0/ob_v3p0.html
index f80a2e97..15b3a463 100644
--- a/ob_v3p0/ob_v3p0.html
+++ b/ob_v3p0/ob_v3p0.html
@@ -27,9 +27,9 @@
specNature: "normative", // spec nature is "normative" or "informative"
specType: "main", // spec type is "main", "cert", "impl", "errata" or other agreed upon string
specVersion: "3.0",
- docVersion: "1.4.1",
+ docVersion: "1.4.3",
specStatus: "Final Release",
- specDate: "November 6, 2025",
+ specDate: "April 22, 2026",
contributors: _contributors,
localBiblio: _localBiblio,
iprs: _iprs,
@@ -250,6 +250,26 @@
Revision History
+
+
Final
+
1.4.2
+
April 17, 2026
+
+
+
Updated CredentialStatus of all examples to BitstringStatusListEntry
-
- 
- 
- 
- 
- 
- 
- 
- 
-