Comprehensive Learner Record Conformance and Certification Guide 1.0 IMS Candidate Final

Comprehensive Learner Record Conformance and Certification Guide

IMS Candidate Final Public
Version 1.0
IMS Candidate Final Public
Date Issued: August 5, 2020
Status: This document is for review and adoption by the IMS membership.
This version: https://www.imsglobal.org/spec/clr/v1p0/cert/
Latest version: https://www.imsglobal.org/spec/clr/latest/cert/
Errata: https://www.imsglobal.org/spec/clr/v1p0/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.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the 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 web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS 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 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.

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

© 2020 IMS Global Learning Consortium, Inc. All Rights Reserved.

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

Abstract

The IMS Comprehensive Learner Record (CLR) specification 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.

1. Introduction

1.1 Conformance and Certification

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 Specification Documents

This section is non-normative.

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

1.3 Key Terms and Definitions

This section is non-normative.

CLR
A document of structured data created by a Publisher containing one or more Assertions about one Learner.
Achievement
An accomplishment such as a degree, competency, course, or other accomplishment. An achievement may be asserted about one or more Learners (though a CLR contains records for only one Learner).
Alignment
A relationship between an Achievement and a node in an external educational framework such as a [CASE-10] framework.
Assertion
The attestation made by an Issuer about a Learner regarding an Achievement. The Assertion may also include associated evidence, results, or other metadata regarding a specific Achievement.
Association
A relationship (e.g. isChildOf, precedes, etc.) between multiple achievements.
Consumer
A REST API actor that makes requests to CLR endpoints on a Provider.
Endorsement
A verifiable assertion issued by a person or entity endorsing an Achievement, Assertion, or Profile.
Evidence
Information supporting the issuance of an assertion such as URL to an artifact produced by the Learner.
Inspector
A person or entity that inspects a CLR to verify or validate the data.
Issuer
The profile of an organization or entity that has made a particular Assertion about a Learner. The Issuer of an Assertion is the authoritative source for that specific Assertion.
Learner
The profile of the person who is the subject of the CLR and assertions contained in a CLR.
Mode
The 'Mode' is used denote whether the system is responsible for initiating the request (Initiate) or responding to the request (Respond)
Provider
A REST API actor that responds to requests to CLR endpoints from a Consumer.
Publisher
The profile of the organization providing the CLR (typically the educational institution, a 3rd-party agent, or the learner). The Publisher is the official record keeper for Assertions in a CLR. In the majority of cases, the Publisher is also the Issuer of some or all of the Assertions in a CLR. Except in the case of a self-curated CLR, the publisher is either the issuer or has a trusted relationship with the issuer of all the Assertions in the CLR. In the case of a self-curated collection of Assertions, the Learner is the Publisher of the CLR.
Verification
Instructive information for third parties to verify Assertions, Endorsements, and CLR packages.

2. CLR Conformance

The goal of IMS certification for CLR [CLR-10] is to ensure interoperable implementations of systems that generate and issue Comprehensive Learner Records as well as those that accept Comprehensive Learner Records and process them.

IMS certification for CLR 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.

Certification may be achieved for one or more of the following 6 features:

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

Many endpoints require authorization. Consumers and Providers are required to support the Authorization Code and/or Client Credentials token grant flow. Certification may be achieved for the following token grant flows:

Consumer
(Initiates Requests)
Provider
(Responds to Requests)
Authorization Code Grant Flow Authorization Code Grant Flow
Client Credentials Grant Flow) Client Credentials Grant Flow

The features and associated certification tests are defined below.

2.1 The Conformance Process

The process for conformance testing implementations of Comprehensive Learner Record (CLR) includes the following:

  • Go to the IMS Comprehensive Learner Record specification page on the IMS website and click on "Conformance Certification".
  • 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 IMS Digital Credentials and Badges Alliance Member, an IMS Affiliate Member, or IMS Contributing Member.
  • You must pass all the tests associated with the features you are applying for using the certification suite hosted on the IMS website.
  • The tests must be completed by a designated representative of the IMS member organization, and you must agree that there is no misrepresentation or manipulation of results in the submitted information.

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

3. Consumer Security Conformance

A product that conforms to any Consumer feature must also conform to either Consumer Authorization Code Grant Flow Support, Consumer Client Credentials Grant Flow Support, or both.

3.1 Required Consumer Authorization Code Grant Flow Support

The OAuth 2.0 endpoints that MUST be supported for the Authorization Code grant flow are listed in the table below:

OAuth 2.0 Call Endpoint HTTP Verb Mode
OAuth 2.0 Authorize as configured during setup GET Initiate
OAuth 2.0 Token as configured during setup POST Initiate

