Open Badges Specification Conformance and Certification Guide

Abstract

Open Badges are visual symbols of accomplishments packed with verifiable metadata according to the Open Badges specification. The Open Badges 3.0 specification Open Badges Specification v3.0 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.

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

Introduction

Conformance Statements

Documents

The full set of documents is comprised of the following documents:

• Open Badges Specification v3.0
• Open Badges Specification Conformance and Certification Guide v3.0
• OpenAPI 3.0 JSON File for Open Badges API
• OpenAPI 3.0 YAML File for Open Badges API
• Open Badges 3.0 JSON-LD Context File

Terms

The following terms are used throughout this document.

Achievement

This is the content description of a credential that an assertion references. It contains metadata such as the name of the achievement, description, alignment of skills, etc. An Assertion asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.

Assertion

The core of both Open Badges and CLR is the assertion about achievement(s). Assertion properties are specific to one learner's achievement and specify metadata such as issuer, date of achievement, expiration data, as well as results and evidence that support the assertion. A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.

Candidate platform

A platform implementing the Open Badges specification with the intent to obtain certification from 1EdTech. They may be in the process to obtain certification.

Comprehensive Learner Record (CLR)

Set of assertions that can be packaged as a verifiable credential.

Defined Achievement Claim

An assertion that the learner achieved a specific achievement.

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.

Service Consumer

In a REST API, the Service Consumer is the actor that initiates the DELETE, GET, or POST request. Also called a Consumer in the IMS Global Security Framework v1.1.

Service Provider

In a REST API, the Service Provider is the actor that responds to a DELETE, GET, or POST request. Also called a Platform in the IMS Global Security Framework v1.1.

Skill

Measurable or observable knowledge, skill, or ability necessary to successful performance of a person.

Skill Claim

An assertion that the learner has the specified skill.

Verifiable Credential

A tamper-evident credential whose issuer can be cryptographically verified. See Verifiable Credentials Data Model v2.0.

Verifiable Presentation

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. Verifiable Credentials Data Model v2.0

Verification

The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.

Verifier

The entity that receives a verifiable credential or verifiable presentation and verifies the credential or presentation has not been tampered with.

Conformance and Certification

The goal of 1EdTech certification for Open Badges Open Badges Specification v3.0 is to ensure interoperable implementations of badging systems that generate and issue digital badges as well as those that host and display badges.

1EdTech certification for Open Badges demands features and capabilities beyond those that are strictly required by the specification. These additional features are defined in this document. The specification is intentionally left very flexible to allow it to be used for many purposes. Gaining this certification is expected to be more difficult than simply meeting the minimum requirements for producing a valid Open Badge.

Certification may be achieved in one or more of the following services:

• Open Badges Issuer
• Open Badges Displayer
• Open Badges Host

The service types and associated certification tests are defined below.

API categorization

This specification defines a RESTful API protocol to be implemented by applications serving in the roles of Service Consumer and Service Provider. The API uses OAuth 2.0 for authentication and granular resource-based permission scopes.

All the endpoints defined in the Open Badges 3.0 API are grouped in four services for certification purposes. This grouping is based on the role of the candidate platform in the API architecture and the purpose of the operation. Thus, the resulting grouping is as follows:

Consumer (Initiates Requests)	Provider (Responds to Requests)
Service Consumer (Read)	Service Provider (Read)
Service Consumer (Write)	Service Provider (Write)

These services contain a set of required endpoints a candidate platform must support for its further certification. Some services may contain a set of optional endpoints that, if supported by the candidate platform, it must support as well.

The Conformance Process

The process for conformance testing role implementations of Open Badges includes the following:

• First, launch the 1EdTech Conformance Test Suite for Open Badges 3.0 and follow the onscreen instructions to run the tests.
• Once the tests have been successfully run, submit your test results. A copy of your test results will be sent to your email address.

To pass certification, you must take the following steps:

• You must be an 1EdTech Digital Credentials and Badges Alliance Member, an 1EdTech Affiliate Member, or 1EdTech Contributing Member.
• You must pass all the tests associated with the features you are applying for using the certification suite hosted on the 1EdTech website.
• The tests must be completed by a designated representative of the 1EdTech member organization, and you must agree that there is no misrepresentation or manipulation of results in the submitted information.

After 1EdTech reviews your submitted information and notifies you that your application is approved, you can claim certification to Open Badges 3.0 and display the 1EdTech certified logo on your website and in your software. The 1EdTech Global Certified Products Directory will list your conformance details.

Open Badges 3.0 Issuer Service 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.

Note: A badge is deemed valid if it successfully passes JSON-LD validation in safe mode and meets the verification requirements specified in Open Badges Specification v3.0.

JSON-LD safe mode is defined as a processing mode in which an error is raised whenever a term in the document is not defined by any of its associated contexts.

Note: Open Badges Issuers that only create OpenBadgeCredentials and not meet Service Consumer (Write) requirements are also known for conform to the Issuer Only service conformance.

Tests

