Comprehensive Learner Record Conformance and Certification Guide 1.0 1EdTech Candidate Final | IMS Global Learning Consortium

Comprehensive Learner Record Conformance and Certification Guide 1.0 1EdTech Candidate Final | IMS Global Learning Consortium
You are here
Specifications
Comprehensive Learner Record Standard™
Comprehensive Learner Record Conformance and Certification Guide 1.0 1EdTech Candidate Final
Abstract
The 1EdTech 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.
1.
Introduction
The 1EdTech Comprehensive Learner Record (CLR) Standard supports interoperability in that CLR publishers and consumers
can consistently send, receive, and verify records among conformant systems. The
CLR Standard describes an information model, service definition, and implementation
guide to allow institutions, suppliers, and others to 'extend' the traditional transcript
with records and types of information that are typically not found in a traditional
transcript, such as competency attainment, co-curricular activities, Open Badges, and to define
and facilitate an institution's learner achievements record store for collection
of CLRs.
CLR Standard data can be consumed by other schools, institutions, employers, and any other
entities that are conformant as CLR consumers. In this machine readable format, CLR
data enables granular and expansive discoverability of learning achievements and competencies that
was not previously possible.
1.1
Status of this Document
This document is intended as a starting point for those looking to implement the Comprehensive Learner Record Standard in their system. This guide can be used to get a fundamental understanding of the CLR Standard data structure and API through the examples and definitions included in the guide, as well as a central hub containing links to the specification documents, conformance certification requirements, and other important resources. This guide may be updated over time.
1EdTech strongly encourages its members and the community to provide feedback to continue
the evolution and improvement of the CLR Standard. To join the 1EdTech developer and
conformance certification community focused on CLR please visit the 1EdTech Digital Credentials
and Badging Alliance online here:
1.2
Specification Documents
CLR Standard specification documents are available on the 1EdTech website:
1EdTech Comprehensive Learner Record Standard Version 1.0
1EdTech Comprehensive Learner Record Standard v1.0: Implementation Guide
1EdTech Comprehensive Learner Record Standard v1.0: Conformance and Certification Guide
1EdTech Comprehensive Learner Record Standard v1.0: OpenAPI Schema
1EdTech Comprehensive Learner Record Standard v1.0: JSON Schema
1EdTech Comprehensive Learner Record Standard v1.0: JSON-LD Context
1.3
Where Can I Get Help?
If you have questions or need help with implementing the CLR Standard or achieving conformance
certification, here are some available resources:
Public
Forum
for all parties interested in CLR.
Affiliates
Forum
for 1EdTech Digital Credentials and Badging Alliance Members, Affiliate, and Contributing Members.
Reference Implementations
for a CLR Client Application,
a Resource Server, and an Authentication Server.
1EdTech Contributing Members have access to private GitHub repositories and a Slack
channel for CLR Project Group discussions and collaborations. Contact an 1EdTech staff
member to gain access.
1.4
Conformance Certification
1EdTech offers a process for testing the conformance of products using the 1EdTech certification test suite.
Certification designates passing a set of tests that verify the standard has been implemented correctly
and guarantees a product’s interoperability across hundreds of other certified products. The CLR
Conformance Certification Guide [
CLR-CERT-10
] provides details about the testing process, requirements,
and how to get started.
Conformance certification is much better than claims of “compliance," since the only way 1EdTech can guarantee
interoperability is by obtaining certification for the latest version of the standard. Only products listed
in the official
1EdTech Certified Product Directory
can claim conformance
certification. 1EdTech certification provides the assurance that a solution will integrate securely and
seamlessly into an institution's digital learning ecosystem.
In order to become certified a paid 1EdTech membership is necessary. Here's why: while conformance
certification provides a "seal" for passing prescribed tests it is much more than that. It is a commitment
by a supplier to the 1EdTech community for continuous support for achieving "plug and play" integration.
Certification implies ongoing community commitment to resolve problems, revise implementations and retest
as need. For that reason, only 1EdTech Contributing Members, Affiliate Members and Alliance members are eligible
to apply for conformance certification. Details and benefits of membership are listed here:
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.5
Product Directory Listing
The
1EdTech Certified Product Directory
is the official listing of products that have passed 1EdTech conformance
certification testing. Products that are listed in this directory are guaranteed
to meet the 1EdTech standards for which they have passed testing. If you experience an
integration issue with a product listed here, 1EdTech will work with the supplier to
resolve the problem. If a product is NOT listed here it has either not passed 1EdTech
testing or its certification has expired.
1.6
Key Terms and Definitions
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, evidence of competency mastery, a course completion, 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.
Evidence
Information supporting the issuance of an assertion such as URL to an artifact produced by the Learner.
Inspector
A Consumer 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.
Protected Information
In the United States, the Family Educational Rights and Privacy Act (
FERPA
) is a Federal Law that
protects personally identifiable information (PII) from students' educational records from unauthorized
disclosure. CLRs fall within the definition of educational records; and the CLR Learner Profile contains
PII. Therefore FERPA may apply to some uses of the CLR spec.
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.
2.
Comprehensive Learner Record (CLR) Standard Conformance
The goal of 1EdTech certification for the CLR Standard [
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.
1EdTech certification for the CLR Standard 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 options: CLR Consumer, CLR Provider, and CLR Host. A product
can be certified for more than one option.
Figure
Diagram of the CLR ecosystem showing the relationships between CLR Consumer, CLR Provider, and CLR
Host
Certification
CLR Consumer
CLR Provider
CLR Host
Profile
Retrieves CLR records from multiple sources and provides storage and reorganization of CLR records.
Creates CLR records and credentials and provides verification.
Receives and hosts CLR records for pass through consumption.
Software Type
Wallet application, gradebook, SIS, portfolio, talent search
SIS, assessment management platform, degree audit system
Recruitment/career platform, credentials management platform
Functions
CLR Consumers can retrieve CLRs from CLR Providers and CLR Hosts for display and/or processing. These
types of applications are display and temporary storage environments for learner credentials. They can read
and merge learner credentials from multiple Providers and Hosts.
CLR Providers create and own CLRs, handle revocations, and provide verification. These applications are
the source of truth for the data in the CLR. Providers create assertions for learners. Learners can move
their CLRs to Consumers and Hosts to view/manage/store them. Providers provide the critical tasks of
creating, maintaining, and verifying the learner CLRs in the overall CLR ecosystem.
CLR Hosts are platforms that can receive CLR records from CLR Providers or other CLR Hosts. These types of
applications are used by learners to consolidate and manage their learning records and where the learner
records are stored for consumption.
Each option requires the implementation of CLR service endpoints (REST API endpoints). Many endpoints require
OAuth 2 authorization. CLR Consumers, CLR Providers, and CLR Hosts are required to support the OAuth 2
Authorization Code and/or Client Credentials token grant flow.
The specific requirements for each certification option are described in sections below.
2.1
The Conformance Process
The process for conformance testing implementations of Comprehensive Learner Record Standard includes the
following:
Go to the
CLR Validator
web page.
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 meet the following criteria:
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 options 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 CLR and display the 1EdTech certified logo on your website and in your software. The 1EdTech
Certified Products Directory will list your conformance details.
3.
CLR Consumer Conformance
A product that conforms to CLR Consumer requirements can request Comprehensive Learner Records (CLRs) from a
product that conforms to
CLR Provider
or
CLR Host
requirements, and request verification of CLR records. One example of such a product is a wallet application which
requests your CLRs from your college or employer.
3.1
Required CLR Consumer Endpoint Support
The service endpoints that
MUST
be supported by a CLR Consumer are listed in the table below:
Service Call
Endpoint
HTTP Verb
Mode
Authorization
Required
getClrs
/ims/clr/v1p0/clrs
GET
Initiate
Yes
Verification
getAssertion
/ims/clr/v1p0/assertions/{sourcedId}
GET
Initiate
No
getClr
/ims/clr/v1p0/clrs/{sourcedId}
GET
Initiate
Yes
getEndorsement
/ims/clr/v1p0/endorsements/{sourcedId}
GET
Initiate
No
getKey
/ims/clr/v1p0/keys/{sourcedId}
GET
Initiate
No
getRevocationList
/ims/clr/v1p0/revocations/{sourcedId}
GET
Initiate
No
3.2
CLR Consumer Compliance
The functional capabilities of such systems are:
They
MUST
comply with
6.
OAuth 2 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
4.
CLR Provider Conformance
A product that conforms to CLR Provider requirements can provide Comprehensive Learner Records (CLRs) to a
product that conforms to
CLR Consumer
or
CLR Host
requirements, and provide verification of its CLR records. One example of such a product is a college or employer
learning system which provides your CLRs to a wallet application which requested them.
4.1
Required CLR Provider Endpoint Support
The service endpoints that
MUST
be supported by a CLR Provider are listed in the table below:
Service Call
Endpoint
HTTP Verb
Mode
Authorization
Required
getClrs
/ims/clr/v1p0/clrs
GET
Respond
Yes
Verification
getAssertion
/ims/clr/v1p0/assertions/{sourcedId}
GET
Respond
No
getClr
/ims/clr/v1p0/clrs/{sourcedId}
GET
Respond
Yes
getKey
/ims/clr/v1p0/keys/{sourcedId}
GET
Respond
No
getRevocationList
/ims/clr/v1p0/revocations/{sourcedId}
GET
Respond
No
4.2
Optional CLR Provider Endpoint Support
The service endpoints that
MAY
be supported by a CLR Provider are listed in the table below:
Service Call
Endpoint
HTTP Verb
Mode
Authorization
Required
Verification
getEndorsement
/ims/clr/v1p0/endorsements/{sourcedId}
GET
Respond
No
4.3
CLR Provider Compliance
The functional capabilities of such systems are:
They
MUST
comply with
7.
OAuth 2 Provider Security Conformance
They
MUST
support the required service 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
They
MAY
support the endpoint payload pagination query parameters. If supported, the corresponding response
HTTP pagination headers
MUST
be supported
5.
CLR Host Conformance
A product that conforms to CLR Host requirements can request Comprehensive Learner Records (CLRs) from a product
that conforms to
CLR Provider
or CLR Host requirements, provide CLRs to a
CLR Consumer
or a CLR Host, send a CLR to a CLR Host, receive a CLR from a CLR Host,
request verification of a CLR, optionally request that a CLR Host delete a CLR, and optionally respond to a
request from a CLR Host to delete a CLR.
5.1
Required CLR Host Endpoint Support
The service endpoints that
MUST
be supported for CLR Host are listed in the table below:
Service Call
Endpoint
HTTP Verb
Mode
Authorization
Required
getClrs
/ims/clr/v1p0/clrs
GET
Initiate
Yes
getClrs
/ims/clr/v1p0/clrs
GET
Respond
Yes
postClr
/ims/clr/v1p0/clrs
POST
Initiate
Yes
postClr
/ims/clr/v1p0/clrs
POST
Respond
Yes
Verification
getAssertion
/ims/clr/v1p0/assertions/{sourcedId}
GET
Initiate
No
getClr
/ims/clr/v1p0/clrs/{sourcedId}
GET
Initiate
Yes
getEndorsement
/ims/clr/v1p0/endorsements/{sourcedId}
GET
Initiate
No
getKey
/ims/clr/v1p0/keys/{sourcedId}
GET
Initiate
No
getRevocationList
/ims/clr/v1p0/revocations/{sourcedId}
GET
Initiate
No
5.2
Optional CLR Host Endpoint Support
The service endpoints that
MAY
be supported for CLR Host are listed in the table below:
Service Call
Endpoint
HTTP Verb
Mode
Authorization
Required
deleteClr
/ims/clr/v1p0/clrs/{sourcedId}
DELETE
Initiate
Yes
deleteClr
/ims/clr/v1p0/clrs/{sourcedId}
DELETE
Respond
Yes
5.3
CLR Host Compliance
The functional capabilities of such systems are:
They
MUST
comply with
6.
OAuth 2 Consumer Security Conformance
and
7.
OAuth 2 Provider 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
6.
OAuth 2 Consumer Security Conformance
A product that initiates any service endpoint request that requires authorization must conform to either OAuth 2
Consumer Authorization Code Grant Flow Support, OAuth 2 Consumer Client Credentials Grant Flow Support, or both.
6.1
Required OAuth 2 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
6.2
Required OAuth 2 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 setup
POST
Initiate
6.3
OAuth 2 Consumer Security Compliance
The functional capabilities of such systems are:
They
MUST
support the required endpoints for
6.1
Required OAuth 2 Consumer Authorization Code Grant Flow Support
6.2
Required OAuth 2 Consumer Client Credentials Grant Flow Support
or both
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.
OAuth 2 Provider Security Conformance
A product that responds to any service endpoint request that requires authorization must conform to either OAuth
2 Provider Authorization Code Grant Flow Support, OAuth 2 Provider Client Credentials Grant Flow Support, or both.
7.1
Required OAuth 2 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
7.2
Required OAuth 2 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
7.3
OAuth 2 Provider Security Compliance
The functional capabilities of such systems are:
They
MUST
support the required endpoints for
7.1
Required OAuth 2 Provider Authorization Code Grant Flow Support
7.2
Required OAuth 2 Provider Client Credentials Grant Flow Support
or both
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
CLR 1.0 Final
February 5, 2021
Reduced service certification options to three: CLR Consumer, CLR Provider, and CLR Host.
CLR 1.0 Final
January 14, 2021
First release of CLR 1.0 Final. Incorporates changes since May 2020.
B.
References
B.1
Normative references
[CASE-10]
Competencies and Academic Standards Exchange (CASE) Service Version 1.0
. 1EdTech Consortium. July 2017. 1EdTech Final Release. URL:
[CLR-10]
1EdTech Comprehensive Learner Record Standard Version 1.0
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[CLR-CERT-10]
1EdTech Comprehensive Learner Record Standard v1.0: Conformance and Certification Guide
. 1EdTech. February 5, 2021. 1EdTech Final Release. URL:
[CLR-IMPL-10]
1EdTech Comprehensive Learner Record Standard v1.0: Implementation Guide
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[CLR-JSON-10]
1EdTech Comprehensive Learner Record Standard v1.0: JSON Schema
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[CLR-JSONLD-10]
1EdTech Comprehensive Learner Record Standard v1.0: JSON-LD Context
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[CLR-OPEN-10]
1EdTech Comprehensive Learner Record Standard v1.0: OpenAPI Schema
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels
. S. Bradner. IETF. March 1997. Best Current Practice. URL:
C.
List of Contributors
The following individuals contributed to the development of this document:
Name
Organization
Role
Tamer Abuelsaad
IBM
Jeff Bohrer
1EdTech
Sherri Braxton
University of Maryland, Baltimore County
Deb Everhart
Learning Objects
Steve Gance
WA Comm & Tech Colleges
Jeff Grann
Capella University
Matthew Hailstone
Brigham Young University
Chris Houston
Capella University and eLumen
Co-Chair
Alex Hripak
Credly
Tracy Korsmo
North Dakota Information Technology
Mark Leuba
1EdTech
Jeff McNeal
State of Michigan Department of Education
Andy Miller
1EdTech
Greg Nadeau
Public Consulting Group
Co-Chair
Nate Otto
Concentric Sky
David Ward
Public Consulting Group
Ozgur Yogurtcu
AEFIS
Co-Chair
Sharebar?