3.2 Required Consumer Client Credentials Grant Flow Support

The OAuth 2.0 endpoints that MUST be supported for the Client Credentials grant flow are listed in the table below:

OAuth 2.0 Call Endpoint HTTP Verb Mode
OAuth 2.0 Token as configured during eetup POST Initiate

3.3 Consumer Security Compliance

The functional capabilities of such systems are:

4. Provider Security Conformance

A product that conforms to any Provider feature must also conform to either Provider Authorization Code Grant Flow Support, Provider Client Credentials Grant Flow Support, or both.

4.1 Required Provider Authorization Code Grant Flow Support

The OAuth 2.0 endpoints that MUST be supported for the Authorization Code grant flow are listed in the table below:

OAuth 2.0 Call Endpoint HTTP Verb Mode
OAuth 2.0 Authorize as configured during setup GET Respond
OAuth 2.0 Token as configured during setup POST Respond

4.2 Required Provider Client Credentials Grant Flow Support

The OAuth 2.0 endpoints that MUST be supported for the Client Credentials grant flow are listed in the table below:

OAuth 2.0 Call Endpoint HTTP Verb Mode
OAuth 2.0 Token as configured during setup POST Respond

4.3 Provider Security Compliance

The functional capabilities of such systems are:

5. Service Consumer (Read) Conformance

A product that conforms to Service Consumer (Read) requirements can request Comprehensive Learner Records (CLRs) from a product that conforms to Service Provider (Read) requirements. One example of such a product is a wallet service which requests your CLRs from your college or employer.

5.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
getClrs /ims/clr/v1p0/clrs GET Initiate Yes

5.2 Service Consumer (Read) Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 3. Consumer Security Conformance
  • They MUST support the required service endpoints
  • They MUST supply an access token with the appropriate scope to service endpoints
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads
  • They MAY support the endpoint payload pagination query parameters. If supported, the corresponding response HTTP pagination headers MUST be supported

6. Service Consumer (Write) Conformance

A product that conforms to Service Consumer (Write) requirements can a) send Comprehensive Learner Records (CLRs) to a product that conforms to Service Provider (Write) requirements, and b) delete a Comprehensive Learner Record held by a product that conforms to Service Provider (Write) requirements. One example of such a product is a college or employer learning system that sends your CLRs to a wallet service.

6.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
postClr /ims/clr/v1p0/clrs POST Initiate Yes

6.2 Optional 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
deleteClr /ims/clr/v1p0/clrs/{sourcedId} DELETE Initiate Yes

6.3 Service Consumer (Write) Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 3. Consumer Security Conformance
  • They MUST support the required endpoints
  • They MAY support the optional endpoints
  • They MUST supply an access token with the appropriate scope to service endpoints
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads

7. Verification Consumer Conformance

A product that conforms to Verification Consumer requirements can initiate the verification requests necessary to verify hosted and signed Assertions, CLRs, and Endorsements.

7.1 Required Verification Consumer Endpoint Support

The verification endpoints that MUST be supported for Verification Consumer are listed in the table below:

Verification Call Endpoint HTTP Verb Mode Authorization
Required
getAssertion @id of the Assertion GET Initiate No
getClr /ims/clr/v1p0/clrs/{sourcedId} GET Initiate Yes
getEndorsement @id of the Endorsement GET Initiate No
getKey @id of the issuer's Public Key GET Initiate No
getRevocationList @id of the issuer's Revocation List GET Initiate No

7.2 Verification Consumer Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 3. Consumer Security Conformance
  • They MUST support the required verification endpoints
  • They MUST supply an access token with the appropriate scope with the getClr verification call
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads

8. Service Provider (Read) Conformance

A product that conforms to Service Provider (Read) requirements can provide Comprehensive Learner Records (CLRs) to a product that conforms to Service Consumer (Read) requirements. One example of such a product is a college or employer learning system which provides your CLRs to a wallet service which requested them.

8.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
getClrs /ims/clr/v1p0/clrs GET Respond Yes

8.2 Service Provider (Read) Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 4. Provider Security Conformance
  • They MUST support the required service endpoints
  • They MUST require an access token with the appropriate scope for the endpoint
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads
  • They MAY support the endpoint payload pagination query parameters. If supported, the corresponding response HTTP pagination headers MUST be supported

9. Service Provider (Write) Conformance

A product that conforms to Service Provider (Write) requirements can a) accept Comprehensive Learner Records (CLRs) from a product that conforms to Service Consumer (Write) requirements, and b) delete a Comprehensive Learner Record that it holds on request from a product that conforms to Service Consumer (Write) requirements. One example of such a product is a wallet service that accepts CLRs from a college or employer learning system.