1. Create a valid 3.0 badge and issue it to the recipient conformance@imsglobal.org and submit the issued badge to the conformance test system.

2. Demonstrate through video the candidate platform's methodology for a recipient to retrieve their badge.

3. (Optional) Complete tests of, at least, required endpoints of Service Consumer (Write) Conformance.

Supported Proof Mechanisms

Open Badges Issuers opting for a Linked Data Proof format as the signature of the badge must use one of the following supported proof mechanisms:

• Data Integrity EdDSA Cryptosuites v1.0 suite with the eddsa-rdfc-2022 algorithm.
• Data Integrity ECDSA Cryptosuites v1.0 suite with the ecdsa-sd-2023 algorithm. The resulting credential MUST contain all required fields for the credential.

Service Consumer (Write) Conformance

A product that conforms to Service Consumer (Write) requirements can send an OpenBadgeCredential or a Profile to a product that conforms to Service Provider (Write) requirements.

Note: In the scope of the conformance test system, the test system acts as the Service Provider, so a Candidate Platform MUST send credentials and profiles from the given conformance test system.

Required Service Consumer (Write) Endpoint Support

The service endpoints that MUST be supported for Service Consumer (Write) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
getServiceDescription	/ims/ob/v3p0/discovery	GET	Initiate	No
OAuth 2.0 Registration	from Service Discovery Document (SDD)	GET	Initiate	No
OAuth 2.0 Authorize	from SDD	GET	Initiate	No
OAuth 2.0 Token	from SDD	POST	Initiate	No
upsertCredential	/ims/ob/v3p0/credentials	POST	Initiate	Yes

Optional Service Consumer (Write) Endpoint Support

The service endpoints that MAY be supported for Service Consumer (Write) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
putProfile	/ims/ob/v3p0/profile	PUT	Initiate	Yes

Tests

1. Obtain an access token from the conformance test system using provided getServiceDescription endpoint and the following OAuth 2.0 authentication flow with the provided login credentials. Ensure that the right scopes are sent.
2. Create a valid AchivementCredential and issue it to the recipient conformance@imsglobal.org. Call the conformance test endpoint upsertCredentials, with the AchivementCredential. Submit the result of the call to the conformance test system.
3. (Optional) Create a new Profile for the id "https://1edtech.org/issuers/cert" and call the conformance test endpoint putProfile with the Profile. Submit the result of the call to the conformance test system.

Open Badges 3.0 Displayer Service 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.

Verification and status

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 Open Badges Specification v3.0. As a quick summary:

• 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

1. The conformance test system will display the URL of three badges. One of them is neither expired nor revoked, other is expired but not revoked and the last one is not expired but revoked. The candidate platform must verify these badges and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of badges to see the following data in all provided badges:

   • image (if the badge provided is a baked badge)
   • name
   • description
   • issuer name
   • issuedOn Date
   • status (expired and/or revoked)

2. Demonstrate through video that the platform allows viewers of badges to do the following:

   • Trigger verification of the badge and retrieve results verifying that the badge credential is not expired, and not revoked

3. The conformance test system will display the URL of three badges created using Verifiable Credentials Data Model v1.1 with the same characteristics as in Test 1. The candidate platform must verify these badges and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of badges to see the following data in all provided badges:

   • image (if the badge provided is a baked badge)
   • name
   • description
   • issuer name
   • issuedOn Date
   • status (expired and/or revoked)

4. Demonstrate through video that the platform allows viewers of badges to do the following:

   • Trigger verification of the badge and retrieve results verifying that the badge credential is not expired, and not revoked

Supported Proof Mechanisms

Open Badges Verifiers must support the following supported proof mechanisms for Linked Data Proof format:

• Data Integrity EdDSA Cryptosuites v1.0 suite with the eddsa-rdfc-2022 algorithm.
• Data Integrity ECDSA Cryptosuites v1.0 suite with the ecdsa-sd-2023 algorithm.

Open Badges 3.0 Host Service 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) Conformance requirements and accept an AchievementCredential or a Profile from an Issuer application. And meet Service Consumer (Read) Conformance and Service Provider (Read) Conformance requirements for exchanging AchievementCredentials with other Host applications.

Tests

1. Complete tests of Service Consumer (Read) Conformance.
2. Complete tests of Service Provider (Read) Conformance.
3. Complete tests of, at least, required endpoints of Service Provider (Write) Conformance.

Service Consumer (Read) Conformance

A product that conforms to Service Consumer (Read) requirements can request credentials and profiles from a product that conforms to Service Provider (Read) requirements.

Note: In the scope of the conformance test system, the test system acts as the Service Provider, so a Candidate Platform MUST request credentials and profiles from the given conformance test system.

Required Service Consumer (Read) Endpoint Support

