Comprehensive Learner Record Implementation Guide 1.0 1EdTech | IMS Global Learning Consortium

Comprehensive Learner Record Implementation Guide 1.0 1EdTech | IMS Global Learning Consortium
You are here
Specifications
Comprehensive Learner Record Standard™
Comprehensive Learner Record Implementation Guide 1.0 1EdTech
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:
This document is an informative resource in the Document Set of the
Comprehensive Learner Record Standard specification
CLR-10
].
As such, it does not include any normative requirements. Occurrences in this
document of terms such as MAY, MUST, MUST NOT, SHOULD or RECOMMENDED have no
impact on the conformance criteria for implementors of this specification.
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.
Getting Started
2.1
Audience
This guide is for technical professionals who work with educational data, including business analysts,
database
administrators, and software developers. The primary audience is developers of CLR platforms, but developers
of
client applications may find this information useful.
2.2
How to Create a CLR
This section describes how to use the CLR data model in several different scenarios. The examples are
truncated to show just enough information to represent the concept. Please refer to
1EdTech Comprehensive Learner Record Standard Version 1.0
for
detailed data model requirements.
2.2.1
As a publisher I want to publish a "complete" or "whole" CLR
2.2.2
As a learner I want to self-publish a custom CLR
2.2.3
As a learner I want to self-issue a custom Assertion
2.2.4
As publisher I want to issue a single achievement assertion
2.2.5
As an issuer I want to identify the entity that assessed an achievement
2.2.6
As an issuer I want to assert the level of mastery
2.2.7
As an issuer I want to assert a competency defined in a CASE framework
2.2.8
As an issuer I want to assert a rubric criterion level defined in a CASE framework
2.2.9
As a publisher I want to associate achievements in a hierarchy
2.2.1
As a publisher I want to publish a "complete" or "whole" CLR
By default, the receiver of a CLR can assume the publisher included all the achievement assertions
for the learner that the receiver is allowed to see. The publisher must include their own
publisher
profile, the
learner
profile, the
assertions
, and the
issuedOn
timestamp. If the publisher includes the
partial
property, it should
be
false
. If an assertion does not appear in a later CLR from the same publisher and for
the same leaner, and
partial
is omitted or
false
, the receiver can assume the
assertion has been revoked.
Example
: A complete CLR
This CLR snippet shows the required elements for a complete CLR:
learner
publisher
assertions
, and
issuedOn
"type"
"Clr"
"learner"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
"email"
"student@example.edu"
"sourcedId"
"abcde"
"studentId"
"12345"
},
"publisher"
: {
"type"
"Profile"
"id"
"urn:uuid:8190dbd9-3741-43b7-9edc-c35455c26e5e"
"email"
"registrar@example.edu"
},
"assertions"
: [
"type"
"Assertion"
"id"
"urn:uuid:7a2e6445-9095-4c66-8d91-5c7ea6e4e8bb"
"achievement"
: {
"id"
"urn:uuid:e34ec584-f552-4d63-bd5d-113f2ccc0a55"
"achievementType"
"Achievement"
"name"
"Sample Achievement"
},
"issuedOn"
"2007-04-05T14:30"
],
"issuedOn"
"2007-04-05T14:30"
2.2.2
As a learner I want to self-publish a custom CLR
Each assertion within a CLR can be independently verified. That means a new CLR can be formed which includes
verifiable achievements from other CLRs. For example, a Learner may want to send a custom CLR to a potential
employer that only includes achievements relevant to the job.
A self-published CLR is one where both the
publisher
id
and
learner
id
are the same. The
assertions
may come from different issuers and the
recipient
may be identified with different
identity
values. Consumers should assume
a CLR is self-published if the
learner
profile has the same
id
as the
code>publisher profile
id
Example
: A self-published CLR
This CLR snippet shows a self-published CLR: the
learner
profile
id
matches
the
publisher
profile
id
"type"
"Clr"
"learner"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"publisher"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"assertions"
: [
"type"
"Assertion"
"recipient"
: {
"type"
"id"
"identity"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"achievement"
: {
"type"
"Achievement"
"id"
"urn:uuid:3cac5ecd-01b4-457b-b11a-cd9b30604634"
"achievementType"
"Achievement"
"name"
"Sample Achievement"
2.2.3
As a learner I want to self-issue a custom Assertion
A Learner can issue achievement assertions to themself and a Publisher can include the self-issued
achievement assertion in a CLR. In this case the achievement
issuer
and
learner
profiles are the same (have the same
id
).
Example
: A self-issued assertion
This snippet shows a CLR with a self-issued Assertion: the
learner
profile
id
matches the
issuer
profile
id
"type"
"Clr"
"learner"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"publisher"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"assertions"
: [
"type"
"Assertion"
"recipient"
: {
"type"
"id"
"identity"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"issuer"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
},
"narrative"
"I have volunteered at Habitat for Humanity for 5 years"
2.2.4
As publisher I want to issue a single achievement assertion
As noted in
2.2.1
As a publisher I want to publish a "complete" or "whole" CLR
, a Publisher normally includes all of a Learner's achievement assertions
the receiver is allowed to see. And the receiver can assume that if an achievement assertion no longer appears
in the Learner's CLR, it has been revoked.
If the Publisher wants to transfer a single achievement assertion without revoking others, the publisher
should include
partial
with a value of
true
. In this case the receiver should not
assume any other achievement assertions have been revoked.
A common use case for setting
partial
to
true
is when an LMS is sending a single
achievement to a credential management hub in real time.
Example
: A single assertion
This CLR snippet shows a single assertion with
partial
set to
true
"type"
"Clr"
"partial"
true
"learner"
: {
"type"
"Profile"
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
"email"
"student@example.edu"
"sourcedId"
"abcde"
"studentId"
"12345"
},
"publisher"
: {
"type"
"Profile"
"id"
"urn:uuid:8190dbd9-3741-43b7-9edc-c35455c26e5e"
"email"
"registrar@example.edu"
},
"assertions"
: [
"type"
"Assertion"
"id"
"urn:uuid:7a2e6445-9095-4c66-8d91-5c7ea6e4e8bb"
"achievement"
: {
"type"
"Achievement"
"id"
"urn:uuid:e34ec584-f552-4d63-bd5d-113f2ccc0a55"
"achievementType"
"Achievement"
"name"
"Sample Achievement"
},
"issuedOn"
"2007-04-05T14:30"
],
"issuedOn"
"2007-04-05T14:30"
2.2.5
As an issuer I want to identify the entity that assessed an achievement
The achievement Issuer is the entity responsible for providing verification of an achievement assertion.
However, it may be the case the Issuer did not make the assessment that the achievement should be asserted. In
that case, the Assertion should include the
source
property to identify the person or
organization that assessed the achievement.
For example, a school district may be the official issuer of achievements, but the schools within the
district are responsible for assessing the achievement. In this scenario, the assertion should include the
source
profile of the school making the assessment, and the achievement should include the
issuer
profile of the school district.
Example
: An assertion with a source property
This snippet shows an assertion with a different
source
than the achievement
issuer
"type"
"Assertion"
"source"
: {
"type"
"Profile"
"id"
"urn:uuid:e557c27f-48d1-43ec-9931-38c41ab2f610"
},
"achievement"
: {
"type"
"Achievement"
"issuer"
: {
"type"
"Profile"
"id"
"urn:uuid:a9f7f643-4f97-473f-b91e-aa7dc4b68551"
2.2.6
As an issuer I want to assert the level of mastery
If you wish to assert levels of mastery, each Achievement
resultDescription
should contain
rubricCriterionLevels
. And each Assertion should include the
achievedLevel
as a
Result.
Example
: Describing levels of mastery
This Achievement snippet describes 3 levels of mastery: Below Basic, Basic, Exceeds.
"type"
"Achievement"
"resultDescriptions"
: [
"id"
"urn:uuid:da72e42e-9f38-4c42-83ac-33f6cb9bb3b1"
"name"
"Mastery"
"resultType"
"PerformanceLevel"
"rubricCriterionLevels"
: [
"id"
"urn:uuid:24df3f14-4b9b-41b9-9e6b-d48798442425"
"name"
"Below Basic"
"level"
"Below Basic"
"description"
"The student made fewer than 3 citations"
},
"id"
"urn:uuid:c225be08-c67d-4ec8-ae8e-4860e83588ef"
"name"
"Basic"
"level"
"Basic"
"description"
"The student made 3-5 citations"
},
"id"
"urn:uuid:f256d3a9-c117-43bf-9e25-dc69691e18a1"
"name"
"Exceeds"
"level"
"Exceeds"
"description"
"The student made more than 5 citations"
The assertion
results
should contain the level of mastery achieved.
Example
: Asserting a level of mastery
This Assertion snippet asserts the Exceeds level of mastery.
"type"
"Assertion"
"results"
: [
"resultDescription"
"urn:uuid:da72e42e-9f38-4c42-83ac-33f6cb9bb3b1"
"achievedLevel"
"urn:uuid:f256d3a9-c117-43bf-9e25-dc69691e18a1"
2.2.7
As an issuer I want to assert a competency defined in a CASE framework
When the achievement description represents a CASE compentency or academic standard, the
Achievment should contain an Alignment to the CASE CFItem. The Alignment should have a
targetType
of
CFItem
and the
targetUrl
should should be
the
uri
of the CFItem.
Example
: Align an achievement to a CASE CFItem
This CLR snippet shows an Achievement aligned to the "Alabama Course of Study: English Language Arts >
Grade 12 > Reading Standards for Literature > Key Ideas and Details >
1. Cite strong and thorough textual evidence
to support analysis of what the text says explicitly as well as inferences drawn from the text, including
determining where the text leaves matters uncertain
" academic standard hosted on the 1EdTech CASE Network.
"type"
"Clr"
"assertions"
: [
"type"
"Assertion"
"achievement"
: {
"type"
"Achievement"
"id"
"urn:uuid:e34ec584-f552-4d63-bd5d-113f2ccc0a55"
"achievementType"
"Competency"
"name"
"Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain"
"alignments"
: [
"targetFramework"
"Alabama Course of Study: English Language Arts"
"targetName"
"Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain"
"targetType"
"CFItem"
"targetUrl"
"https://caseregistry.imsglobal.org/uri/74f5bb7d-d7cc-11e8-824f-0242ac160002"
2.2.8
As an issuer I want to assert a rubric criterion level defined in a CASE framework
When the Result represents a particular CASE rubric criterion level, the Achievement
resultDescriptions
should include a ResultDescription aligned to the CFRubric, the
ResultDescription
rubricCriterionLevels
should include a RubricCriterionLevel aligned to the
CFRubricCriterionLevel, and the Assertion
results
should contain a Result with the
achievedLevel
Example
: Align Achievement to CASE CFRubric
This CLR snippet shows an Achievement aligned to the sample CFRubric shown in the
CASE 1.0 Best Practices and Implementation Guide
, and
an Assertion Result linked to a specific CFRubricCriterionLevel.
"type"
"Clr"
"assertions"
: [
"type"
"Assertion"
"achievement"
: {
"type"
"Achievement"
"achievementType"
"Competency"
"name"
"Performance Improvement Project Scores"
"resultDescriptions"
: [
"id"
"urn:uuid:4c75445c-e3b0-459e-9e3a-5f4bb03cb0f9"
"name"
"Performance Improvement Project Scores"
"resultType"
"RubricCriterionLevel"
"alignments"
: [
"type"
"CFRubric"
"targetFramework"
"Health Care Rubrics"
"targetName"
"Performance Improvement Projects Scoring Guide"
"targetUrl"
"http://axiom.cs.hmhco.com/ims/mrflsc/v1p0/CFRubric/c320e4f3-043a-11e7-a400-12c6ab5e124d"
],
"rubricCriterionLevels"
: [
"id"
"urn:uuid:566671a7-e82d-499e-a204-fa4c990a12a1"
"name"
"Exceeds"
"level"
"Outlines a performance improvement issue within a health care organization that needs improvement and provides some relevant background information."
"alignments"
: [
"targetFramework"
"Health Care Rubrics"
"targetName"
"Outlines a performance improvement issue within a health care organization that needs improvement and provides some relevant background information."
"targetType"
"CFRubricCriterionLevel"
"targetUrl"
"http://axiom.cs.hmhco.com/ims/mrflsc/v1p0/CFRubricCriterionLevel/f2439cb5-05c3-11e7-a400-12c6ab5e124d"
},
},
"id"
"urn:uuid:fbff8396-fcb3-498c-b6eb-4f706830187b"
"name"
"Meets"
"level"
"Provides solid and relevant reasons for why a performance improvement problem is an issue worth fixing in a health care organization and identifies assumptions on which the analysis is based."
"alignments"
: [
"targetFramework"
"Health Care Rubrics"
"targetName"
"Provides solid and relevant reasons for why a performance improvement problem is an issue worth fixing in a health care organization and identifies assumptions on which the analysis is based."
"targetType"
"CFRubricCriterionLevel"
"targetUrl"
"http://axiom.cs.hmhco.com/ims/mrflsc/v1p0/CFRubricCriterionLevel/5a68203f-05c4-11e7-a400-12c6ab5e124d"
},
"results"
: [
"resultDescription"
"urn:uuid:4c75445c-e3b0-459e-9e3a-5f4bb03cb0f9"
"achievedLevel"
"urn:uuid:566671a7-e82d-499e-a204-fa4c990a12a1"
2.2.9
As a publisher I want to associate achievements in a hierarchy
CLR Achievements can be associated with each other to represent relationships within a CLR and relationships
between the achievements asserted in the CLR and achievements within a larger curriculum. An Association
describes a relationship between a source Achievement and a target Achievement. Some association types, for
example
exactMatchOf
and
isRelatedTo
, are transitive and represent the same meaning
regardless of source or target. Some association types have an implicit reverse association when the source
and target are switched; two such examples include "A
isChildOf
B" having an implicit "B
isParentOf
A"; and "A
isReplacedBy
B" having an implicit "B
replaces
A". CLR does not explicitly specify these reverse associations. The interpretation and use of these are at the
discretion of the implementation.
The target of any association does not need to be part of the CLR.
As noted in the
CFItem
example, achievements can be aligned to CFItems which can
also be associated to other CFItems. Publishers and issuers may use CLR Associations and/or CASE Associations
to describe the relationships between achievements in a CLR. CLR Associations only associate CLR Achievements.
CASE Associations only associate CASE Documents.
Example
10
: Associated Achievements
This CLR snippet shows two associations: one between the two achievements asserted within the CLR, and one
between an asserted achievement and an achievement on a future learning path for the learner.
"assertions"
: [
"type"
"Assertion"
"achievement"
: {
"id"
"https://example.edu/achievements/1"
"type"
"Achievement"
"name"
"Achievement 1"
"associations"
: [
"associationType"
"isParentOf"
"title"
"Achievement 2"
"targetId"
"https://example.edu/achievements/2"
},
"type"
"Assertion"
"achievement"
: {
"id"
"https://example.edu/achievements/2"
"type"
"Achievement"
"name"
"Achievement 2"
"associations"
: [
"associationType"
"isChildOf"
"title"
"Achievement 1"
"targetId"
"https://example.edu/achievements/1"
2.3
How to use the API
This section describes how to use the CLR API in several different scenarios.
2.3.1
As a consumer system I want to get all the CLRs I'm authorized to access from a
provider system
2.3.2
As a consumer system I want to post a single CLR to a provider system
2.3.3
As a consumer system I want to delete a single CLR from a provider system
2.3.4
As an inspector I want to get a single CLR
2.3.5
As an inspector I want to get a single assertion
2.3.6
As an inspector I want to get a single endorsement
2.3.7
As an inspector I want to get an issuer's public key
2.3.1
As a consumer system I want to get all the CLRs I'm authorized to access from a
provider system
A Consumer organization's system reads (GETs) one or more learners' Comprehensive Learner Records from an
Provider organization's system. This use case supports systems interoperability uses such as
transferring CLR data from one system to another. It can also be used to get data to populate
collections or repositories of Comprehensive Learner Records.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System; and
Authorization Server.
Preconditions
The Consumer knows the Provider's 'getClrs' endpoint URL. The Consumer has an
authorization code
or
client
credentials
which can be used to request an
access token
that
grants access to the CLRs on the Provider
system.
Primary Flow
Consumer system/service requests an access token from the Authorization Server.
The Authorization Server responds with the access token.
Consumer system/service initiates a GET request to the Provider's system/service 'getClrs' endpoint,
passing the access token as a
bearer token
in the
Authorization header.
Compliant ClrSet payload will be generated by Provider based on the access granted by the access
token.
Provider responds HTTP status 200 OK with the payload to the Consumer.
Consumer receives the CLR payload.
Consumer processes the payload successfully.
Alternate Flows
Consumer system includes the
since
query
parameter in the GET request: Provider responds with a ClrSet payload that contains CLRs that were
issued after the provided timestamp.
Consumer sends a malformed request: Provider responds with HTTP status 400 Bad Request and an
imsx_StatusInfo payload with the exact error.
Consumer is not authenticated: Provider responds with HTTP status 401 Unauthorized and an
unauthorized payload using the imsx_StatusInfo object.
Consumer is not authorized: Provider responds with HTTP status 403 Forbidden and an unauthorized
payload using the imsx_StatusInfo object.
CLRs not found: Provider responds with HTTP status 404 Not Found and an imsx_StatusInfo object with
the exact error.
2.3.2
As a consumer system I want to post a single CLR to a provider system
A Consumer organization's system sends (POSTs) a Comprehensive Learner Record to an Provider
organization's system. This use case supports systems interoperability uses such as transferring CLR
data from one system to another. It can also be used to create or update a Comprehensive Learner Record
on the Provider.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System; and
Authorization Server.
Preconditions
: The Consumer knows the Provider's 'postClr' endpoint URL. The Consumer has an
authorization code
or
client
credentials
which can be used to request an
access token
that
grants the appropriate access to the CLR on
the Provider system.
Primary Flow
Consumer system/service requests an access token from the Authorization Server.
The Authorization Server responds with the access token.
Consumer creates the POST request payload consisting of the CLR to create or update on Provider.
Consumer system/service initiates a POST request to the Provider's system/service 'postClr'
endpoint, passing the payload in the body of the request, and the access token as a
bearer token
in the Authorization header.
Provider creates or updates the CLR and create the response payload consisting of the CLR that was
created or updated.
Provider responds HTTP status 200 OK if the CLR was updated/replaced or 201 Created if the CLR was
created and the payload to the Consumer.
Consumer receives the CLR payload.
Consumer processes the payload successfully.
Alternate Flows
Consumer sends a CLR that already exists and exactly matches the CLR on the Provider system:
Provider responds with HTTP status 304 Not Modified and no payload.
Consumer sends a malformed request: Provider responds with HTTP status 400 Bad Request and an
imsx_StatusInfo payload with the exact error.
Consumer is not authenticated: Provider responds with HTTP status 401 Unauthorized and an
unauthorized payload using the imsx_StatusInfo object.
Consumer is not authorized: Provider responds with HTTP status 403 Forbidden and an unauthorized
payload using the imsx_StatusInfo object.
CLR not found: Provider responds with HTTP status 404 Not Found and an imsx_StatusInfo object with
the exact error.
2.3.3
As a consumer system I want to delete a single CLR from a provider system
A Consumer organization's system DELETEs a Comprehensive Learner Record to an Provider organization's
system.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System; and
Authorization Server.
Preconditions
: The Consumer knows the Provider's 'deleteClr' endpoint URL and the
id
of the CLR to be deleted. The Consumer has an
authorization
code
or
client credentials
which can be used to request
an
access token
that grants the appropriate access to the CLR on
the Provider system.
Primary Flow
Consumer system/service requests an access token from the Authorization Server.
The Authorization Server responds with the access token.
Consumer system/service initiates a DELETE request to the Provider's system/service 'deleteClr'
endpoint, passing the access token as a
bearer token
in the
Authorization header.
Provider deletes the CLR.
Provider responds HTTP status 204 No Content to the Consumer.
Alternate Flows
Consumer sends a malformed request: Provider responds with HTTP status 400 Bad Request and an
imsx_StatusInfo payload with the exact error.
Consumer is not authenticated: Provider responds with HTTP status 401 Unauthorized and an
unauthorized payload using the imsx_StatusInfo object.
Consumer is not authorized: Provider responds with HTTP status 403 Forbidden and an unauthorized
payload using the imsx_StatusInfo object.
CLR not found: Provider responds with HTTP status 404 Not Found and an imsx_StatusInfo object with
the exact error.
2.3.4
As an inspector I want to get a single CLR
A Consumer organization or system reads (GETs) a specific Comprehensive Learner Record from a Provider
system. This use case supports hosted verification of a CLR and/or determines if the CLR has been
revoked.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System.
Preconditions
: Consumer has the
id
of a CLR and the
id
is the URL to the
Provider's 'getClr' endpoint that returns the CLR.
Primary Flow
Consumer system/service will initiate a call to the Provider's system/service for a specific CLR.
Compliant CLR payload will be generated by Provider based on a lookup of the unique identifier of
the CLR.
Provider responds HTTP status 200 OK with the payload to the Consumer.
Consumer receives the CLR payload.
Consumer processes the payload successfully.
Alternate Flows
The CLR does not exist: Provider responds HTTP status 404 Not Found.
2.3.5
As an inspector I want to get a single assertion
A Consumer organization or system reads (GETs) a specific Assertion from a Provider system. This use case
supports hosted verification of an Assertion and/or determines if the Assertion has been revoked.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System.
Preconditions
: Consumer has the
id
of an Assertion and the
id
is the URL
to the Provider's 'getAssertion' endpoint that returns the Assertion.
Primary Flow
Consumer system/service will initiate a call to the Provider's system/service for a specific
Assertion.
Compliant Assertion payload will be generated by Provider based on a lookup of the unique identifier
of the Assertion.
Provider responds HTTP status 200 OK with the payload to the Consumer.
Consumer receives the Assertion payload.
Consumer processes the payload successfully.
Alternate Flows
The Assertion does not exist: Provider responds HTTP status 404 Not Found.
2.3.6
As an inspector I want to get a single endorsement
A Consumer organization or system reads (GETs) a specific Endorsement from a Provider system. This use
case supports hosted verification of an Endorsement and/or determines if the Endorsement has been
revoked.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System.
Preconditions
: Consumer has the
id
of an Endorsement and the
id
is the
URL to the Provider's 'getEndorsement' endpoint that returns the Endorsement.
Primary Flow
Consumer system/service will initiate a call to the Provider's system/service for a specific
Endorsement.
Compliant Endorsement payload will be generated by Provider based on a lookup of the unique
identifier of the Endorsement.
Provider responds HTTP status 200 OK with the payload to the Consumer.
Consumer receives the Endorsement payload.
Consumer processes the payload successfully.
Alternate Flows
The Endorsement does not exist: Provider responds HTTP status 404 Not Found.
2.3.7
As an inspector I want to get an issuer's public key
A Consumer organization or system reads (GETs) a specific CryptographicKey from a Provider system. This
use case supports signed verification of CLRs, Assertions, and Endorsements.
Actors
: CLR Provider and CLR Consumer Institution, Vendor, Student Information System (SIS),
Learning Management System (LMS), Employer, Organization, CLR Renderer, or Internal System.
Preconditions
: Consumer has the
id
of a CryptographicKey and the
id
is
the URL to the Provider's 'getKey' endpoint that returns the CryptographicKey.
Primary Flow
Consumer system/service will initiate a call to the Provider's system/service for a specific
CryptographicKey.
Compliant CryptographicKey payload will be generated by Provider based on a lookup of the unique
identifier of the CryptographicKey.
Provider responds HTTP status 200 OK with the payload to the Consumer.
Consumer receives the CryptographicKey payload.
Consumer processes the payload successfully.
Alternate Flows
The CryptographicKey does not exist: Provider responds HTTP status 404 Not Found.
3.
Best Practices
3.1
Institutional Context
The Comprehensive Learner Record is a new concept for learners, faculty, and administrators; but all of these
groups have a role in creating the CLR in a way that supports the mission of a particular institution or
organization. An institutional or organizational team is recommended to appropriately plan for, implement,
and assess the CLR.
Foundations: Critical Questions
Define the CLR for your institution and stakeholder groups. Ask: What does the CLR mean to you?
What information do you want to include? How do you expect learners to use this information? How
does this type of document fit into your organizational mission and brand?
Where is the information you hope to represent on the CLR currently located (system, paper, not
recorded anywhere)? What data is available in an accessible format and what data is not? For
data that is not accessible, what needs to happen to get the data in a format that will allow
you to create a CLR?
What kind of record do you need to provide? PDF, digital, paper, or all of these?
Do you need to conduct a pilot first, or do you plan to implement directly across the entire
institution?
Will you engage employers as part of the process?
Which institutional policies will be impacted in the decision to move forward, and who will
shepherd them through changes and approval processes?
How can the document be secured in terms of data integrity and security?
Foundations: Planning
Identify the stakeholders and "champions" that need to be involved in the planning and
implementation phases from an administrative, academic, and technological perspective.
Develop a project plan, including milestones, timeline for deliverables, and ownership
accountability.
Clearly define responsibilities of the project team.
Identify a go live date.
Determine what support and technology can be built in-house and what might require vendor
support.
What is your communication plan? How will you socialize and explain this document to those
outside of the project?
Determine how you will assess the CLR, collect feedback, and evaluate how is it being used,
including determining what tools to use in this part of the process.
Implementation:
Create a plan to test integration, user experience, and the CLR documents themselves.
Create feedback loops to ensure project team is connected and aware of changes or delays.
Finalize look and feel of the document.
Create a marketing plan to be clear on the communications that will be received by learners,
faculty, and staff.
Determine how will you collect data.
Define a plan for continuous process improvement based on assessment, feedback, and industry
trends and developing practices.
Put together a plan of how to resolve an technology or content related issues once the document
is live.
Evaluation and Assessment of the CLR:
Evaluation and Assessment of the CLR:
How should an individual's CLR be managed and updated over time? The CLR is meant to be a
dynamic document reflecting the most current and correct information as of its production. There
should be a date on the CLR that reflects the date it was produced.
Identify how changes should be handled – it is recommended changes happen in the source systems
as the CLR is designed to be produced dynamically with real time data.
Identify revocation practices as needed.
Analyze results and implement a continuous improvement model for the CLR that embraces the
changing educational experiences of learners.
3.2
Security and Privacy
All conformant Comprehensive Learner Record provider services are secured using OAuth 2.0 Bearer Token
authorization [
RFC6749
], and conformant Comprehensive Learner Record consumers must also support bearer
token authorization. Additionally, some providers and consumers may support additional authorization
mechanisms.
In general, for any consumer that is authorized to access any Comprehensive Learner Record(s), the
Comprehensive Learner Record service should provide all relevant data that the authorized party should have
access to, accounting for data availability and performance considerations. However, in the event that a
provider wishes to provide varying degrees of access to various entities, or that the provider does not wish
to disclose other details out of privacy concerns, the provider may intentionally omit data from the
Comprehensive Learner Record.
3.2.1
Dynamic Client Registration of a Consumer Application
Dynamic client registration [
RFC7591
] and the Authorization Code Flow [
RFC6749
] is required when the
learner is involved in the decision of what (if anything) can be shared between the Provider and
Consumer applications. The beauty of the dynamic client registration piece is that there does not need
to be a pre-established relationship shared secrets) between the Provider and Consumer applications that
take part in this interaction. Please refer to the
REST Binding
document for details.
A learner is on an application that is a CLR consumer.
They are offered the chance to bring their CLR into the consumer application.
They identify their provider server domain, and they are directed to the provider server to
authorize.
They get to the provider server and authenticate.
They see a permission grant request to grant permission to the CLR consumer application.
They grant permission and are redirected back to the CLR consumer application.
The consumer application then has the capability to pull CLRs for that learner from the provider.
3.2.2
Out-of-Band Registration of a Consumer Application
Dynamic client registration is not required for system-to-system transfer (i.e. when the learner is not
involved in the transaction). In this case, the two systems must use Client Credentials [
RFC6749
] and
may use dynamic client registration or manually exchange client credentials out-of-band. Please refer to
the
REST Binding
document for details.
3.2.3
Protecting Personally Identifiable Information
In the United States, students' personally identifiable information is protected from unauthorized
disclosure by the Family Educational Rights and Privacy Act (
FERPA
). While the Federal Law
applies to schools that receive federal funding, it is also a best practice. CLRs are educational
records that contain a student's PII in the Learner Profile. Therefore all CLR REST operations that deal
with a whole CLR must implement OAuth Authorization ([
CLR-CERT-10
]).
A CLR Assertion may contain PII in the
recipient
field, and the
getAssertion
operation does not require authorization. Therefore,
organizations that are impacted by FERPA should not use PII to identify the recipient. As a best
practice, use a UUID to identify the recipient that is not the student's
email
sourcedId
, or code>studentId in any other source of educational records. This will
prevent an unauthorization person with access to the Assertion, but without access to the CLR, from
linking the Assertion to a student.
Example
11
: Using UUID to hide recipient PII
This CLR snippet shows an Assertion recipient identified by UUID that is only used within the
learner's CLR.
Members of the learner's community using the
getAssertion
endpoint (which is public and
allows
anonymous requests) would not have access to the learner's PII unless they have access to the CLR
(which is
protected).
"type"
"Clr"
"learner"
: {
"id"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
"email"
"student@example.edu"
"sourcedId"
"abcde"
"studentId"
"12345"
},
"assertions"
: [
"recipient"
: {
"type"
"id"
"identity"
"urn:uuid:4f836af9-d79e-41c7-8add-a10995b71ccd"
3.3
Trust Model
The current relationship between the issuer/publisher, the learner, and the inspector/verifier depends on
somewhat blind trust. The CLR 1.0 model does not explicitly provide proof that people and organizations are
who they say they are. For example there is no solution yet for these two use cases:
As an inspector of a CLR, I have obtained a CLR from Publisher A which claims its profile to have a name
"BigCorp, Inc.". I know that BigCorp, Inc is a well-known company with a corporate office in New York. I
want to verify that the CLR I am viewing that claims to be published by this organization is actually
the word of this organization.
As an inspector of a CLR, I have obtained a CLR from Publisher A with an achievement record "BigSchool".
I know that BigSchool is a well-known institution of higher education in California. I want to verify
that the achievement record I am viewing that is claimed by the publisher to be issued by this
organization is actually the word of this organization.
Future versions of the CLR specification will address this issue.
3.4
Linked Data (JSON-LD)
The CLR specification uses
JSON-LD 1.0
, which is a standard for creating linked data on the web. This
enables anyone interested in linked data to understand common entities across standards and data sources.
JSON-LD enables transformations of the data, such as normalizing the exchanged data between various sources.
This is a capability of JSON-LD and associated tools and is not specific to the Comprehensive Learner Record
standard.
Although the CLR specification provides these linked data capabilities, most consumers and providers are
likely to treat the data the same way they would treat any JSON data; they do not need to do anything
special in order to accommodate the linked data.
The CLR specification also uses the
OpenAPI Specification
to describe the API. OpenAPI uses an extended subset of
JSON Schema: core definitions and terminology
to describe data formats. Some keywords are supported with
minor differences
. One of those
differences leads to two constraints on JSON-LD within the CLR specification:
Difference
type – the value must be a single type and not an array of types.
Constraints
>Arrays with one element cannot be collapsed to a JSON value type
Example
12
: Arrays with one element must not be collapsed to a value type
Given the
data
property is an
array
of type
string
, in
JSON-LD both of
these serializations are equivalent.
"data"
: [
"one"
The following serialization of the
data
array is
not
supported in
CLRs.
"data"
"one"
JSON objects cannot be collapsed to just the
@id
Example
13
: Objects must not be collapsed to just the @id
JSON-LD objects can normally be collapsed to just their
@id
if the
@id
is the URL
of the object, and both of these serializations are equivalent.
"data"
: {
"id"
"https://example.edu/data/1"
"bananas"
true
The following serialization of the
data
object is
not
supported in
CLRs.
"data"
"https://example.edu/data/1"
3.5
Additional Properties
Providers may extend many entities within the data model by simply adding properties. No special prefixing or
naming convention is required. The only requirement is that providers do not override standard properties.
note
Consumers that are not aware of the additional properties should simply ignore them.
Example
14
: Clr with additional properties
Example with two custom properties:
associatedSemesters
and
semesters
. No
special
prefixing or naming convention is required.
"type":
"Clr"
...,
"assertions"
: [
"type"
"Assertion"
...,
"associatedSemesters"
: [
"id"
"241076a3-6b15-4283-ba1f-c2729f5cc9de"
"type"
"RecordEntityLink"
"entityType"
"Basic"
"entityId"
"urn:uuid:3f0f35e2-7ed8-4f89-aa0b-326e2617a47c"
},
...
],
"achievements": [
"type"
"Achievement"
...,
"semesters"
: [
"type"
"Basic"
"id"
"urn:uuid:3f0f35e2-7ed8-4f89-aa0b-326e2617a47c"
"Name"
"Spring 2018"
...
],
},
...
Additionally, a provider may provide a JSON-LD context containing definitions of the extensions; in this
case, the provider must specify the standard context definition, and additionally list any custom JSON-LD
extensions.
Example
15
Same example of extensions as above, but providing a custom JSON-LD context. While the context is not
necessary, it may be useful for consumers who would use advanced linked data capabilities; e.g., if
using a
definition of semesters that aligns with an externally defined format.
"@context"
: [
"https://purl.imsglobal.org/spec/clr/v1p0/context/"
"https://example.org/transcript-semesters"
],
"type"
"Clr"
...,
"assertions"
: [
...,
"type"
"Assertion"
...,
associatedSemesters
: [...]
...
],
"achievements"
: {
...,
"semesters"
: [...],
3.6
Verification
Verification is the process to ensure the CLR as a whole, and the Assertions and Endorsements within a CLR
are trustworthy. Verification is distinct from 1EdTech conformance certification of applications and services
that implement this 1EdTech specification.
note
Upon receiving a CLR, applications should verify the data.
3.6.1
Verification Process
The verification process is implemented by the Consumer application. Although verification is not
required, it is highly recommended for applications with a user facing interface. The user or machine
requesting verification is called an inspector. Clrs, Assertions, and Endorsements are all verifiable if
they include a Verification object. The process of verification includes tests to ensure that:
Clrs, Assertions and Endorsements were created by the appropriate issuer/publisher Profile according
to rules declared in their Verification objects
Assertions are awarded to a valid property value of the expected recipient (for example, the
Assertion is awarded to a known email address value for email type recipient Identity object)
The Assertion, Clr, or Endorsement has not been revoked by the issuer
The Assertion, Clr, or Endorsement either has not been changed since it was issued (signed
verification) or the issuer can issue a copy of the entity during verification (hosted verification)
The Assertion issuer is authorized to award Assertions of the declared Achievement type (typically
by being the issuer of the Achievement)
The Assertion has not expired
Additional checks may ensure that:
The issuer Profile awarding the Assertion or publishing the Clr is trusted to have declared accurate
information about its identity (typically via Endorsement)
note
Since learners can self-issue (or self-publish) Assertions, Clrs, and Endorsements
(claims); inspectors should not trust self-issued claims as highly as claims asserted by trusted third
parties.
note
Issuers should make every effort to ensure their claims are verifiable for the entire
lifetime of a CLR which may be 80+ years. Signed verification is recommended for this reason.
There are two forms of verification supported in the CLR specification:
Signed
Hosted
3.6.2
Signed Verification
Issuers can sign an Assertion, Endorsement, or the Clr as a whole, and consumers can verify signed
entities without
relying on the availability of the issuer's hosting services. Signed entities can be verified long after
they are
issued, even if the issuer has ceased operations. Therefore, signed verification is
RECOMMENDED
due to
its ensured
longevity.
A signed entity is published as a Compact JSON Web Signature (JWS) [
RFC7515
]. A Compact JWS has three
components
separated by dots (.):
Example
16
: JWS Format
header
.payload
.signature
The complete JSON representation of the entity must be used as the JWS payload. The RSA-SHA256 (RS256)
signing
algorithm must be used to sign the JWS.
The CryptographicKey with the public key corresponding to the private key used to sign the entity must be
included
in the issuer Profile and should be publicly accessible via HTTP(S).
3.6.2.1
Steps to sign an entity
note
Only the issuer of an entity may sign the entity.
Starting with a fully populated entity, serialize the entity to a JSON string.
Create a Compact JWS as described in [
RFC7515
] using the JSON string as the payload and the issuer's
private key.
3.6.2.2
Steps to verify a signed entity
Base64url decode the JWS payload. This will be a JSON string representation of the entity.
Parse the decoded JWS payload into the appropriate object type (Assertion, Endorsement, or Clr).
If the parsing operation fails, the entity must be treated as unverified.
Get the trusted CryptographicKey from the issuer Profile and entity's Verification object using
these steps:
Examine the issuer's CryptographicKey available via the
publicKey
property
of the issuer Profile. If the
owner
property of the CryptographicKey does
not match the issuer Profile
id
, the CryptographicKey cannot be trusted.
Examine the entity's Verification object available via the
verification
property of the entity. Then examine the Verification object's CryptographicKey
identifier available via the
creator
property. If the identifier is present
but does not match the issuer's CryptographicKey
id
, the CryptographicKey
cannot be trusted.
If the CryptographicKey cannot be trusted, the entity must be treated an unverified.
Perform an HTTP GET request to the trusted CryptographicKey's id property. If a CryptographicKey
is returned in the response payload, use it as the trusted CryptographicKey. If the request
fails, continue using the trusted CryptographicKey embedded in the entity.
Using the
publicKey
in the trusted CryptographicKey verify the JWS. If the JWS
verification fails, the entity must be treated as unverified.
Retrieve the issuer's RevocationList from
revocationList
URL in issuer Profile if
present. If a RevocationList is returned in the response payload, and the
id
appears in the RevocationList, the entity must be treated as unverified.
If the above steps pass, the signed entity may be treated as verified.
note
Other signature suites may be included in this document later if they are
investigated and approved.
3.6.2.3
Revokeing a signed entity
To identify an entity as revoked, add an entry to the resource pointed at by the issuer's Profile
revocationList
URL with the
id
of the entity and, optionally, a reason why
the entity is being revoked.
3.6.3
Hosted Verification
Hosted verification requires the entity be hosted at a URL as a document in JSON-LD format served with
the
content-type application/ld+json and/or application/json. This document should be available without
requiring
authentication to anyone who has the entity
id
(which must be a URL). When hosted
verification is used,
this URL is the source of truth for the entity, and any verification attempt will request it to make
sure the entity
exists and describes the expected entity. Redirects are permissible as long as the appropriate content
is eventually
returned. The hosting application must properly set the content-type.
The entity
id
must be within the permitted scope for hosted verification declared in issuer
Profile.
This defaults to requiring the entity be hosted on the same origin as the issuer Profile
id
if there is
no
verification
property declared in the issuer Profile. For Assertions this rule extends
to the
Assertion's Achievement. For domain origins that host multiple applications and websites, the
startsWith
path may be used, in which case, the
verificationProperty
(e.g.
id
) must start with the value found in the issuer Profile's Verification object
startsWith
declaration.
3.6.3.1
Steps to verify a hosted entity
Verification of hosted entity may be performed starting with the entity URL or with an entity
instance in hand.
If starting with a full entity that indicates Hosted verification, the input data should only be
trusted to identify the URL (
id
) of the hosted entity document.
Perform an HTTP(S) GET request to the entity URL. If an entity is returned in the response
payload, it must be used it as the trusted entity and may be treated as verified. If the request
fails, the entity must be treated as unverified.
3.6.3.2
Revoking hosted entities
To mark a hosted entity as revoked, hosts should respond with an HTTP Status of 410 Gone. The
response may include an entity body containing some additional metadata, such as a revocationReason.
If either the 410 Gone status or a response body declaring revoked true is returned, the entity
should be treated as revoked and thus unverified.
3.7
Optional Data Validation
Certification is the process for ensuring Consumers and Providers conform to the requirements of the CLR
specification. Certification ensures they are capable of exchanging CLR data with fidelity. Certification
includes a
number of data validation checks.
The certification process includes data validation to ensure all the objects within a CLR payload conform to
the
requirements for its class:
Each object in the CLR payload is a valid JSON-LD document
Each object conforms to the JSON Schema defined by the CLR specification, including:
Each object contains all required properties for its class
Each object contains values of the expected data type for all declared properties
Consumers may validate the CLR data they received from a *certified* Provider, but this is not required.
4.
CLR in the 1EdTech Ecosystem
4.1
CASE - Competency and Academic Standards Exchange
4.1.1
When to use CLR Associations versus CASE CFAssociations
CLR Achievements can be associated by including CLR Associations in the CLR. CASE CFItems can be
associated by
including CFItemAssociations in the framework. Because CLR Achievements can be Aligned with CASE
CFItems, there are
two ways to associate CLR Achievements:
Define the associations using CLR Associations
Define the associations by aligning the achievements with CFItems and then using the
CFItemAssociations to mean the achievements are also aligned
Use #2 if the CLR Achievement and CFItem are strongly aligned (i.e. have the same meaning) and the CFItem
is already associated with other CFItems in the CASE framework. Otherwise use #1 and define the
associations in the CLR.
4.2
Learner Information Services (LIS) and OneRoster
The Comprehensive Learner Record uses a flattened version of the LIS Person model, similar to OneRoster
and LTI, and can be joined by sourcedId.
The Issuer can map to an organization within an 1EdTech specification by way of the sourcedId.
note
The LIS Person sourcedId is defined as “The globally unique identifier that has been
assigned to
the associated Person object. Each Person object must have only one sourcedId but this may be changed, any
number of times, during the object's lifetime.” [
LIS-20
4.3
Open Badges
An
Open Badges v2.0
(OB) badge is composed of an OB
Assertion
and an OB
BadgeClass
. The OB Assertion class is similar to the CLR
Assertion
class and they share many of the same properties with the
same meaning. Likewise, the OB
BadgeClass
is similar to the CLR
Achievement
class and they also share many of the same properties
with the same meaning. Two common use cases for using Open Badges and CLR together are described below.
4.3.1
As an OB Host and CLR Publisher I want to publish a collection of badges as a CLR
4.3.2
As a CLR Achievement Issuer I want to issue an Open Badge
4.3.1
As an OB Host and CLR Publisher I want to publish a collection of badges as a CLR
As an OB Host you have collected several badges for a recipient, and now you want to publish a collection of
their badges as a CLR. This can be done in two ways: convert the badges to CLR Assertions or create CLR
Assertions that link to the badges.
Convert the badges to CLR Assertions
Start with a blank
Clr
Add a
learner
CLR
Profile
based on the badge's
recipient OB
Profile
Add a
publisher
CLR Profile to represent the organization issuing the CLR.
Add a CLR
Assertion
based on each badge's OB
Assertion
Add a CLR
Achievement
based on the badge's OB
BadgeClass
Set
achievementType
property to "Badge".
Set
issuedOn
to the timestamp of when the CLR is issued.
Publish the CLR.
Include the badges without conversion
Start with a blank
Clr
Link to the Open Badge context
"https://w3id.org/openbadges/v2"
"@context"
: [
"https://purl.imsglobal.org/spec/clr/v1p0/context"
"https://w3id.org/openbadges/v2"
Add a
learner
CLR
Profile
based on the badge's
recipient OB
Profile
Add a
publisher
CLR Profile to represent the organization issuing the CLR.
Add a CLR
Assertion
for each badge's OB
Assertion
Use the badge
id
Add the "obi:Assertion"
type
"type"
: [
"Assertion"
"obi:Assertion"
Add the badge properties using compact IRIs.
"obi:BadgeClass"
: { ... }
Set
issuedOn
to the timestamp of when the CLR is issued.
Publish the CLR.
Link to the badges
Start with a blank
Clr
Add a
learner
CLR
Profile
based on the badge's
recipient OB
Profile
Add a
publisher
CLR Profile to represent the organization issuing the CLR.
Add a CLR
Assertion
based on each badge's OB
Assertion
Add a CLR
Artifact
that links to the badge. Artifacts are
added to the Assertion's
evidence
property.
Set
issuedOn
to the timestamp of when the CLR is issued.
Publish the CLR.
4.3.2
As a CLR Achievement Issuer I want to issue an Open Badge
As a CLR issuer you can issue CLR assertions, and now you also want to issue an OB badge.
Create an OB
BadgeClass
based on the CLR
Achievement
Create an OB
Assertion
based on the CLR
Assertion
Set the OB Assertion
badge
property to the OB BadgeClass defined above.
Issue the badge.
5.
Common Questions and Answers about CLR
Question
Answer
Who validates the CLR and its contents?
CLR and the Assertions and Endorsements it contains should be secure
and verified by the issuing organization. For CLRs the
publisher
is the issuer. For
Assertions and
Endorsements, the
issuer
is the issuer.
What data should go on the CLR, and is there a need for a process of petition to add things to a
CLR?
In
general, the organization or institution determines the content of a CLR. If there is a desire to
allow learners to
petition to add content, clear guidelines should be created that address what kind of content can be
added, where
the data and content originates, and how it will be noted (verified/not verified) on the CLR.
Who are the typical stakeholders for a CLR?
Student Affairs, Registrar, SEM, and/or Academic Affairs. Involved
should be all enrollment management functionalities, financial aid, marketing, academic affairs,
Registrar Office,
Student Services, Career Services, Residential Life, Co-Curricular bodies.
Should we charge for a CLR?
This decision is individualized. The business model will need to be examined. The
choice of whether to create a transactional model (where the learner requests the Comprehensive
Learner Record and
it is produced on a "per request" basis) or a model where the Comprehensive Learner Record is
"pushed" to learners
and they own the Comprehensive Learner Record and can use it as they see fit will be determined by
many factors
including revenue gain/loss, policies and practices, data systems and scalability.
Are there any things we should not put on a CLR?
The institution should determine whether achievements which
reflect personal information that may be sensitive to a learner should provide an option to include
or not to
include on a request.
Do we want to distribute the CLR in addition to the official transcript?
The CLR can be created to include what
is on the official transcript, or distributed along with the official transcript which is still the
known, verified
document among institutions of higher education and employers.
Where should the CLR be housed?
Where will learners access the CLR? There are many places such as the digital
classroom or through career service portals, but each institution will have to decide this based on
what the CLR
represents.
Who will manage questions about the CLR once it is live?
Learners and others who have access to the CLR may have
various questions once they see the document. Establishing FAQ's to be shared with those who
interact with learners
and also making known one or more point of contacts that can speak fluently about the CLR can be
beneficial.
A.
Revision History
This section is non-normative.
Version No.
Release Date
Comments
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-INFO-10]
1EdTech Comprehensive Learner Record Standard Information Model Version 1.0
. 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:
[CLR-REST-10]
1EdTech Comprehensive Learner Record Standard REST/JSON Binding Version 1.0
. 1EdTech. January 14, 2021. 1EdTech Final Release. URL:
[JSON-LD]
JSON-LD 1.0
. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 3 November 2020. W3C Recommendation. URL:
[JSON-Schema]
JSON Schema: core definitions and terminology
. K. Zyp. Internet Engineering Task Force (IETF). 31 January 2013. Internet-Draft. URL:
[OB-20]
Open Badges v2.0
. Otto, Nate; Bohrer, Jeff; Cook, Timothy; Gylling, Markus; Hripak, Alexander; Pitcher, Justin. 1EdTech Consortium. April 2018. 1EdTech Final Release. URL:
[OpenAPI]
OpenAPI Specification
. Darrell Miller; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Uri Sarid; Tony Tam; Jason Harmon. OpenAPI Initiative. URL:
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels
. S. Bradner. IETF. March 1997. Best Current Practice. URL:
[RFC6749]
The OAuth 2.0 Authorization Framework
. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL:
[rfc6750]
The OAuth 2.0 Authorization Framework: Bearer Token Usage
. M. Jones; D. Hardt. IETF. October 2012. Proposed Standard. URL:
[RFC7515]
JSON Web Signature (JWS)
. M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL:
[RFC7591]
OAuth 2.0 Dynamic Client Registration Protocol
. J. Richer, Ed.; M. Jones; J. Bradley; M. Machulak; P. Hunt. IETF. July 2015. Proposed Standard. URL:
B.2
Informative references
[CASE-IMPL-10]
1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.0: Best Practices and Implementation Guide
. 1EdTech. July 7, 2017. 1EdTech Final Release. URL:
[LIS-20]
1EdTech Learning Information Services v2.0
. L. Feng; W. Lee; C. Smythe. 1EdTech Consortium. June 2011. 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?