9.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
postClr /ims/clr/v1p0/clrs POST Respond Yes

9.2 Optional 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
deleteClr /ims/clr/v1p0/clrs/{sourcedId} DELETE Repond Yes

9.3 Service Provider (Write) Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 4. Provider Security Conformance
  • They MUST support the required endpoints
  • They MAY support the optional endpoints
  • They MUST require an access token with the appropriate scope for the endpoint
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads

10. Verification Provider Conformance

A product that conforms to Verification Provider requirements can respond to the verification requests necessary to verify hosted and signed Assertions, CLRs, and Endorsements.

10.1 Required Verification Provider Endpoint Support

The verification endpoints that MUST be supported for Verification Provider are listed in the table below:

Verification Call Endpoint HTTP Verb Mode Authorization
Required
getAssertion @id of the Assertion GET Respond No
getClr /ims/clr/v1p0/clrs/{sourcedId} GET Respond Yes
getEndorsement @id of the Endorsement GET Respond No
getKey @id of the issuer's Public Key GET Respond No
getRevocationList @id of the issuer's Revocation List GET Respond No

10.2 Verification Provider Compliance

The functional capabilities of such systems are:

  • They MUST comply with § 4. Provider Security Conformance
  • They MUST support the required verification endpoints
  • They MUST require an access token with the appropriate scope for the getClr verification call
  • They MUST supply or 'handle' all of the required data fields in payloads
  • They MUST be capable of supplying or 'handling' all of the optional data fields in payloads
  • They MUST NOT provide extension data fields in the payloads

A. Revision History

This section is non-normative.

Version No. Release Date Comments
Version 1.0 IMS Candidate Final Public, Release 2.0 August 5, 2020 Updated to new approved certification plan.
Version 1.0 IMS Candidate Final Public, Release 2.0 August 29, 2019 Coordinated release 2.0 of version 1.0.
Version 1.0 IMS Candidate Final, Release 1.0 April 12, 2018 Release 1.0.

B. References

B.1 Normative references

[CLR-10]
IMS Comprehensive Learner Record (CLR) Specification Version 1.0. IMS Global. May 21, 2020. IMS Candidate Final Public. URL: https://www.imsglobal.org/spec/clr/v1p0/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

B.2 Informative references

[CASE-10]
Competencies and Academic Standards Exchange (CASE) Service Version 1.0. IMS Global Learning Consortium. July 2017. IMS Final Release. URL: https://www.imsglobal.org/activity/case/
[CLR-CERT-10]
IMS Comprehensive Learner Record (CLR) Conformance and Certification Guide Version 1.0. IMS Global. August 5, 2020. IMS Candidate Final Public. URL: https://www.imsglobal.org/spec/clr/v1p0/cert/
[CLR-IMPL-10]
IMS Comprehensive Learner Record (CLR) Implementation Guide Version 1.0. IMS Global. February 7, 2020. IMS Candidate Final Public. URL: https://www.imsglobal.org/spec/clr/v1p0/impl/
[CLR-JSON-10]
IMS Comprehensive Learner Record (CLR) JSON Schema Version 1.0. IMS Global. May 21, 2020. IMS Candidate Final Public. URL: https://purl.imsglobal.org/spec/clr/v1p0/schema/json/
[CLR-JSONLD-10]
IMS Comprehensive Learner Record (CLR) JSON-LD Context Version 1.0. IMS Global. May 21, 2020. IMS Candidate Final Public. URL: https://purl.imsglobal.org/spec/clr/v1p0/context/
[CLR-OPEN-10]
IMS Comprehensive Learner Record (CLR) OpenAPI Schema Version 1.0. IMS Global. May 21, 2020. IMS Candidate Final Public. URL: https://purl.imsglobal.org/spec/clr/v1p0/schema/openapi/

C. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Tamer AbuelsaadIBM
Jeff BohrerIMS Global
Sherri BraxtonUniversity of Maryland, Baltimore County
Deb EverhartLearning Objects
Steve GanceWA Comm & Tech Colleges
Jeff GrannCapella University
Matthew HailstoneBrigham Young University
Chris HoustoneLumenCo-Chair
Alex HripakCredly
Mark LeubaIMS Global
Jeff McNealState of Michigan Department of Education
Andy MillerIMS Global
Greg NadeauPublic Consulting GroupCo-Chair
Nate OttoConcentric Sky
Ozgur YogurtcuAEFIS

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

IMS Global 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.

IMS Global would appreciate receiving your comments and suggestions.

Please contact IMS Global through our website at http://www.imsglobal.org.

Please refer to Document Name: Comprehensive Learner Record Conformance and Certification Guide 1.0

Date: August 5, 2020