The service endpoints that MUST be supported for Service Consumer (Read) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
getServiceDescription	/ims/ob/v3p0/discovery	GET	Initiate	No
OAuth 2.0 Registration	from Service Discovery Document (SDD)	GET	Initiate	No
OAuth 2.0 Authorize	from SDD	GET	Initiate	No
OAuth 2.0 Token	from SDD	POST	Initiate	No
getCredentials	/ims/ob/v3p0/credentials	GET	Initiate	Yes
getProfile	/ims/ob/v3p0/profile	GET	Initiate	Yes

Tests

1. Obtain an access token from the conformance test system using provided getServiceDescription endpoint and the following OAuth 2.0 authentication flow with the provided login credentials. Ensure that the right scopes are sent.
2. Call the conformance test endpoint getCredentials. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned credentials.
3. (Optional) Call the conformance test endpoint getCredentials with query and pagination parameters. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned credentials.
4. Call the conformance test endpoint getProfile. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned profile.

Service Provider (Read) Conformance

A product that conforms to Service Provider (Read) requirements can provide badges to a product that conforms to Service Consumer (Read) requirements.

Note: In the scope of the conformance test system, the test system acts as the Service Consumer, so a Candidate Platform MUST receive credentials and profiles requests from the given conformance test system.

Required Service Provider (Read) Endpoint Support

The service endpoints that MUST be supported for Service Provider (Read) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
getServiceDescription	/ims/ob/v3p0/discovery	GET	Respond	No
OAuth 2.0 Registration	from Service Discovery Document (SDD)	GET	Respond	No
OAuth 2.0 Authorize	from SDD	GET	Respond	No
OAuth 2.0 Token	from SDD	POST	Respond	No
getCredentials	/ims/ob/v3p0/credentials	GET	Respond	Yes
getProfile	/ims/ob/v3p0/profile	GET	Respond	Yes

Service Provider (Read) Compliance

The functional capabilities of such systems are:

• They MUST support the required service endpoints
• They MUST require an access token with the appropriate scope for endpoints that require authorization
• They MUST return a valid entity in each endpoint. In getCredentials, each of the elements in the returned list MUST be verifiable.
• They MUST support the endpoint payload pagination query parameters, and the corresponding response HTTP pagination headers MUST be supported
• They MAY support Token Refresh as defined in The OAuth 2.0 Authorization Framework. If so, a call to refresh token MUST return a new access token.
• They MAY support Token Revocation as defined in Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). If so, a revocation MUST cause all of subsequent calls to return an error

Tests

1. Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
2. Return valid AchivementCredentials when the API operation getCredentials is called.
3. Return valid AchivementCredentials when the API operation getCredentials is called with query and pagination parameters.
4. Return a Profile for the authorized user (with id "https://1edtech.org/issuers/cert") when the API operation getProfile is called.
5. (Optional) Revoke the Token. Subsequents calls from the conformance test system must return an error.

If refresh token is supported, the conformance test system will perform a call for refreshing the token and repeat tests 2, 3 & 4 with the refreshed access token.

Service Provider (Write) Conformance

A product that conforms to Service Provider (Write) requirements can accept an OpenBadgeCredential or a Profile from a product that conforms to Service Consumer (Write) requirements.

Note: In the scope of the conformance test system, the test systems acts as the Service Consumer, so a Candidate Platform MUST receive credentials and profiles calls from the given conformance test system.

Required Service Provider (Write) Endpoint Support

The service endpoints that MUST be supported for Service Provider (Write) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
getServiceDescription	/ims/ob/v3p0/discovery	GET	Respond	No
OAuth 2.0 Registration	from Service Discovery Document (SDD)	GET	Respond	No
OAuth 2.0 Authorize	from SDD	GET	Respond	No
OAuth 2.0 Token	from SDD	POST	Respond	No
upsertCredential	/ims/ob/v3p0/credentials	POST	Respond	Yes

Optional Service Provider (Write) Endpoint Support

The service endpoints that MAY be supported for Service Provider (Write) are listed in the table below:

Service Call	Endpoint	HTTP Verb	Mode	Authorization Required
putProfile	/ims/ob/v3p0/profile	PUT	Respond	Yes

Service Provider (Write) Compliance

The functional capabilities of such systems are:

• They MUST support the required endpoints.
• They MAY support the optional endpoints.
• They MUST require an access token with the appropriate scope for the endpoints that require authorization.
• They MUST preserve sent data. A subsequent call to getCredentials after a upsertCredential with a given credential must return that same credential as result of the Credential equality and comparison algorithm defined in Open Badges Specification v3.0.
• They MAY support Token Refresh as defined in The OAuth 2.0 Authorization Framework. If so, a call to refresh token MUST return a new access token.
• They MAY support Token Revocation as defined in Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). If so, a revocation MUST cause all of subsequent calls to return an error.

Tests

1. Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
2. Return valid AchivementCredentials when the API operation upsertCredential is called.
3. (Optional) Return the Profile for the authorized user when the API operation updateProfile is called.
4. (Optional) Revoke the Token. Subsequents calls from the conformance test system must return an error.

If refresh token is supported, the conformance test system will perform a call for refreshing the token and repeat tests 2 & 3 with the refreshed access token.