Skip to content

Latest commit

 

History

History
24 lines (14 loc) · 5.09 KB

33-comprehensive-learner-record-clr.md

File metadata and controls

24 lines (14 loc) · 5.09 KB

3.3: Comprehensive Learner Record (CLR)

In addition to Open Badges 3.0, the 1EdTech is also releasing an update for the partner specification Comprehensive Learner Record (CLR 2.0, see Candidate Final release). The OB and CLR specs both deal with packaging the recognition of learning achievements into Verifiable Credentials, but whereas Open Badges each describe a single achievement for a single learner, CLR packages together multiple OpenBadgeCredentials about one learner into a bundle of many achievements together, with the option to declare associations between them. An example is a transcript credential that contains individual credentials for each completed course and mastered competency as well as a final degree credential.

Just like how each Open Badges OpenBadgeCredential is digitally signed by its issuer as a Verifiable Credential, issuers may bundle together multiple related achievement credentials into transcripts and other longitudinal records for an individual learner in a CLR as a ClrCredential, which is also signed using the same technique as each individual credential. This is like a large sealed envelope that contains many other smaller sealed envelopes. Additionally, credentials can be augmented with an EndorsementCredential from a third party to lend the support of another individual or organization to the quality or relevance of an issuer or credential data.

As Edubadges begins to support OB 3.0, Edubadges will receive some requests to issue CLR 2.0 as well, but the calculation of the priority of this proposed feature will depend on more than interest among issuers. The additional complexity of bundling credentials together into a CLR represents a significant implementation and maintenance cost. As with many other decisions sketched out in this report, the ultimate value of a CLR issuing implementation would be if the places where credentials need to travel in order to have value supported CLR and got specific value out of their support for CLR.

What are possible CLR-specific benefits could SURF consider?

  • There is a high degree of expressivity with CLR to form richly connected data, and SURF partners might like the idea of giving learners an artifact of their learning that was able to capture a lot of complexity about their educational journey as an export that they might keep. Educational institutions subject to data retention policies limiting long term storage of learner data may partly address this challenge by issuing a CLR and delivering it into the custody of the learner themselves.
  • There may be synergy with other initiatives that Edubadges would address for transcript-like use cases. For example, if next year Edubadges invested heavily in implementation of Europass compatibility, that would represent a large portion of the roadmap. See the complexity and number of options similar to CLR in the European Digital Credentials guide. Subsequently, adding CLR serialization might be inexpensive because many of the user stories supporting manipulation of transcript data models would be done and all that would remain would be the JSON packaging, cryptographic signing (using the same signing already implemented for OB 3.0), and the UX to access credentials in CLR format.

What challenges would Edubadges face if it pursued CLR implementation?

  • The early implementation landscape will be skewed towards CLR issuers rather than consumers, so there are few benefits in terms of consumer access for early adopter issuers.
  • Because of the “VC within a VC” structure of ClrCredentials, only the outer layer of this credential onion is unpacked by many tools that are compatible with Verifiable Credentials yet lack consumer-side support for CLR specifically. This is also a challenge for OpenBadgeCredentials, but with a ClrCredential, so much of the meaning is conveyed only by the individual OpenBadgeCredentials within, rather than the outer layer that the basic VC level display that might only cover the credential name and the name of the issuer. A basic compatibility display of a CLR like this would result in very little of the actual data in the credential being displayed until the credential is presented to a consumer that had full-fledged CLR support.
  • It is unknown whether CLR conformance certification will require the implementation of the API component of the CLR 2.0 spec. For Open Badges, API support is an optional part of conformance. Edubadges should not highly value conformance certification. The primary value remains in the opportunities opened for learners, but the cost of implementing necessary features for conformance should be considered.
Back to Index Back to Chapter 3: The Open Badges and Digital Credentials Landscape Next Chapter 3.4: Other standards and ecosystems in development in Europe