Open Badges 3.0 Certification Guide

Open Badges Specification Conformance and Certification Guide

Final Release
Spec Version 3.0
Final Release
Document Version: 1.0
Date Issued: May 27, 2024
Status: This document is made available for adoption by the public community at large.
This version: https://www.imsglobal.org/spec/ob/v3p0/cert/
Latest version: https://www.imsglobal.org/spec/ob/latest/cert/
Errata: https://www.imsglobal.org/spec/ob/v3p0/errata/

IPR and Distribution Notice

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

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: 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)
Arizona State University June 21, 2022 No RF RAND (Required & Optional Elements)
Temple University June 10, 2022 No RF RAND (Required & Optional Elements)
Credly October 3, 2019 No RF RAND (Required & Optional Elements)
Workday, Inc. June 10, 2022 No RF RAND (Required & Optional Elements)
RANDA Solutions June 9, 2022 No RF RAND (Required & Optional Elements)
Anthology April 16, 2024 No RF RAND (Required & Optional Elements)
Unicon April 22, 2024 No RF RAND (Required & Optional Elements)
Bowdoin College June 11, 2022 No RF RAND (Required & Optional Elements)
American Association of Collegiate Registrars and Admissions Officers (AACARO) April 15, 2024 No RF RAND (Required & Optional Elements)
Desire to Learn (D2L) April 16, 2024 No RF RAND (Required & Optional Elements)
Digital Knowledge EdTech Lab Inc. April 24, 2024 No RF RAND (Required & Optional Elements)
IQC Italian Quality Company April 19, 2024 No RF RAND (Required & Optional Elements)
Skybridge Skills April 16, 2024 No RF RAND (Required & Optional Elements)
Navigatr April 25, 2024 No RF RAND (Required & Optional Elements)
T3 Innovation Network, US Chamber of Commerce Foundation April 25, 2024 No RF RAND (Required & Optional Elements)
Territorium April 23, 2024 No RF RAND (Required & Optional Elements)
Western Governors University (WGU) June 11, 2022 No RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.

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

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

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

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources .

© 2024 1EdTech™ Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

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.

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.

1. Introduction

1.1 Conformance Statements

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, 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.

1.2 Documents

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

1.3 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 (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [vc-data-model-2.0].

  • Verifiable Presentation (VP): A tamper-evident presentation of one or more Verifiable Credentials of which cryptographic verification can be used to determine the trustworthiness of the authorship of the data. [vc-data-model-2.0]

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

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

2. Conformance and Certification

This section is non-normative.

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.

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.

2.1 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.

2.2 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.

3. Open Badges 3.0 Issuer Service Conformance

This section is non-normative.

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 baked 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
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.

3.1 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 § 3.2 Service Consumer (Write) Conformance.

3.2 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.

3.2.1 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

3.2.2 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

3.2.3 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.

4. Open Badges 3.0 Displayer Service Conformance

This section is non-normative.

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.

4.1 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 [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 expired if the current date and time is after the validUntil.

4.2 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 ([VC-DATA-MODEL]) 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

5. Open Badges 3.0 Host Service Conformance

This section is non-normative.

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

5.1 Tests

  1. Import each of the provided artifacts (see table below), verify the badge, and submit the status to the conformance test system.

    Required OpenBadgeCredential Format Use this resource for certification
    Baked OpenBadgeCredential (PNG) format https://someurl/OB30-conformance.png
    Baked OpenBadgeCredential (SVG) format https://someurl/OB30-conformance.svg
    OpenBadgeCredential JSON Resource URL https://someurl/OB30-conformance.jws
  2. Export the imported badge in the previous test and submit the exported badge to the conformance test system. The conformance test system will ensure that the exported badge is a valid badge and that no information is lost in the import/export operation.

  3. Complete tests of § 5.2 Service Consumer (Read) Conformance.

  4. Complete tests of § 5.3 Service Provider (Read) Conformance.

  5. Complete tests of, at least, required endpoints of § 5.4 Service Provider (Write) Conformance.

5.2 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.

5.2.1 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

5.2.2 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.

5.3 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.

5.3.1 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

5.3.2 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 [RFC6749]. If so, a call to refresh token MUST return a new access token.
  • They MAY support Token Revocation as defined in [RFC7709]. If so, a revocation MUST cause all of subsequent calls to return an error

5.3.3 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.

5.4 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.

5.4.1 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

5.4.2 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

5.4.3 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 [OB-30].
  • They MAY support Token Refresh as defined in [RFC6749]. If so, a call to refresh token MUST return a new access token.
  • They MAY support Token Revocation as defined in [RFC7709]. If so, a revocation MUST cause all of subsequent calls to return an error.

5.4.4 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.

A. Revision History

This section is non-normative.

Version No. Document Version Release Date Comments
Candidate Public Final 1.0 November 10, 2022 Open Badges 3.0 first Candidate Public Final release
Final 1.0 May 27, 2024 Open Badges 3.0 Final Release

B. References

B.1 Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119

B.2 Informative references

[OB-30]
Open Badges Specification v3.0. 1EdTech. Candidate Final Public. URL: https://www.imsglobal.org/spec/ob/v3p0/
[OB-CERT-30]
Open Badges Specification Conformance and Certification Guide v3.0. 1EdTech. Candidate Final Public. URL: https://www.imsglobal.org/spec/ob/v3p0/cert/
[RFC6749]
The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6749
[RFC7709]
Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). A. Malis, Ed.; B. Wilson; G. Clapp; V. Shukla. IETF. November 2015. Informational. URL: https://www.rfc-editor.org/rfc/rfc7709
[SEC-11]
IMS Global Security Framework v1.1. C. Smythe; C. Vervoort; M. McKell. IMS Global Learning Consortium. July 19th, 2021. IMS Final Release. URL: https://www.imsglobal.org/spec/security/v1p1/
[VC-DATA-MODEL]
Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/
[vc-data-model-2.0]
Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 13 May 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/

C. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Nate OttoConcentric Sky, Skybridge SkillsInvited Expert
Kerri LemoieDigital Credentials Consortium (MIT)Editor
Phillip LongT3 Innovation NetworkInvited Expert
Marty ReedRANDA SolutionsCo-chair, CLR
Justin PitcherAnthologyCo-chair, OB
Brent CapriottiWestern Governors University (WGU)Co-chair, CLR
Sherri BraxtonBowdoin CollegeCo-chair, OB
Jock WrightVerifyEd
Jen SchreiberWorkday
Viktor HaagD2L
Alex HripakCredly
David WardPCG
Laura JanusekD2L
John KuoArizona State University
Sara ArjonaMoodle HQ
Mark McConahayAACRAO
Dmitri ZagidulinDCCInvited Expert
Tracy KorsmoNorth Dakota IT (NDIT)
Kate GiovacchiniArizona State University
Andy Miller1EdtechEditor
Markus Gylling1EdtechEditor
Dan Blickensderfer1EdtechEditor
Xavi Aracil1EdtechEditor

1EdTech™ Consortium, Inc. ("1EdTech") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at www.1edtech.org.

Please refer to Document Name: Open Badges Specification Conformance and Certification Guide 3.0

Date: May 27, 2024