CLR 2.0 Certification Guide | IMS Global Learning Consortium

CLR 2.0 Certification Guide | IMS Global Learning Consortium
You are here
Specifications
CLR 2.0 Certification Guide
Abstract
The Comprehensive Learner Record (CLR) Standard has been designed to create, transmit, and render an individual's set of achievements, as issued by multiple learning providers, in a machine-readable format that can be curated into verifiable digital records of achievement.
This version of the specification aligns CLR 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
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 $[object Object].
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:
Comprehensive Learner Record Standard v2.0
Comprehensive Learner Record Standard Conformance and Certification Guide v2.0
OpenAPI 3.0 JSON File for Comprehensive Learner Record API
OpenAPI 3.0 YAML File for Comprehensive Learner Record API
Comprehensive Learner Record 2.0 JSON-LD Context File
1.3
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.
Editor's note
@@ TBD @@
The goal of certification for Comprehensive Learner Record (CLR) [
CLR-20
] is to ensure interoperable implementations of credentialing systems that generate and issue ClrCredentials as well as those that host and display ClrCredentials.
Certification for Comprehensive Learner Record 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 CLR Credential.
Certification may be achieved in one or more of the following services:
CLR Issuer
CLR Displayer
CLR 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
Comprehensive Learner Record 2.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 CLR includes the following:
First, launch the
1EdTech Conformance Test Suite
for Comprehensive Learner Record 2.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 Comprehensive Learner Record 2.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.
CLR 2.0 Issuer Service Conformance
This section is non-normative.
A CLR
Issuer
is an application that allows for the creation of ClrCredentials and the subsequent delivery of ClrCredentials to recipients that conform to the CLR Specification. The candidate platform must issue a valid baked ClrCredential and demonstrate how the ClrCredential is retrieved by the recipient. The candidate platform may also meet Service Consumer (Write) requirements and can send an ClrCredential or a Profile to a product that conforms to Service Provider (Write) requirements.
Note
A ClrCredential is deemed valid if it successfully passes JSON-LD validation in safe
mode and meets the verification requirements specified in
Comprehensive Learner Record Standard v2.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
CLR Issuers that only create ClrCredentials and not meet Service Consumer (Write) requirements are also known for conform to the
Issuer Only
service conformance.
3.1
Tests
Create a valid baked ClrCredential and issue it to the recipient
conformance@imsglobal.org
and submit the issued badge to the conformance test system.
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 ClrCredential 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/clr/v2p0/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/clr/v2p0/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/clr/v2p0/profile
PUT
Initiate
Yes
3.2.3
Tests
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.
Create a valid ClrCredential and issue it to the recipient
conformance@imsglobal.org
. Call the conformance test endpoint
upsertCredentials
, with the ClrCredential. Submit the result of the call to the conformance test system.
(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.
CLR 2.0 Displayer Service Conformance
This section is non-normative.
An CLR Displayer is an application that displays and verifies ClrCredentials for viewers. The candidate platform must support viewer-initiated verification of a ClrCredential.
4.1
Verification and status
The tests within this section refer to possible values of the status of a record. The meaning of these values and how to determine them from a credential is defined in sections 9.1 and 9.2 of [
CLR-20
]. 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
The conformance test system will display the URL of three ClrCredentials. 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 credentials and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of credentials to see the following data in all provided credentials:
image (if the credential provided is a baked credential)
name
description
issuer name
issuedOn Date
status (expired and/or revoked)
Demonstrate through video that the platform allows viewers of credentials to do the following:
Trigger verification of the credential and retrieve results verifying that the ClrCredential is not expired, and not revoked
The conformance test system will display the URL of three ClrCredentials created using
Verifiable Credentials Data Model v2.0
([
VC-DATA-MODEL
]) with
the same characteristics as in Test 1. The candidate platform must verify these credentials and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of credentials to see the following data in all provided credentials:
image (if the badge provided is a baked badge)
name
description
issuer name
issuedOn Date
status (expired and/or revoked)
Demonstrate through video that the platform allows viewers of credentials to do the following:
Trigger verification of the credential and retrieve results verifying that the ClrCredential is not expired, and not revoked
5.
CLR 2.0 Host Service Conformance
This section is non-normative.
An CLR
Host
is an application that can aggregate and publicly host ClrCredentials for recipients. It also supports export of ClrCredentials at user request. The candidate platform must be able to import all formats of ClrCredentials as well as prove that ClrCredential metadata is not lost upon export. The candidate platform must also meet
5.4
Service Provider (Write) Conformance
requirements and accept a ClrCredential 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 ClrCredentials with other Host applications.
5.1
Tests
Import each of the provided artifacts (see table below), verify the badge, and submit the status to the conformance test system.
Required ClrCredential Format
Use this resource for certification
Baked ClrCredential (PNG) format
Baked ClrCredential (SVG) format
ClrCredential JSON Resource URL
Export the imported ClrCredential in the previous test and submit the exported ClrCredential to the conformance test system. The conformance test system will ensure that the exported ClrCredential is a valid ClrCredential and that no information is lost in the import/export operation.
Complete tests of
5.2
Service Consumer (Read) Conformance
Complete tests of
5.3
Service Provider (Read) Conformance
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/clr/v2p0/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/clr/v2p0/credentials
GET
Initiate
Yes
getProfile
/ims/clr/v2p0/profile
GET
Initiate
Yes
5.2.2
Tests
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.
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.
(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.
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 ClrCredentials 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/clr/v2p0/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/clr/v2p0/credentials
GET
Respond
Yes
getProfile
/ims/clr/v2p0/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
Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
Return valid ClrCredentials when the API operation
getCredentials
is called.
Return valid ClrCredentials when the API operation
getCredentials
is called with query and pagination parameters.
Return a Profile for the authorized user (with id
"https://1edtech.org/issuers/cert"
) when the API operation
getProfile
is called.
(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 a ClrCredential 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/clr/v2p0/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/clr/v2p0/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/clr/v2p0/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
upsertCredentials
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
Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
Return valid AchivementCredentials when the API operation
upsertCredentials
is called.
(Optional) Return the Profile for the authorized user when the API operation
updateProfile
is called.
(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 Final
February 7, 2023
Comprehensive Learner Record 2.0 first Candidate Final release
Final
1.0
February 26, 2025
Comprehensive Learner Record 2.0 Final Release
Final
1.1
December 15th, 2025
Added JSON-LD Safe mode requirement for issuer certification
profile.
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:
B.2
Informative references
[CLR-20]
Comprehensive Learner Record Standard v2.0
. 1EdTech Consortium. February 26, 2025. 1EdTech Final Release. URL:
[CLR-CERT-20]
Comprehensive Learner Record Standard Conformance and Certification Guide v2.0
. 1EdTech Consortium. February 26, 2025. 1EdTech Final Release. URL:
[OB-30]
Open Badges Specification v3.0
. 1EdTech. 1EdTech Final Release. URL:
[RFC6749]
The OAuth 2.0 Authorization Framework
. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL:
[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:
[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:
[VC-DATA-MODEL-2.0]
Verifiable Credentials Data Model v2.0
. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 15 May 2025. W3C Recommendation. URL:
C.
List of Contributors
The following individuals contributed to the development of this document:
Name
Organization
Role
Nate Otto
Concentric Sky, self
Invited Expert
Kerri Lemoie
Concentric Sky, RANDA
Editor
Phillip Long
Concentric Sky
Invited Expert
Marty Reed
RANDA Solutions
Co-chair, CLR
Justin Pitcher
Anthology
Co-chair, OB
Brent Cappriotti
RANDA Solutions
Co-chair, CLR
Sherri Braxton
Bowdoin College
Co-chair, OB
Jock Wright
VerifyEd
Jen Schreiber
Workday
Viktor Haag
D2L
Alex Hripak
Credly
David Ward
PCG
Laura Janusek
D2L
John Kuo
Arizona State University
Sara Arjona
Moodle HQ
Mark McConahay
AACRAO
Invited Expert
Dmitri Zagidulin
DCC
Invited Expert
Tracy Korsmo
North Dakota IT (NDIT)
Kate Giovacchini
Arizona State University
Andy Miller
1Edtech
Editor
Markus Gylling
1Edtech
Editor
Dan Blickensderfer
1Edtech
Editor
Xavi Aracil
1Edtech
Editor
Permalink
Referenced in:
§ 1.3 Terms
Permalink
Referenced in:
§ 1.3 Terms
(2)
(3)
Permalink
Referenced in:
§ 2.1 API categorization
(2)
(3)
§ 3.2 Service Consumer (Write) Conformance
§ 5.2 Service Consumer (Read) Conformance
§ 5.3 Service Provider (Read) Conformance
§ 5.4 Service Provider (Write) Conformance
Permalink
Referenced in:
§ 1.3 Terms
Permalink
Referenced in:
§ Abstract
Permalink
Referenced in:
§ 1.3 Terms
(2)
§ 2.1 API categorization
Permalink
Referenced in:
§ 2.1 API categorization
Permalink
Referenced in:
§ 2.1 API categorization
Permalink
Referenced in:
§ 1.3 Terms
Permalink
Referenced in:
§ Abstract
Permalink
Referenced in:
§ 1.3 Terms
(2)
(3)
Permalink
Referenced in:
§ Abstract
§ 1.3 Terms
(2)
Permalink
Referenced in:
Not referenced in this document.
Permalink
Referenced in:
Not referenced in this document.
Sharebar?