Comprehensive Learner Record Standard Version 2.0

Candidate Final Public
Spec Version 2.0

Candidate Final Public

Document Version:	1.0.16
Date Issued:	April 29, 2024
Status:	This document is for review and adoption by the 1EdTech membership.
This version:	https://www.imsglobal.org/spec/clr/v2p0/main/
Latest version:	https://www.imsglobal.org/spec/clr/latest/main/
Errata:	https://www.imsglobal.org/spec/clr/v2p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .

The following participating organizations have made explicit license commitments to this specification:

Org name	Date election made	Necessary claims	Type
Nate Otto (Invited Expert)	July 14 2022	No	RF RAND (Required & Optional Elements)
iQ4 Corporation	June 22, 2022	No	RF RAND (Required & Optional Elements)
Arizona State University	June 21, 2022	No	RF RAND (Required & Optional Elements)
D2L	June 15, 2022	No	RF RAND (Required & Optional Elements)
Bowdoin College	June 11, 2022	No	RF RAND (Required & Optional Elements)
Temple University	June 10, 2022	No	RF RAND (Required & Optional Elements)
Unicon	June 10, 2022	No	RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

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

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

Abstract

The Comprehensive Learner Record (CLR) Standard has been designed to create, transmit, and render an individual's set of achievements, as issued by multiple learning providers, in a machine-readable format that can be curated into verifiable digital records of achievement.

1. Overview

This section is non-normative.

1.1 Audiences

The target readers for this document are:

Business Leaders - the people who are responsible for identifying the business case for using verifiable digital credentials and badges
Solution Architects - the people who are responsible for the definition and design of systems, applications, and tools that are to be used to issue, exchange, and verify digital credentials and badges
Product Developers - the people who are adding functionality to issue, exchange, and verify digital credentials

1.2 Document Set

The CLR Standard (Comprehensive Learner Record Standard) has several related documents and artifacts shown below. Together they make up the specification.

Comprehensive Learner Record Standard v2.0 ([CLR-20]) - The main CLR Standard 2.0 specification document.
Open Badges Implementation Guide v3.0 ([OB-IMPL-30]) - Provides information to lead you to successful implementation and certification of the Comprehensive Learner Record 2.0 specification.
Comprehensive Learner Record Standard Conformance and Certification Guide v2.0 ([CLR-CERT-20]) - Specifies the conformance tests and certification requirements for this standard.

1.2.1 OpenAPI 3.0 Files

The Open API Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.

-- OpenAPI Specification

1.2.2 JSON-LD Context File

When two people communicate with one another, the conversation takes place in a shared environment, typically called "the context of the conversation". This shared context allows the individuals to use shortcut terms, like the first name of a mutual friend, to communicate more quickly but without losing accuracy. A context in JSON-LD works in the same way. It allows two applications to use shortcut terms to communicate with one another more efficiently, but without losing accuracy.

Simply speaking, a context is used to map terms to IRIs. Terms are case sensitive and any valid string that is not a reserved JSON-LD keyword can be used as a term.

-- JSON-LD 1.1

The context file is available at: https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json.

1.2.3 JSON Schema

All JSON Schema can be found in § E.2 JSON Schema. JSON Schema files for credentials and API schema verification are available online:

1.3 Conformance Statements

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, NOT REQUIRED, 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.

The Conformance and Certification Guide for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

1.4 Terminology

Achievement Type: A vocabulary which describes the type of achievement.
Alignment: An alignment is a reference to an achievement definition, whether referenced in a resource outside the package or contained within the package.
Association: An association is the relationship between one assertion in a CLR has with another assertion in that CLR.
Claim: A statement about the Credential Subject. A claim may include associated evidence, results, or other metadata regarding a specific achievement, skill or assertion.
client: In a REST API, the client is the actor that initiates the DELETE, GET, or POST request. Also called a Consumer in the IMS Global Security Framework v1.1.
Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a credential.
Credential: A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. [VC-DATA-MODEL-2.0]
Credential Subject: Describes the claims being made by the Verifiable Credential. In the context of Open Badges and CLR is typically an individual but in the case of Open Badges, may be another entity type such as a course, book, or organization. Learners, Organizations and other entities can be explicit subclasses of Credential Subjects for purposes of business rules. [VC-DATA-MODEL-2.0]
Decentralized Identifiers: A type of identifier for people, organizations and any other entity, where each identifier is controlled independently of centralized registries. [DID-CORE] [DID-USE-CASES]
Digital Credential Achievement (DC Achievement): This is the content description of a credential that an assertion references. It contains metadata such as the name of the achievement, description, alignment of skills, etc. An Open Badge asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.
Digital Credential Assertion (DC Assertion): The core of both Open Badges and CLR is the assertion about achievement(s). DC Assertion properties are specific to one learner's achievement and specify metadata such as issuer, date of achievement, expiration data, as well as results and evidence that support the assertion. A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.
Evidence: Information supporting a claim such as a URL to an artifact produced by the Learner.
Issuer: A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential.
Learner: The person who is the subject of the CLR and assertions contained in a CLR.
Open Badge: A single assertion of an achievement that is packaged as a verifiable credential.
Organization: An organized group of one or more people with a particular purpose. [CEDS]
Person: A human being, alive or deceased, as recognized by each jurisdiction’s legal definitions. [CEDS]
Presentation: Data derived from one or more verifiable credentials, issued by one or more [=issuers=, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. [VC-DATA-MODEL-2.0]
Publisher: The organization or entity issuing the CLR (typically the educational institution or a 3rd-party agent). The publisher is either the issuer or has a trusted relationship with the issuer of all the assertions in the CLR.
Relying Third-Party: Also referred to as the "verifier" of a VC. This entity requests, verifies, and may consume data being presented.
REST API: A style of web API (Application Programming Interface) loosely based on HTTP methods (DELETE, GET, POST, and PUT) to access resources (e.g. CLRs) via a URL.
Result: Describes a possible achievement result. A result may contain the rubric level that was achieved.
Result Description: Describes a possible achievement result. A result description may contain a rubric.
Rich Skill Descriptor (RSD): A machine readable reference to a description of a skill located at a unique URL. [RSD]
Role: People have roles in organizations for specific periods of time. Roles are a time aware association between a person and an organization. [CEDS]
Rubric: Defines levels associated with the achievement definition (e.g. "approaches", "meets", and "exceeds").
server: In a REST API, the server is the actor that responds to a DELETE, GET, or POST request. Also called a Platform in the IMS Global Security Framework v1.1.
Skill Assertion: An assertion that contains a "skill result."
Validation: The process of assuring the verifiable credential or verifiable presentation meets the needs of the verifier and other dependent stakeholders. Validating verifiable credentials or verifiable presentations is outside the scope of this specification.
Verifiable Credential (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [VC-DATA-MODEL-2.0].
Verifiable Presentation (VP): A tamper-evident presentation of one or more Verifiable Credentials of which cryptographic verification can be used to determine the trustworthiness of the authorship of the data. [VC-DATA-MODEL-2.0].
Verification: The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.
Verifier: The entity that receives a verifiable credential or verifiable presentation and verifies the credential or presentation has not been tampered with.

1.5 Conceptual Model

This conceptual model describes CLR concepts and the relationship between those concepts. The data model in appendix § B.4 Shared Credential Data Models below is the normative reference for the classes and properties that are used to implement the concepts.

The conceptual model is targeted for all § 1.1 Audiences, while the data model is targeted for Solution Architects and Product Developers.

In the diagram below, the concepts are shown in gray boxes (e.g. Associations). Please see § 1.4 Terminology for definitions of the concepts.

Starting with this version of the CLR Standard, a CLR is also a Verifiable Credential (VC) as defined by the Verifiable Credentials Data Model v2.0 specification. The diagram includes labels that show the relationships between VC terminology and CLR terminology (e.g. Publisher is identified by the VC "issuer").

Comprehensive Learner Record (VC)

I, Publisher assert a Claim about this Credential Subject
- The claim provides the identity of the publisher, issuance date, and instructions on how to cryptographically prove the publisher identity and that the assertion and claim contents have not been tampered with since issuance.
  - The claim must describe a single credential subject which identifies the recipient of the CLR as the learner.
  - The claim must also contain a packaged set of assertions where each assertion is a DC Assertion with a definition shared by the [OB-30] and [CLR-20] standards. The issuer of each assertion may or may not be the same entity as the publisher. The recipient of each assertion must be the Learner even if the issuer uses a different identification for the learner. The publisher claims that this packaged set of assertions represents the publisher’s complete CLR for the learner at the time of issuance.
  - The claim may also contain a packaged set of DC Achievements which the publisher claims to represent a complete set of achievements that may be asserted by issuers about the learner at some time in the future.
  - The claim may also contain Associations between assertions in the CLR.

2. Use Cases

This section is non-normative.

The use cases below drive the design of the CLR Standard v2.0.

2.1 Categories

The use cases are tagged with the following categories.

Issue 1: Too many categories, or incomplete tagging

Most of these categories are not used as category tags.

Higher Education: These use cases involve transcripts and proof of degrees, continuing and profession education, and co-curricular activities in higher education.
K12: These use cases involve transcripts and co-curricular activities in primary and secondary education.
Employment: These use cases involve employers, job applicants, and LERs (Learning and Employment Records).
Training Providers: These use cases involve community colleges, technical high schools, MOOC (Massive Open Online Course) providers, and training providers such as CompTIA (the Computing Technology Industry Association), CDL (Commerical Drivers License) training providers, and OSHA (Occupational Safety and Health Administration) training providers.
Licensing and Regulatory Affairs: These use cases involve licensing and regulatory affairs, and state or federal licensing boards such as CDL issuers, CNA (Certified Nursing Assistant) issuers, workforce development organization, candidate coaching organizations, and government licensure orgs.
Military: These use cases involve training provided by a military organization, and career services provided by the military such as MilGears.
Professional Organization: These use cases involve training provided by professional organizations such as trade associations including the National Trade Association, BBB (Better Business Bureau), and SAG-AFTRA (Screen Actors Guild - American Federation of Television and Radio Artists).

2.2 Recent graduate wants to hold a copy of their own official transcript

Categories: Higher Ed, K12

Samuel is a recent graduate of Atlas University. They majored in Mechanical Engineering and received a BSE Degree. Samuel requests an official diploma and transcript issued by Atlas University to store in their VC-compatible Wallet. Samuel requests the transcript from the Registrar's Office. The Registrar issues the transcript as a CLR Verifiable Credential (CLR VC) and notifies Samuel to accept the CLR into their wallet. The CLR VC includes several Assertions including the BSE Degree and Course completions.

Goal of the Primary Actor: Samuel's goal is to hold their BSE Degree and transcript to share directly with employers or other institutions that require and need to verify their degree and/or transcript.

Preconditions for this Use Case

Altas University has implemented the CLR VC specification and been authorized to publish credentials.
Samuel has created a wallet supported by the CLR VC publisher and registered it with Altas (email address or other identifier).

Flow of Events

Samuel requests the credentials be issued by Atlas University.
Atlas issues the credentials to a known wallet user Samuel has registered.
Samuel receives a notification that a credential has been issued
Samuel logs into his wallet and is prompted to accept the credential

Post-Conditions/Success Criteria

Samuel holds his credentials on one or more wallets (web app, mobile app) and when is asked to provide any of his credentials, they are able to securely share the credential(s) through an email invitation or a direct transfer of the CLR to the validators (institution or employer) system by scanning a QR code provided by the validator and approving the credential be sent.
The credential received by the validator is validated using W3C VC and the credential(s) are accepted.

Points of Failure

CLR Publishing Engine
Wallet availability

Variations

Samuel is a recent graduate of a high school and received a diploma and transcript.
The official transcript Includes the BSE Degree and Course completions with evidence demonstrating their knowledge of concepts, and co-curricular Assertion VCs issued by Atlas University partners.

The official transcript contains pointer data toward course-related metadata such as the syllabus.

2.3 Job applicant provides proof of degree and transcript to potential employer

Categories: Higher Ed, Employment

Samuel wants to apply for a job opening at ACME Company. The job description requires proof of a degree in Mechanical Engineering and prefers that candidates provide a complete transcript. ACME Company will accept a Verifiable Presentation as evidence to accompany the job application. Samuel holds a CLR that bundles together their BSE Degree assertion and the assertions recognizing courses completed with relevant evidence. Using their wallet, Samuel creates a Verifiable Presentation that includes the Transcript CLR and attaches the VP to their job application. Horace, in HR at ACME Company uses the VP proof to verify that the VP was not corrupted, and the VC proofs to verify that the data issued by Atlas University was not corrupted as a complete transcript of Samuel's achievements at the school.

Goal of the Primary Actor: Samuel wants to prove that they have met the degree requirements for a position.

Actors

Samuel, a college graduate and job applicant
Horace, HR staff at ACME Company

Preconditions for this Use Case

Samuel holds a CLR including their degree assertion and the full transcript of assertions they received from their university for course completions, competencies, and extracurriculars.
Samuel has a VC wallet capable of presenting the CLR VC as a Verifiable Presentation. ACME Company has verifier software that can verify the VP and unpack the CLR schema and perform additional verification of each assertion it contains. This software, or its human operator, can identify the degree assertion from among the set, verify that it meets their needs, and can view and understand the other assertions included in the CLR.

Flow of Events

Samuel receives a request from ACME Company to present their credentials.
Samuel selects the CLR credential as responsive to the request.
The wallet uses Samuel's cryptographic key information to sign a VP containing the CLR VC.
The VP is transmitted to ACME Company in response to the request.
ACME's verifier software verifies the authenticity of the CLR VC, and further unpacks the individual assertions, verifying each.
The software presents the list of assertion credentials to Horace to review.
Horace confirms that the issuer is as expected, all relevant credentials are valid, and that the degree assertion is present and meets expectations. He reviews the list of courses, competencies, and extracurriculars and finds that Samuel is a well-experienced candidate.

Post-Conditions/Success Criteria

The CLR is successfully transferred to the verifier, who has verified not only the validity of the outer layer, but also of each assertion contained within.

Points of Failure

ACME's verifier and Samuel's wallet must be able to negotiate a credential request (or through some other mechanism determine how the VP should be delivered to verifier).
Samuel must be able to select the CLR credential in response to the credential request.
ACME's verifier software must be able to verify the signatures created through the mechanism chosen for the VP and the VC it contains.
ACME's verifier software must be CLR-aware, capable of unpacking and verifying the individual assertions within the CLR schema.
ACME must be able to verify that the issuer (university) is authentic.

Variations

Samuel initiates the flow by generating a VP from their wallet and transmitting it to the verifier (either through an upload form, or by email).

2.4 Job applicant provides proof of degree and specific courses/engagements from the CLR

Categories: Higher Ed, Employment

Monique wishes to apply for a job opening at CHEM pharmaceutical Company. The job description requires proof of a degree in Chemistry and successful completion of Organic Chemistry class. The student possesses their institutionally issued CLR, but wishes to submit only the Degree and the Organic Chemistry courses to the CHEM company. Using their wallet, Monique creates a CLR Verifiable Presentation that pulls the Attested Degree and Courses from their CLR transcript. Harry, in HR at CHEM Company uses the VP proof to verify that the VP was not corrupted, and the VC proofs to verify that the data issued by the institution was not corrupted. There is an indicator on the CLR to let Harry know 1) the publisher was the student, 2) the record asserted was not the entire institutional transcript, and 3) the authority behind the degree is the institution, but the authority behind the assessment in the course in the College of Arts and Sciences.

Goal of the Primary Actor: Monique wishes to apply for a job opening at CHEM pharmaceutical Company.

Actors

Monique, Job applicant
Harry, HR professional

Preconditions for this Use Case

Student possesses their institutionally issued CLR (Complete Transcript)
CLR includes the Attested Degree and Courses
CLR indicates to the verifier (employer) that the publisher was the student, the record asserted was not the entire institutional transcript, and that the authority behind the degree is the institution, but the authority behind the assessment in the course in the College of Arts and Sciences.
Student has a digital wallet or other method of curation and sharing
Student can submit a subset of their credentials (only proof of Degree and completion of Organic Chemistry courses to the CHEM company)

Flow of Events

Monique applies using her institutionally issued CLR and a digital wallet to curate and share only the two required verifiable credentials in a VP
HR verifies the VP proof to verify that the VP was not corrupted, and the VC proofs to verify that the data issued by the institution was not corrupted and see that the CLR's publisher was the student (self asserted) and the record being asserted is not the entire institutional transcript but proof of a degree and of a single course completion.

Post-Conditions/Success Criteria

HR verifies the VP proof to verify that the VP was not corrupted, and the VC proofs to verify that the data issued by the institution was not corrupted and see that the CLR's publisher was the student (self asserted) and the record being asserted is not the entire institutional transcript but proof of a degree and of a single course completion.
HR sees that the authority behind the degree is the institution and the authority behind the assessment in the course in the College of Arts and Sciences.

2.5 Higher Ed Competency-Based Education

Categories: Higher Ed, Training Providers

As a learner, I would like recognition and verification of all the credentials I acquired within the certificate, micro-credential, or degree program I attended, covering both academic and experiential learning activities I was involved in. The credentials would include the set of skills I acquired related to the degree or the certificate program I completed, the learning experiences I completed, along with the assessments carried out during my learning. The work I created for those assessments, and results of the assessments with scale and success level information should be included as evidence of my learning and skills. These achievements should be transferable so that I can continue to add upon these in my lifelong learning and be accepted by employers as proof of employability.

Goal of the Primary Actor: Learner wants to have skills-enhanced credentials that specify assessment approaches - from their academic as well as extracurricular/experiential learning represented in their CLR so they can best represent their abilities.

Actors

Learner
Issuer
Employer
Training Provider

Preconditions for this Use Case

Issuer is using digital credentials that are at least OB2 compliant and making use of Earning Criteria and Alignment properties (BadgeClass/Achievement) and Evidence class and other properties that individually cover assessment work product, including experiential learning work products versus typical objective/performance assessment result. Or Issuer is on a path to do so.

Flow of Events

Issuer designs, develops and launches degree and non-degree offerings based on market relevance and skills most sought by employers
Issuer creates and issues skills-aligned digital badges (or OB assertions within CLR assertion) for targeted achievements within the aforementioned degree and non-degree offerings
Learner receives and can share CLR, which includes all earned digital credentials and a full listing of market relevant skills for each

Post-Conditions/Success Criteria

Learner has a full record of their earned credentials with full listings of relevant skills, assessment methods, and evidence/work product (if relevant) underlying each. Potential employers and partner academic institutions can receive this same information in a CLR (web page or document) or as structured data that their internal systems can consume to support hiring efforts or admissions/articulation, respectively.

Points of Failure

Less related to technical solution, but robust coverage of assessment methods and evidence/work product per earned credential is a large commitment to Issuers operating at scale. Other failure point - if work product URL is tied to to 3rd party tool (like online portfolio), that link must persist as a dependency. Use case also calls for Issuer verification of experiential learning achievements, which can be logistically challenging when operating at scale.

2.6 Issuer Asserting All Student Achievements Comprehensively as a CLR

Categories: Higher Ed, K12

As an Issuer, I need to make a single, bulk CLR assertion for a student's full academic record with my institution. This may include degree completion and any underlying or related credentials such as courses, certificates, competencies, etc.

Goal of the Primary Actor: Assert/confer a full record for a student who has completed their program of study. Full manifest, similar to final academic transcript but also including complementary achievements that don't appear on the transcript, such as badges, competencies and skills.

Actors

Issuing organizations

Preconditions for this Use Case

Learner holds a wallet that can accept CLR credentials
Institution has implemented the CLR VC specification to publish credentials

Flow of Events

student completes program of study
issuer assets all academic achievements for this learner via a comprehensive CLR assertion
consuming system, such as LER, represents all achievements in comprehensive assertion in student's learner record
student makes achievements in record discoverable/shares
hiring managers with relevant needs discover student based on their comprehensive achievement data.

Post-Conditions/Success Criteria

All achievements in CLR assertion processed, ingested, and presentable in LER interfaces.

Points of Failure

Duplicate assertions of individual achievements, revocation

2.7 Issuer Asserting Partial Transcript at Intermediate Points in Learning Journey

Categories: Higher Ed, K12

As an Issuer that operates under a more traditional semester or term model, I need to make batch-level CLR assertions per student at the end of each semester/term to augment their record with their semester/term achievements. I will make similar assertions at the end of each semester/term until the student completes their program of study.

Goal of the Primary Actor: Update Learning and Employment Record in batches tied to my semester/term schedule.

Actors

Issuing organizations

Preconditions for this Use Case

Learner holds a wallet that can accept CLR credentials
Institution has implemented the CLR VC specification to publish credentials

Flow of Events

Learner is enrolled in multiple courses and earns achievements within them (i.e., competency-level) and at their completion
Issuer makes CLR assertion at the end of each semester/term for each learner - can consist of multiple levels of achievement including course completion and related/child achievements like certificates earned, competencies mastered
Learner wallet system for a student receives semester/term assertion and displays achievements to the student

Post-Conditions/Success Criteria

All achievements in CLR assertion processed, ingested, and presentable in LER interfaces.
Subsequent assertions (for later terms) augment the record accordingly.

Points of Failure

Duplicate assertions of individual achievements, revocation

2.8 Issuer Asserting Student Up to Date Partial Transcript of Achievements as CLR on Request

Categories: Higher Ed, K12

As an Issuer that uses a non-standard enrollment or term approach, I need to assert student achievements individually to augment their record with timely achievement/credential data as they occur, without limiting myself to using other data models/specifications or requiring my school to engineer for multiple data models. I also prefer the robustness of the CLR data model to other alternatives.

Goal of the Primary Actor: Assert achievements individually using CLR data specification to incrementally update student wallets/LERs with their achievements and credentials as soon as they are earned or on student request. Students will not have to wait until the end of each semester or program completion for their CLR-based achievements to be represented and leverage them in pursuing career goals incrementally.

Example: a student in our Cybersecurity Bachelor's program may earn CISSP certification at program midpoint and be able to gain entry-level employment in the cyber field long before completing their full degree. Incremental assertion of achievements and credentials can help enable this.

Actors

Issuing organizations

Preconditions for this Use Case

Learner holds a wallet that can accept CLR credentials
Institution has implemented the CLR VC specification to publish credentials

Flow of Events

Learner is enrolled in multiple courses and earns achievements within them (i.e., competency-level) and at their completion
Issuer makes CLR assertion for each discrete achievement as they occur or as the student requests them
Learner wallet system for a student receives semester/term assertion and displays achievements to the student

Post-Conditions/Success Criteria

individual achievement in CLR assertion processed, ingested, and presentable into learner wallet system. Subsequent assertions for later achievements augment the record accordingly.

Points of Failure

Duplicate assertions of individual achievements, revocation

2.9 Internal Organizational Staff Development and Promotion

Categories: Employment, Training Providers

As a staff member at an employer, such as a University, Pat would like recognition and verification of all the credentials they acquired within the certificate and micro-credential bearing professional development activities they have undertaken during their ten years as an employee. These include LinkedIn Learning courses, MOOCs, technical training programs like AWS Academy, and locally offered in-person training (e.g. Inclusive Hiring practices).

Goal of the Primary Actor: In pursuit of a promotion to a management position, Pat wants to submit evidence of professional growth that has occurred since graduating with their bachelor's degree 10 years ago. The job posting requires a “Masters degree or equivalent skills and experience” and Pat would like to claim qualification under the latter case.

Actors

Employee
Training Providers
Hiring manager
University HR

Preconditions for this Use Case

Credentials and evidence must be available within a CLR as individually signed VCs.

Flow of Events

Pat identifies relevant verifiable credentials from within the CLR, and packages them as a self-signed CLR
Pat transmits the self-signed CLR to the hiring manager for review.
Hiring Manager receives application materials and reviews self-signed CLR and credentials it contains
University HR verifies credential claims prior to making a job offer

Post-Conditions/Success Criteria

Pat has ability to audit verification activities against the permitted credentials
Pat has ability to revoke access privileges on demand
System has ability to set default access time frames

Points of Failure

Confidentiality of application process compromised through insufficient Identity and Access Management to CLR records.
Access permissions are not time bound and access lingers beyond the appropriate access window.

2.10 Upskilling with Higher Ed Professional/Continuing Education (via Georgia Tech - Matt Lisle)

Issue 2: This use case has not been reviewed and appears to be a functional duplicate of the above

Issue 3: This use case has not been categorized

Categories: @@@TBD

As a working professional, Jane wants to advance her career by earning a credential that proves that she has obtained specific skills.

Jane is an employee at Local Company. To increase her chances of gaining a promotion at work, she would like to earn the Advanced Problem Solving Certificate at Georgia Tech Professional Education. This certificate requires completing a series of 4 in-person courses at Georgia Tech, each of which takes approximately 2-3 days. Upon completion, Jane would like to present a printed certificate to her employer as proof of completion. She would also like to add digital micro-credentials to her digital wallet for each of the 4 short courses, and a digital credential that represents her completion of the entire 4-course program. Eventually, Jane could share her digital credentials with her employer and they would automatically be ingested into Local Company's talent management system as part of Jane's employee record. These digital records would also be verifiable and tamper-proof. However, Local Company's current systems still necessitate the printable certificate.

Goal of the Primary Actor: Jane wants to earn an Advanced Problem Solving Certificate in order to advance her career.

Actors

Jane
Georgia Tech Professional Education (GTPE)
Local Company (Jane's employer)

Preconditions for this Use Case

Jane must have a digital wallet
GTPE has a method for issuing VC-aligned CLRs
GTPE can also produce a printable certificate
Local Company has a method for verifying and ingesting VC-aligned CLRs

Flow of Events

Jane completes course 1.
Upon completion of the in-person course, a GTPE employee marks Jane as complete in the GTPE learning management system.
The GTPE learning management system presents a deep link specific to Jane that allows her to claim the credential.
Jane imports the course credential into her wallet.
As Jane progresses through the courses, GTPE updates the credential with additional achievementCredentials.
Jane's digital wallet checks for updates on the GTPE credential whenever JAnes views the credential. Her progress through the courses is pulled into the wallet from the updated credential.
Upon completing 4 courses, the GTPE SIS issues the program certificate within the same CLR.
Jane is also emailed a printable certificate (preferably in PDF format) with a unique serial number (or similar security).
Jane presents the printed certificate to her employer
Her employer manually records the certificate in Jane's employee record.
Using her digital wallet, and shares some or all of her five digital credentials with her online network and future potential employers.

(The following steps occur in a future state when Local Company's internal HR systems can ingest digital credentials)

Jane opens her digital wallet, and shares the program-level digital credential with her employer.
The employer verifies the credentials and ingests them into Jane's employee record.
When a promotion opportunity arises at Local Company, Jane is flagged as a qualified candidate due -- in part -- to her Advanced Problem Solving certificate.

Post-Conditions/Success Criteria

Jane has access to all of her credentials in her digital wallet and can decide what she shares with others.
The company can verify the credentials and consume the data so that when a promotion opportunity arises, the company can understand Jane's qualifications and trust the data without contacting the issuers of the credentials.
Jane is a candidate for promotions she wouldn't have otherwise been considered for due to the removal of friction in the system.

Points of Failure

GTPE is unable to issue a CLR
Wallet must comply with the refresh service to check for updates.
The company can't verify the issuer
The company HR systems doesn't understand digital credentials, or
Jane is unable to present a printed certificate.

2.11 Teacher Placement with a District

Categories: Employment

Sarah, a graduate of a teacher training program, wants to present my license and endorsements to a school district for potential employment.

Goal of the Primary Actor: Sarah wishes to teach Algebra I at Northwoods High School and prove her credentials are adequate.

Actors

College of education - endorser of teacher candidate for a license
State - issuer of the license
Teacher - subject of the license
District - verifier of the license

Preconditions for this Use Case

License requirements must be met by the Teacher
License must be issued with individual expressions of endorsements
The Issuing system must be capable and willing to express the data programmatically.
Verifiers must be capable and willing to consume the data programmatically.

Flow of events

University creates endorsement of candidate
Teacher applies for license
Teacher issued license
Teacher receives their license as a CLR VC with endorsements as assertions
District inspects the license
District inspects the degree
Teacher is placed in school

Post-Conditions/Success Criteria

Districts are able to quickly qualify eligible candidates
Districts have more access to licensed candidates directly matched to their job openings.

Points of Failure

inability to Issue the license and endorsements programmatically.
inability to Consume the license programmatically.
teacher's license is revoked or invalid for the position.
teacher opts-out to sharing credentials.

2.12 Professional Licensure Test Taker results

As an ETS Praxis test taker I wish to share my test results as a VC with States for issuance of a license.

Goal of the Primary Actor: Judah wants to get his teaching license in Utah to teach 3rd grade in Granite School District. He has taken the Praxis test for Elementary Education and the test for School Leadership because he may apply for a principal position in the future.

Actors

ETS Praxis Testing system
Judah
Utah State Licensure system
Granite School District Human Resource Department

Preconditions for this Use Case

ETS Praxis test passed
ETS Praxis required by the State
Specific test results are mapped to specific endorsements

Flow of events

Judah takes 2 Praxis tests and passes
Judah is issued a VC with the raw test results
State of Utah receives Judah's Praxis results
Judah meets all conditions and is issued a license.
GSD has an open position and requests a proof of Praxis score from Judah.
Judah shares the VC of his Praxis Report.
Judah employed by GSD

Post-Conditions/Success Criteria

Judah gets placed with a school district 3-6 months faster than current architecture.
no business requirements have to change to achieve this result, only technical.

Points of Failure

The school district cannot import Judah's credentials into their existing systems.

2.13 Students in Tutoring Program

Categories: K12

Sammy is a student being tutored by Terry as part of a high intensity tutoring program.

Goal of the Primary Actor: Terry's goal is to record an observation of a performance level to one or more learning objective at the beginning and end of each tutoring session.

Preconditions for this Use Case

BCPS has published learning objectives with crosswalks to state standards in CASE.
BCPS has worked with tutoring providers to implement CLR publishing to a learning ledger captured by Microsoft’s Open Education Architecture (OEA).

Flow of Events

Terry Tutor uses a Tutor Operations platform and the beginning and end of each session to record performance level associated with one or more learning objectives.
The Tutor Operations platform publishes an achievement assertion for each objective assessed to a Learning Ledger.
BCPS publishes learner profile views through secure LTI to Canvas LMS
BCPS packages and publishes sets of achievement assertions as Verifiable Credentials to parent/guardians and adult learners.

Post-Conditions/Success Criteria

Until they are 18, Sammy’s parents are able to hold all requested achievement assertions on any compliant digital wallet and control requests for access and presentation of verifiable records.
Broward College is able to verifiable Sammy’s records.

Points of Failure

CASE Server
CLR Publishing Engine
Wallet availability

Variations

Terry is a teacher, not a tutor and is using a gradebook.
Sammy is administered a test by a 3rd party group.

3. Getting Started

This section is non-normative.

3.1 Implementation Guide

The Open Badges Implementation Guide v3.0 contains non-normative information on how to implement [OB-30] and [CLR-20]. The Guide includes getting started information, best practices, key terms, and other useful inforation.

3.2 Conformance and Certification

Comprehensive Learner Record Standard Conformance and Certification Guide v2.0 - Specifies the conformance tests and certification requirements for this specification.

4. CLR Standard Document Formats

ClrCredentials can be exchanged as documents as defined in this section, or using the CLR Standard API. Documents can be exchanged as a text file, as a web resource, or embedded in an image. The contents of a CLR document MUST meet the following criteria:

The contents of the CLR document MUST represent exactly one ClrCredential
The contents MUST be serialized as JSON and JSON-LD (see § A. Serialization)
JSON exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].

4.1 File Format

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) the contents of the file MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT. The file extension SHOULD be ".jws" or ".jwt".

If an embedded proof method is used instead, the contents of the file MUST be the JSON representation of the ClrCredential. The file extension SHOULD be ".json".

4.2 Web Resource

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) the contents of the response MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT. The Content-Type SHOULD be text/plain.

If an embedded proof method is used instead, the contents of the response MUST be the JSON representation of the ClrCredential. The Content-Type SHOULD be application/json or application/ld+json.

4.3 Image Format

Comprehensive Learner Records (CLRs) may be exchanged as image files with CLRs encoded within. This allows CLRs to be portable wherever image files may be stored or displayed.

"Baking" is the process of taking a ClrCredential and embedding it into the image, so that when a user displays the image on a page, software that is CLR-aware can automatically extract that ClrCredential data and perform the checks necessary to see if a person legitimately earned the achievements within the CLR. The image must be in either [PNG] or [SVG] format in order to support baking.

4.3.1 PNGs

4.3.1.1 Baking

An iTXt chunk should be inserted into the PNG with keyword clrcredential.

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) the text value of the chunk MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT. Compression MUST NOT be used.

Example 1: An example of creating a chunk with VC-JWT proof (assuming an iTXt constructor)

var chunk = new iTXt({
  keyword: 'clrcredential',
  compression: 0,
  compressionMethod: 0,
  languageTag: '',
  translatedKeyword: '',
  text: 'header.payload.signature'
});

If an embedded proof method is used instead, the text value of the chunk MUST be the JSON representation of the ClrCredential. Compression MUST NOT be used.

Example 2: An example of creating a chunk with embedded proof (assuming an iTXt constructor)

var chunk = new iTXt({
  keyword: 'clrcredential',
  compression: 0,
  compressionMethod: 0,
  languageTag: '',
  translatedKeyword: '',
  text: '{
          "@context": [
            "https://www.w3.org/ns/credentials/v2",
            "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
            "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
            "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
          ],
          "id": "http://example.edu/credentials/3732",
          "type": ["VerifiableCredential", "ClrCredential"],
          "issuer": {
            "id": "https://example.edu/issuers/565049",
            "type": "Profile",
            "name": "Example University"
          },
          "validFrom": "2010-01-01T00:00:00Z",
          "credentialSubject": {
            "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
          },
          "proof": { }
        }'
});

An iTXt chunk with the keyword clrcredential MUST NOT appear in a PNG more than once. When baking an image that already contains credential data, the implementor may choose whether to pass the user an error or overwrite the existing chunk.

4.3.1.2 Extracting

Parse the PNG datastream until the first iTXt chunk is found with the keyword clrcredential. The rest of the stream can be safely discarded. The text portion of the iTXt chunck will either be the JSON representation of a § B.1.1 ClrCredential or the Compact JWS string that was the result of signing the ClrCredential with § 7.2 JSON Web Token Proof Format.

4.3.2 SVG

4.3.2.1 Baking

First, add an xmlns:clr attribute to the <svg> tag with the value "https://purl.imsglobal.org/clr/v2p0". Directly after the <svg> tag, add an <clr:credential> tag.

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) add a verify attribute to the <clr:credential> tag. The value of verify attribute MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT.

Example 3: An example of a well baked SVG with VC-JWT proof

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:clr="https://purl.imsglobal.org/clr/v2p0"
  viewBox="0 0 512 512">
  <clr:credential verify="header.payload.signature"></clr:credential>

  <!-- rest-of-image -->
</svg>

If an embedded proof method is used instead, omit the verify attribute, and the JSON representation of the ClrCredential MUST go into the body of the tag, wrapped in <![CDATA[...]]>.

Example 4: An example of a well baked SVG with embedded proof

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:clr="https://purl.imsglobal.org/clr/v2p0"
  viewBox="0 0 512 512">
  <clr:credential>
    <![CDATA[
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "http://example.edu/credentials/3732",
        "type": ["VerifiableCredential", "ClrCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": "Profile",
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
        },
        "proof": { }
      }
    ]]>
  </clr:credential>

  <!-- rest-of-image -->
</svg>

There MUST be only one <clr:credential> tag in an SVG. When baking an image that already contains ClrCredential data, the implementor may choose whether to pass the user an error or overwrite the existing tag.

4.3.2.2 Extracting

Parse the SVG until you reach the first <clr:credential> tag. The rest of the SVG data can safely be discarded.

5. CLR Standard API

CLRs can be exchanged using the API (application programming interface) defined here, or as documents.

This specification defines a RESTful API protocol to be implemented by applications serving in the roles of Client and Resource Server. The API uses OAuth 2.0 for authentication and granular resource-based permission scopes. Please see the Comprehensive Learner Record Standard Conformance and Certification Guide v2.0 for a list of which endpoints must be implemented for certification.

Note: Non-individual access

The API defined here is intended for Clients and servers that give individual users control over access to their resources. While system-to-system bulk transfers using OAuth 2.0 Client-Credentials Grant are expected to occur, it is out of scope for this version of the specification to define. Future versions of this specification may add explicit support for OAuth 2.0 Client-Credentials Grant.

In addition to the documentation in this section, there are OpenAPI files for the CLR Standard API in both JSON and YAML format:

5.1 Architecture

Figure 1 Diagram showing the major components of the Open Badges API

There are five key components to the API architecture.

User: This is the user that owns the resources (ClrCredentials) that are on the resource server. Also called a Resource Owner.
Web Browser: This is the web browser the user interacts with.
Client: This is the web application that interacts with the resource server on behalf of the user. Also called Consumer in the IMS Global Security Framework v1.1.
Authorization Server: This is a server that implements the OAuth 2.0 endpoints on behalf of the resource server. In many systems, the authorization server and the resource server are combined.
Resource Server: This is the server that has the protected resources (ClrCredentials). Also called Provider in the IMS Global Security Framework v1.1.

The role of each component during Registration, Obtaining Tokens, and Authenticating with Tokens are described below.

5.2 Secure REST Endpoints

These endpoints are used to exchange ClrCredentials and Profile information.

All secure endpoint requests MUST be made over secure TLS 1.2 or 1.3 protocol.

All of the Secure REST Endpoints are protected by OAuth 2.0 access tokens as described in § 6. CLR Standard API Security.

Scopes

Each endpoint requires an access token with a specific CLR Standard scope as shown below.

Operation	Scope
getCredentials	`https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly` - Permission to read ClrCredentials for the authenticated entity.
upsertCredential	`https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.upsert` - Permission to create or update ClrCredentials for the authenticated entity.
getProfile	`https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly` - Permission to read the profile for the authenticated entity.
putProfile	`https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update` - Permission to update the profile for the authenticated entity.

5.2.1 getCredentials

Get issued ClrCredentials from the resource server for the supplied parameters and access token.

Request

GET /ims/clr/v2p0/credentials?limit={limit}&offset={offset}&since={since}

Request header, path, and query parameters
Parameter	Parameter Type	Description	Required
`limit` (query)	`PositiveInteger`	The maximum number of ClrCredentials to return per page.	Optional
`offset` (query)	`NonNegativeInteger`	The index of the first ClrCredential to return. (zero indexed)	Optional
`since` (query)	`DateTime`	Only include ClrCredentials issued after this timestamp.	Optional

Responses

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`GetClrCredentialsResponse`	The set of ClrCredentials that meet the request parameters. Paging applies to the total number of ClrCredentials in the response.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 5: Sample getCredentials Request

GET /ims/clr/v2p0/credentials?limit=2&offset=0 HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json

Example 6: Sample getCredentials Response (line breaks for clarity)

HTTP/1.1 200 OK
Content-Type: application/json
X-Total-Count: 1
Link: <https://example.edu/ims/clr/v2p0/credentials?limit=2&offset=2>; rel="next",
      <https://example.edu/ims/clr/v2p0/credentials?limit=2&offset=0>; rel="last",
      <https://example.edu/ims/clr/v2p0/credentials?limit=2&offset=0>; rel="first",
      <https://example.edu/ims/clr/v2p0/credentials?limit=2&offset=0>; rel="prev"

{
  "credential": [
    {
      "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
        "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
        "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
        "https://w3id.org/security/suites/ed25519-2020/v1"
      ],
      "id": "http://example.edu/credentials/3732",
      "type": [
        "VerifiableCredential",
        "ClrCredential"
      ],
      "issuer": {
        "id": "https://example.edu/issuers/565049",
        "name": "Example University"
      },
      "validFrom": "2010-01-01T00:00:00Z",
      "credentialSubject": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "verifiableCredential": [
          {
            "@context": [
              "https://www.w3.org/ns/credentials/v2",
              "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
              "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
              "https://w3id.org/security/suites/ed25519-2020/v1"
            ],
            "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
            "type": [
              "VerifiableCredential",
              "AchievementCredential"
            ],
            "issuer": {
              "id": "https://example.edu/issuers/565049",
              "type": "Publisher",
              "name": "Example University"
            },
            "validFrom": "2010-01-01T00:00:00Z",
            "achievement": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
            "credentialSubject": {
              "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
            },
            "credentialSchema": [{
              "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
              "type": "1EdTechJsonSchemaValidator2019"
            }],
            "proof": {
              "type": "Ed25519Signature2020",
              "created": "2022-04-07T21:25:44Z",
              "verificationMethod": "did:key:undefined",
              "proofPurpose": "assertionMethod",
              "proofValue": "z2MVFHXZ8YK32d9zUfFk9hJsVNfdg3vDJsxSRqKpdaJ9T8WLAg1NcTHB91tfJrfDFkLBKtrRQFjqGkeTF3yqcz8ut"
            }
          }
        ],
        "achievement": [
          {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "creator": {
              "id": "https://example.edu/issuers/565049"
            },
            "name": "Achievement 1",
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png"
            }
          },
          {
            "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
            "creator": {
              "id": "https://example.edu/issuers/565049"
            },
            "name": "Achievement 2",
            "description": "Achievement 2",
            "image": {
              "id": "https://example.edu/achievements/sample.png"
            }
          }
        ],
        "association": [
          {
            "associationType": "isParentOf",
            "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
          }
        ]
      },
      "credentialSchema": [
        {
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }
      ],
      "proof": {
        "type": "Ed25519Signature2020",
        "created": "2022-04-07T21:25:44Z",
        "verificationMethod": "did:key:undefined",
        "proofPurpose": "assertionMethod",
        "proofValue": "zMkGPxkm3cxzEAxbjTW9MWyQEM6WZNigeoGpqA2MZhPFqotVnin6oBJSya8hqwqcFRCWMHPedDUKrn31VQGgE9BF"
      }
    }
  ],
  "compactJwsString": [
    "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy5
    3My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vZGMuaW1zZ2xvYmFsLm9yZy9kcmFmdC9
    jbHIvdjJwMC9jb250ZXh0IiwiaHR0cHM6Ly9pbXNnbG9iYWwuZ2l0aHViLmlvL29wZW5iYWRnZXMtc3B
    lY2lmaWNhdGlvbi9jb250ZXh0Lmpzb24iXSwiaWQiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGl
    hbHMvMzczMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJDbHJDcmVkZW50aWFsIl0sIml
    zc3VlciI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXh
    hbXBsZSBVbml2ZXJzaXR5In0sImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiY3J
    lZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmV
    jMjEiLCJhc3NlcnRpb25zIjpbImV5SmhiR2NpT2lKU1V6STFOaUlzSW5SNWNDSTZJa3BYVkNKOS5leUo
    yWXlJNmV5SkFZMjl1ZEdWNGRDSTZXeUpvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZ
    rWlc1MGFXRnNjeTkyTVNJc0ltaDBkSEJ6T2k4dmFXMXpaMnh2WW1Gc0xtZHBkR2gxWWk1cGJ5OXZjR1Z
    1WW1Ga1oyVnpMWE53WldOcFptbGpZWFJwYjI0dlkyOXVkR1Y0ZEM1cWMyOXVJbDBzSW1sa0lqb2lkWEp
    1T25WMWFXUTZPVEUxTXpka1ltRXROVFpqWWkweE1XVmpMV0ptTmpNdE1ESTBNbUZqTVRNd01EQXlJaXd
    pZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNJc0lrRnpjMlZ5ZEdsdmJrTnlaV1J
    sYm5ScFlXd2lYU3dpYVhOemRXVnlJanA3SW1sa0lqb2lhSFIwY0hNNkx5OWxlR0Z0Y0d4bExtVmtkUzl
    wYzNOMVpYSnpMelUyTlRBME9TSXNJblI1Y0dVaU9pSlFkV0pzYVhOb1pYSWlMQ0p1WVcxbElqb2lSWGh
    oYlhCc1pTQlZibWwyWlhKemFYUjVJbjBzSW1semMzVmhibU5sUkdGMFpTSTZJakl3TVRBdE1ERXRNREZ
    VTURBNk1EQTZNREJhSWl3aVlXTm9hV1YyWlcxbGJuUWlPaUoxY200NmRYVnBaRHBrWkRnNE4yWXdZUzA
    xTm1OaUxURXhaV010WW1ZMk15MHdNalF5WVdNeE16QXdNRElpTENKamNtVmtaVzUwYVdGc1UzVmlhbVZ
    qZENJNmV5SnBaQ0k2SW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01USmxZbU0yWmpGak1qYzJaVEV
    5WldNeU1TSjlMQ0pqY21Wa1pXNTBhV0ZzVTJOb1pXMWhJanBiZXlKcFpDSTZJbWgwZEhCek9pOHZjSFZ
    5YkM1cGJYTm5iRzlpWVd3dWIzSm5MME5zY2tOeVpXUmxiblJwWVd3dWFuTnZiaUlzSW5SNWNHVWlPaUp
    LYzI5dVUyTm9aVzFoVm1Gc2FXUmhkRzl5TWpBeU1DSjlYWDBzSW1semN5STZleUpwWkNJNkltaDBkSEJ
    6T2k4dlpYaGhiWEJzWlM1bFpIVXZhWE56ZFdWeWN5ODFOalV3TkRraUxDSjBlWEJsSWpvaVVIVmliR2x
    6YUdWeUlpd2libUZ0WlNJNklrVjRZVzF3YkdVZ1ZXNXBkbVZ5YzJsMGVTSjlMQ0p1WW1ZaU9qRXlOakl
    6TURRd01EQXNJbXAwYVNJNkluVnlianAxZFdsa09qa3hOVE0zWkdKaExUVTJZMkl0TVRGbFl5MWlaall
    6TFRBeU5ESmhZekV6TURBd01pSXNJbk4xWWlJNkltUnBaRHBsZUdGdGNHeGxPbVZpWm1WaU1XWTNNVEp
    sWW1NMlpqRmpNamMyWlRFeVpXTXlNU0o5Lk9idmlwaTNyTVVvbWZHaEZwTlZ1WVk5ekpXVUtVSTg2SXJ
    ZRlRtNDdScDJSc1hGYUlBYXJHZlE4X3ZVS0R1RVh0MDRma1liQUpxVno1UGhrYkpUTlZULWtGMXpWaXV
    vdUNucXIwN1gzYmZfb2U0RUxKN2FEVXp6N2hKdEpKdmdCTzVlYzFSN3ZHVnBMc0kwYm1sbFlNVlFzeEs
    xejFQS3lGdEFTTDM0WUo1N3NwQkVzbE1RNEc2RENiRTZOSktPM2lqZk1LTUxkT2RPbHVnb3hINjVyQnp
    nWlRxWlI0RkMwbXpmWHJGQUhFeVFqdktlMHFJdWJLbjJsV3FKRTFNbDg5SDRSX3dzenFHTEtIOWpSdVJ
    VcEE0REp5ZFd4Z0xSbjhTYXJSRl9WUWoxaktsdjNCWTZuUEtGSjN0VF81ZXBrUmQxQnF0MG94UHJhQjJ
    UVzg1aFNuUSJdLCJhY2hpZXZlbWVudHMiOlt7ImlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0xMWV
    jLWJmNjMtMDI0MmFjMTMwMDAyIiwiY3JlYXRvciI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXN
    zdWVycy81NjUwNDkifSwibmFtZSI6IkFjaGlldmVtZW50IDEiLCJkZXNjcmlwdGlvbiI6IkFjaGlldmV
    tZW50IDEiLCJpbWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL3NhbXB
    sZS5wbmcifX0seyJpZCI6InVybjp1dWlkOmRkODg3ZjBhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDA
    wMiIsImNyZWF0b3IiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5In0sIm5
    hbWUiOiJBY2hpZXZlbWVudCAyIiwiZGVzY3JpcHRpb24iOiJBY2hpZXZlbWVudCAyIiwiaW1hZ2UiOns
    iaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2FjaGlldmVtZW50cy9zYW1wbGUucG5nIn19XSwiYXNzb2N
    pYXRpb25zIjpbeyJhc3NvY2lhdGlvblR5cGUiOiJpc1BhcmVudE9mIiwic291cmNlSWQiOiJ1cm46dXV
    pZDphNzQ2N2VmNi01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJ0YXJnZXRJZCI6InVybjp1dWl
    kOmRkODg3ZjBhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMiJ9XX0sImNyZWRlbnRpYWxTY2hlbWE
    iOlt7ImlkIjoiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvQWNoaWV2ZW1lbnRDcmVkZW50aWFsLmp
    zb24iLCJ0eXBlIjoiSnNvblNjaGVtYVZhbGlkYXRvcjIwMjAifV19LCJpc3MiOnsiaWQiOiJodHRwczo
    vL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJ
    uYmYiOjEyNjIzMDQwMDAsImp0aSI6Imh0dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiw
    ic3ViIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.hb_qNMd6nQBU9T0
    0ohxvQDJ95kcnPRd_RMZqvpvsgCqvzIzXV1HV1wZ7mxNkaIlNim-JA1MgFlh3C1I_s2iGRBn9jSZAHvT
    JGyhiU_80Jhi1R8K2BymlB3T3o3_g0waCrsSIoAcN6NFnpDCR4Taop_JCBoC8msDG4qKskq0wEDYhR3N
    09qvdl1kkJVmFJNc0R_5QK54kIk8YEzeClgo3ceh4q7ooPBRvfduehYButLZkhy3rQP9Y8kIyCMvrhL9
    5FwlnEeIY3YVz52qlhrk_SXMX6e-pKY-beqcJa_i0AS_ZG6iz6bN0T99UOd9coczJDt6nzr5B2P8Iz6c
    IcZmx2A"
  ]
}

5.2.2 upsertCredential

Create or replace a ClrCredential on the resource server, appending it to the list of credentials for the subject, or replacing an existing entry in that list. The resource server SHOULD use the credential equality and comparison algorithm to compare and determine initial equality. The response code makes clear whether the operation resulted in a replacement or an insertion.

Note

This specification does not dictate the behavior of Hosts in the cases where the submitted credential is older than or the same as the existing one according to the credential equality and comparison algorithm.

Request

POST /ims/clr/v2p0/credentials

Allowed request content types
Content-Type Header	Content Type	Content Description	Content Required
application/json	`ClrCredential`	If the ClrCredential is not signed with the VC-JWT Proof Format, the request body MUST be a ClrCredential and the `Content-Type` MUST be `application/json`.	Required
text/plain	`CompactJws`	If the ClrCredential is signed with the VC-JWT Proof Format, the request body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required

Responses

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`ClrCredential`	The ClrCredential was successfully replaced on the resource server. The response body MUST be the ClrCredential in the request. If the ClrCredential is not signed with the VC-JWT Proof Format, the response body MUST be a ClrCredential and the `Content-Type` MUST be `application/json`.	Required
200	text/plain	`CompactJws`	The ClrCredential was successfully replaced on the resource server. The response body MUST be the ClrCredential in the request. If the ClrCredential is signed with the VC-JWT Proof Format, the response body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required
201	application/json	`ClrCredential`	The ClrCredential was successfully created on the resource server. The response body MUST be the ClrCredential in the request. If the ClrCredential is not signed with the VC-JWT Proof Format, the response body MUST be a ClrCredential and the `Content-Type` MUST be `application/json`.	Required
201	text/plain	`CompactJws`	The ClrCredential was successfully created on the resource server. The response body MUST be the ClrCredential in the request. If the ClrCredential is signed with the VC-JWT Proof Format, the response body MUST be a CompactJws string and the `Content-Type` MUST be `text/plain`.	Required
304	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 7: Sample upsertCredential Request

POST /ims/clr/v2p0/credentials
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json
Content-Type: application/json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://w3id.org/security/suites/ed25519-2020/v1"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": "Publisher",
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "achievement": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
        },
        "credentialSchema": [{
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }],
        "proof": {
          "type": "Ed25519Signature2020",
          "created": "2022-04-07T21:25:44Z",
          "verificationMethod": "did:key:undefined",
          "proofPurpose": "assertionMethod",
          "proofValue": "z2MVFHXZ8YK32d9zUfFk9hJsVNfdg3vDJsxSRqKpdaJ9T8WLAg1NcTHB91tfJrfDFkLBKtrRQFjqGkeTF3yqcz8ut"
        }
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "creator": {
          "id": "https://example.edu/issuers/565049"
        },
        "name": "Achievement 1",
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "creator": {
          "id": "https://example.edu/issuers/565049"
        },
        "name": "Achievement 2",
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png"
        }
      }
    ],
    "association": [
      {
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-04-07T21:25:44Z",
    "verificationMethod": "did:key:undefined",
    "proofPurpose": "assertionMethod",
    "proofValue": "zMkGPxkm3cxzEAxbjTW9MWyQEM6WZNigeoGpqA2MZhPFqotVnin6oBJSya8hqwqcFRCWMHPedDUKrn31VQGgE9BF"
  }
}

Example 8: Sample upsertCredential Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://w3id.org/security/suites/ed25519-2020/v1"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": "Publisher",
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "achievement": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "proof": {
          "type": "Ed25519Signature2020",
          "created": "2022-04-07T21:25:44Z",
          "verificationMethod": "did:key:undefined",
          "proofPurpose": "assertionMethod",
          "proofValue": "z2MVFHXZ8YK32d9zUfFk9hJsVNfdg3vDJsxSRqKpdaJ9T8WLAg1NcTHB91tfJrfDFkLBKtrRQFjqGkeTF3yqcz8ut"
        }
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "creator": {
          "id": "https://example.edu/issuers/565049"
        },
        "name": "Achievement 1",
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "creator": {
          "id": "https://example.edu/issuers/565049"
        },
        "name": "Achievement 2",
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png"
        }
      }
    ],
    "association": [
      {
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-04-07T21:25:44Z",
    "verificationMethod": "did:key:undefined",
    "proofPurpose": "assertionMethod",
    "proofValue": "zMkGPxkm3cxzEAxbjTW9MWyQEM6WZNigeoGpqA2MZhPFqotVnin6oBJSya8hqwqcFRCWMHPedDUKrn31VQGgE9BF"
  }
}

5.2.3 getProfile

Fetch the profile from the resource server for the supplied access token. Profiles that are received MAY contain attributes that a Host SHOULD authenticate before using in practice.

Request

GET /ims/clr/v2p0/profile

Responses

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`Profile`	The matching profile.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 9: Sample getProfile Request

GET /ims/clr/v2p0/profile HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json

Example 10: Sample getProfile Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "@context": [
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University"
}

5.2.4 putProfile

Update the profile for the authenticate entity.

Request

PUT /ims/clr/v2p0/profile

Allowed request content types
Content-Type Header	Content Type	Content Description	Content Required
application/json	`Profile`	The request MUST include the entire Profile object. The resource server MAY respond with 400 BAD_REQUEST to reject data that is known immediately to not be acceptable by the platform, e.g. to reject a "telephone" property if the resource server cannot validate telephone numbers.	Required

Responses

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`Profile`	The matching profile. Successful request responses will be the same as GET Profile and may not include the patched values (as the resource server may be waiting for asynchronous processes to complete before accepting the value). The values may never become part of the published profile.	Required
202	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has been accepted for processing, but the processing has not been completed.	Required
304	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 11: Sample putProfile Request

PUT /ims/clr/v2p0/profile HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json
Content-Type: application/json

{
  "@context": [
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University",
  "phone": "111-222-3333"
}

Example 12: Sample putProfile Response

{
  "@context": [
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
  ],
  "type": "Profile",
  "id": "https://example.edu/issuers/565049",
  "name": "Example University",
  "phone": "111-222-3333"
}

5.3 Service Discovery Endpoint

Access to the discovery endpoint MUST NOT be protected. The Service Description Document (SDD) MUST be provided over HTTPS with TLS 1.2 or 1.3.

5.3.1 getServiceDescription

Fetch the Service Description Document from the resource server.

Request

GET /ims/clr/v2p0/discovery

Responses

Allowed response codes and content types
Status Code	Content-Type Header	Content Type	Content Description	Content Required
200	application/json	`ServiceDescriptionDocument`	The service discovery document.	Required
404	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.	Required
400	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server cannot or will not process the request due to something that is perceived to be a client error.	Required
401	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the request has not been applied because it lacks valid authentication credentials for the target resource.	Required
403	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server understood the request but refuses to fulfill it. The exact reason SHOULD be explained in the response payload.	Required
405	application/json	`Imsx_StatusInfo`	As defined in [rfc9110], indicating that the server does not allow the method.	Required
500	application/json	`Imsx_StatusInfo`	As defined in [rfc9110]. Implementations SHOULD avoid using this error code - use only if there is catastrophic error and there is not a more appropriate code.	Required
DEFAULT	application/json	`Imsx_StatusInfo`	The request was invalid or cannot be served. The exact error SHOULD be explained in the response payload.	Required

Example 13: Sample getServiceDescription request

GET /ims/clr/v2p0/discovery HTTP/1.1
Host: example.edu
Accept: application/json

Example 14: Sample getServiceDescription response

HTTP/1.1 200 OK
Content-Type: application/json

...
"components": {
    "securitySchemes": {
        "OAuth2ACG": {
            "type": "oauth2",
            "description": "OAuth 2.0 Authorization Code Grant authorization",
            "x-imssf-name": "Example Provider",
            "x-imssf-privacyPolicyUrl": "provider.example.com/privacy",
            "x-imssf-registrationUrl": "provider.example.com/registration",
            "x-imssf-termsOfServiceUrl": "provider.example.com/terms",
            "flows": {
                "authorizationCode": {
                    "tokenUrl": "provider.example.com/token",
                    "authorizationUrl": "provider.example.com/authorize",
                    "refreshUrl": "provider.example.com/token",
                    "scopes": {
                        "https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly" : "...",
                        "https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.upsert" : "..."
                        "https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly" : "...",
                        "https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update" : "..."
                    }
                }
            }
        }
    },
    "schemas": {
        ...
    }
}
...

5.4 Paging

Pagination of getCredentials results is controlled by two query string parameters appended to the request. The response includes the following pagination headers.

Response Header	Description	Required
`X-Total-Count: <total_count>`	The resource server MUST include an `X-Total-Count` response header if the total result count is known. If the total result count is not known, the total count header MUST be ommitted.	Conditionally Required for `200 OK` Response
`Link: <pagination_links>`	The resource server MUST include a `Link` response header if the list of credentials in the response is incomplete; and MAY include the `Link` header if the response is complete.	Conditionally Required for `200 OK` Response

If present, the Link header MUST support all of the following link relations (rel values):

Relation	Description
next	The link relation for the immediate next page of results. This MUST appear when the current list response is incomplete.
last	The link relation for the last page of results. This MUST always appear.
first	The link relation for the first page of results. This MUST always appear.
prev	The link relation for the immediate previous page of results. This MUST appear when the offset is greater than zero.

5.5 Retry Behavior

Resource Servers MAY implement a Retry-After header to indicate a period of time to wait before attempting the request again.

If no Retry-After header is present and the response is non-2XX, it is recommended to retry the request in 30 minutes for an additional two attempts. After which, it MAY be desirable to alert the user that there is an issue with the connection (e.g. perhaps they need to reauthenticate or manually trigger the request when they believe services are back up).

6. CLR Standard API Security

The CLR Stardard API endpoints must use the methods outlined in Section 4, "Securing Web Services" of the IMS Global Security Framework v1.1. Clients and servers that give individual users control over access to their resources MUST use the OAuth 2.0 Authorization Code Grant method. A partial list of examples are shown in the table below:

Example	Grant Method to Use
A university system maintains an achievement hub that students and alumni can use to retrieve their personal extended transcript. One of the students is using a digital wallet to assemble a personal portfolio. The student uses the wallet application to get their extended transcript from the university system's achievement hub. The client is the wallet application and the server is the achievement hub.	OAuth 2.0 Authorization Code Grant because the learner is accessing their own individual resources.
A learner has used a digital wallet to assemble a comprehensive record of their achievements. The learner uses the wallet application to "submit" their CLR to a potential employer. The client is the wallet application and the server is the employer's career tracking system.

Example

Grant Method to Use

A university system maintains an achievement hub that students and alumni can use to retrieve their personal extended transcript. One of the students is using a digital wallet to assemble a personal portfolio. The student uses the wallet application to get their extended transcript from the university system's achievement hub. The client is the wallet application and the server is the achievement hub.

OAuth 2.0 Authorization Code Grant because the learner is accessing their own individual resources.

A learner has used a digital wallet to assemble a comprehensive record of their achievements. The learner uses the wallet application to "submit" their CLR to a potential employer. The client is the wallet application and the server is the employer's career tracking system.

Note: Non-individual access

6.1 Using OAuth 2.0 Authorization Code Grant

In scenarios where the learner or another third party is the resource owner, there will not be a pre-established trust relationship. Therefore the client credentials approach is insufficient. Instead you MUST use of OAuth 2.0 Authorization Code Grant.

Making a secured CLR Standard API request using authorization code grant comprises three steps:

§ 6.1.1 ACG - Registration - Share configuration information between the client and the server.
§ 6.1.2 ACG - Obtaining Tokens - Obtain an authorization code using a choreography between the client, web browser, user, and authorization server. Then request an access token by sending a request, using the previously obtained authorization code, to the Access Token service endpoint.
§ 6.1.3 ACG - Authenticating with Tokens - Use the access token in the Authorization header of the API request

6.1.1 ACG - Registration

To get started, the client and authorization server must share the four pieces of information shown below. Clients and servers that implement the Authorization Code Grant (ACG) method of resource access MUST implement § 6.4 Dynamic Client Registration to share this information.

client_id: This is the public identifier for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.
client_secret: This is the shared secret for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.
List of Scopes: The list of scopes that identify the set of endpoints for which access permission is being requested.
OAuth 2.0 Access Token Service Endpoint: The endpoint from which the approved, requesting client can obtain an access token.

If the client and authorization server support Token Revocation, they should also share:

OAuth 2.0 Revocation Service Endpoint: The endpoint a client can use to revoke an access token.

6.1.2 ACG - Obtaining Tokens

Figure 2 Sequence diagram for obtaining access tokens when using the ACG flow

Obtaining an access token using an authorization code has two steps:

First obtain an authorization code using a choreography between the client, web browser, user, and authorization server - § ACG - Authorization Request
Then request an access token using the authorization code - § ACG - Access Token Request

Once obtained, the client can freely re-use the access token up until the token's expiry time, so that the client need not repeat steps of obtaining an authorization code and requesting an access token for every API request. Token refresh is also available (see § Token Refresh Request).

ACG - Authorization Request

After the client application is registered with the authorization server as described in § 6.4 Dynamic Client Registration, the client application then MAY initiate an authorization request as described in Section 4.2 of the IMS Global Security Framework v1.1 by redirecting the user to the authorizationUrl as declared in the resource server's Service Description Document (SDD).

In the OAuth 2.0 Security Best Practices document [OAUTH2-SBP] the use of Proof Key for Code Exchange (PKCE) [RFC7636] is recommended in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response. When using 1EdTech specifications, PKCE MUST be used to protect Authorization Code Grant based access. The PKCE has two stages:

First the client MUST supply a code_challenge and code_challenge_method in the request for an authorization code. The authorization server is responsible for associating the code_challenge with the issued authorization code.
Then the client MUST supply the code_verifier in the Access Token Request, and the authorization server verifies the code_verifier.

Parameter Name	Type	Description	Required
`response_type`	String	Value MUST be set to "code".	Required
`client_id`	String	The client application identifier. MUST be the `client_id` provided in the Dynamic Client Registration § Register with Authorization Server response.	Required
`redirect_uri`	URL	The client application's redirection endpoint. MUST match one of the `redirect_uris` in the § 6.1.1 ACG - Registration request. Although this is optional in the IMS Global Security Framework v1.1, it is REQUIRED by this specification.	Required
`scope`	String	The scope of the authorization request. The authorization server is responsible for validating the scopes identified in the request and the response MUST include a scope parameter which confirms this list or comprises a subset of the services requested.	Required
`state`	String	An opaque value used by the client application to maintain state between the request and callback. The authorization server includes this value when redirecting the web browser back to the client. This parameter MUST be used for preventing cross-site request forgery.	Required
`code_challenge`	String	This is BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).	Required
`code_challenge_method`	String	This MUST have a value of "S256" to indicate the SHA256 code verifier transformation method is used.	Required

All of the authorization request parameters are encoded in the authorization request as query string parameters. The request MUST be made by redirecting the browser to the OAuth 2.0 Authorization endpoint. The request MUST use HTTPS with TLS 1.2 or 1.3 protocol.

Example 15: Sample ACG authorization request (line breaks for clarity)

HTTP/1.1 302 Found
Location: https://auth.example.com/authorize?
    client_id=4ad36680810420ed
    &response_type=code
    &scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fclr%2Fv2p0%2Fscope%2Fcredential.readonly%20offline_access
    &redirect_uri=https%3A%2F%client.example.com%2FAuthorize
    &state=26357667-94df-4a14-bcb1-f55449ddd98d
    &code_challenge=XeDw66i9FLjn7XaecT_xaFyUWWfUub02Kw118n-jbEs
    &code_challenge_method=S256

ACG - Authorization Response

If the redirect_uri matches a known client_id, the authorization server SHOULD present a UI asking the user to authenticate themself and grant the access request. The authorization server SHOULD display the client_name, client_uri, logo_uri, tos_uri, and policy_uri collected during Dynamic Client Registration to the user to help them decide whether to grant the access request.

If the user authorizes the client application to access their resources with the requested scopes, the authorization server MUST redirect the browser back to the redirect_uri with the code, scope, and state query string parameters.

The Authorization Code MUST be used only once. A lifetime for the authorization code of 600 seconds (10 minutes) is RECOMMENDED. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

Parameter Name	Type	Description	Required
`code`	String	The authorization code.	Required
scope	String	The authorized scope for the access request (this MAY be a subset of the scopes in the request). The value is a space delimited set of scopes.	Required
state	String	The opaque value supplied by the client to maintain state between the request and callback.	Required

Example 16: Sample ACG authorization response (line breaks for clarity)

HTTP/1.1 302 Found
Location https://client.example.com/Authorize?
    code=dcf95d196ae04d60aad7e19d18b9af755a7b593b680055158b8ad9c2975f0d86
    &scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fclr%2Fv2p0%2Fscope%2Fcredential.readonly%20offline_access
    &state=26357667-94df-4a14-bcb1-f55449ddd98d

Authorization Error Response

If the authorization server does not recognize the client applications's redirection endpoint from a prior connection with this client application, the authorization server SHOULD inform the user of the error and MUST NOT automatically redirect to the web browser to the invalid redirection URI.

If the user denies the authorization request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI.

Parameter Name	Type	Description	Required
`error`	AuthorizationError	A single ASCII [RFC20] error code from the AuthorizationError vocabulary.	Required
`error_description`	String	Human-readable ASCII [RFC20] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
`error_uri`	URI	A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.
`state`	String	The opaque value supplied by the client to maintain state between the request and callback.	Required

Example 17: Sample authorization error response

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

ACG - Access Token Request

With the supplied code, the client application SHOULD attempt to exchange the code for an access_token. The client application makes an authorization grant POST request to the tokenUrl as declared in the resource server's Discovery Document. The HTTP POST request MUST include a Basic authorization header with the client_id and client_secret provided in the registration response. The body of the token request MUST include the following form fields:

Field Name	Type	Description	Required
`grant_type`	String	Value MUST be set to "authorization_code".	Required
`code`	String	The authorization code received from the authorization server.	Required
`redirect_uri`	URL	The client application's redirection endpoint.	Required
`scope`	String	The scope of the access request.	Required
`code_verifier`	String	The PKCE code verifier.	Required

Example 18: Sample ACG token request (line breaks for clarity)

POST /token HTTP/1.1
Host: auth.example.com
Authorization: Basic NDE2ZjI1YjhjMWQ5OThlODoxNWQ5MDA4NTk2NDdkZDlm
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
    &code=7c7a73263ee14b2b48073d0615f286ec74f6636689046cb8dbede0b5e87a1338
    &redirect_uri=https%3A%2F%client.example.com%2FAuthorize
    &scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fclr%2Fv2p0%2Fscope%2Fcredential.readonly+offline_access
    &code_verifier=mYUQfKNgI1lSbY8EqtvNHLPzu0x%2FcVKO3fpWnX4VE5I%3D

ACG - Access Token Response

If the authorization server grants this request (see Section 5.1 in [RFC6749] for the detailed description), it returns HTTP 200 OK status code with content type "application/json" consisting of a JSON object containing the access token and its expiry lifetime (1EdTech recommends a default expiry lifetime of 3600 seconds, one hour, for access tokens), optionally a refresh token, and confirms the set of scopes supported by the access token:

Property Name	Type	Description	Required
`access_token`	String	The access token issued by the authorization server.	Required
`token_type`	String	The type of the token issued. The case insensitive value MUST be "bearer".	Required
`scope`	String	The scope of the access token. This is a space-separated list of scopes.	Required
`expires_in`	PositiveInteger	The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. 1EdTech recommends a default expiry lifetime of 3600 seconds, one hour, for access tokens. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.	Optional
`refresh_token`	String	The refresh token, which can be used to obtain new access tokens using the same authorization grant as described in § Token Refresh Request.	Optional

Example 19: Sample ACG token response

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, max-age=0
Pragma: no-cache
Content-Type: application/json; charset=UTF-8

{
    "access_token": "863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92",
    "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
    "expires_in": 3600,
    "token_type": "Bearer",
    "scope": "https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly offline_access"
}

Access Token Error Response

The authorization server MAY decide not to issue an access token. This could be because the request scopes are invalid, the credentials from the client may be invalid, etc. In this case the authorization server MUST return an HTTP 400 Bad Request status code with content type "application/json" consisting of a JSON object describing the error in the response body. The properties used to describe the error are:

Property Name	Type	Description	Required
`error`	TokenError	A single ASCII [RFC20] error code]. See Section 5.2 of [RFC6749].	Required
`error_description`	ASCIIString	Human-readable ASCII [RFC20] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.	Optional
`error_uri`	URI	A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.	Optional

Example 20: Sample access token error response

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "error": "invalid_request"
}

6.1.3 ACG - Authenticating with Tokens

After obtaining an access_token and optionally a refresh_token using the method above, a client application MAY issue request that access resources controlled by the user on the resource server using the access_token in the HTTP Authorization header [RFC2617] with a Bearer Token [RFC6750]. For example, a "getCredentials" would look like this:

Example 21: Sample getCredentials request

GET ims/clr/v2p0/credentials
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/ld+json

6.2 Token Refresh

The recommended value of the access token's expires_in attribute is 3600 i.e. one hour. This means that the validity of the access token expires one hour after the time it was issued.

When requesting an access token as part of the Authorization Code Grant process, an authorization server MAY return a 'Refresh Token'. The refresh token can be used to obtain an access token using the same authorization grant: this is described in Section 6 of [RFC6749]. The use of the Refresh Token avoids the choreography for obtaining the credentials to gain access to the authorization server.

An Authorization Server is NOT REQUIRED to support token refresh.

Token Refresh Request

If the access_token is expired or about to expire, and the client application received a refresh_token, the client application can use OAuth 2.0 Token Refresh to get a new access_token and refresh_token.

The client makes a refresh POST request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body:

Parameter Name	Type	Description	Required
`grant_type`	String	Value MUST be set to "refresh_token".	Required
`refresh_token`	String	The refresh token issued to the client.	Required
`scope`	String	The scope of the access request. The requested scope MUST NOT include any scope not originally granted by the user, and if omitted is treated as equal to the scope originally granted by the user.	Required

Example 22: Sample ACG token refresh request

POST /token HTTP/1.1
Host: auth.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fclr%2Fv2p0%2Fscope%2credential.readonly

Token Refresh Response

If valid and authorized, the authorization server issues a new access token and optionally a new refresh token as described earlier in § ACG - Access Token Response. If the request failed verification or is invalid, the authorization server returns an error response as described earlier in § Access Token Error Response.

6.3 Token Revocation

There may be deployments in which revocation of an access token is useful. The Token Revocation process is based upon [RFC7009]. The client requests the revocation of a particular token by making an HTTP POST request (using TLS) to the token revocation endpoint URL. Note that [RFC7009] states that implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens.

Token Revocation Request

The client constructs the request by including the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body:

Parameter Name	Type	Description	Required
`token`	String	The token that the client wants to get revoked.	Required
`token_type_hint`	String	MUST be set to either "access_token" or "refresh_token".	Required

Example 23: Sample token revocation request

POST /revoke HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

Token Revocation Response

The authorization server responds with HTTP 200 OK status code if the token has been revoked successfully or if the client submitted an invalid token.

When the request for revocation is rejected, the authorization server returns an error response as described earlier in § Access Token Error Response with an error code of "unsupported_token_type".

6.4 Dynamic Client Registration

Clients and servers that implement the Authentication Code Grant (ACG) method of resource access MUST implement the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. There are two steps in this process:

Request the Service Description Document (SDD) from the resource server
Register with the authorization server

Sequence diagram for registration when using ACG flow — Figure 3 Sequence diagram for dynamic client registration when using ACG flow

The client only needs to register a client_id with the authorization server once. Each user will use the same client_id when they request their own authorization code.

Request the Service Description Document

To start the registration process, the user supplies the client with the resource server's base URL. When presented with an unknown resource server the client MUST request the resource server's Service Description Document (SDD) as shown in § 5.3.1 getServiceDescription.

Upon receiving a SDD from a resource server, the client SHOULD respect the Cache-Control and Expires headers if present in the response and configure local cache to match the directives it declares. If directives include one of no-cache, no-store, the client SHOULD NOT cache the data for future interactions. If directives include max-age or if an Expires header is present, the client SHOULD cache the SDD data, if valid, up to the expiration indicated, either at the time indicated by the Expires header or max-age seconds from request time.

An Etag header MAY be offered with the SDD response. If so, after a resource's declared expiration, a client MAY include an If-None-Match header containing the value of the Etag to check if the resource is still fresh. If so the resource server may return a 304 Not Modified response status code, and a new Expires or Cache-Control header MAY be included, which the client SHOULD use to update the cache expiration.

Register with Authorization Server

With the Client Registration URL in hand (from the x-imssf-registrationUrl property of the SDD), the client SHOULD post a registration request to the authorization server. The registration request MUST comply with OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. The registration request MUST NOT require an Initial Access Token. Use of the 'Software Statement' is NOT RECOMMENDED. The client registration request is sent to the Client Registration URL. The request MUST be sent using HTTPS with TLS 1.2 or 1.3 protocol.

The properties of the JSON body MUST be implemented as described in the following table. All URLs MUST use HTTPS (e.g. https://example.com/logo.png) and all URLs MUST have the same hostname. All required properties MUST be present in the registration request in order for it to be accepted by the authorization server. Arrays MUST be used even when a single value is to be sent.

Name	Type	Description	Required
`client_name`	String	The human-readable name of the client application.	Required
`client_uri`	URL	A page that describes the client application.	Required
`logo_uri`	URL	The logo of the client application. If present, the authorization server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file.	Required
`tos_uri`	URL	The human-readable Terms of Service for the client application that describes a contractural relationship between the end-user and the client that the end-user accepts when authorizing the client.	Required
`policy_uri`	URL	The human-readable Privacy Policy for the client application that describes how the deployment organization collects, uses, retains, and discloses personal data.	Required
`software_id`	String	A unique idenfitier assigned by the client application developer or software published used by registration endpoints to identify the client application to be dynamically registered. As described in [rfc7591], it SHOULD remain the same for all instances of the client application software.	Required
`software_version`	String	A version identifier string for the client application software identifies by `software_id`. The value of `software_version` SHOULD change on any update to the client application software identified by the same `software_id`.	Required
`redirect_uris`	URL[]	Array of redirection URI strings for use in the OAuth 2.0 flow.	Required
`scope`	String	In the registration request, this is a string containing a space-separated list of scope values that this client application may include when requesting access tokens. If omitted, the authorization server MAY register a client application with a default set of scopes. In the registration response, this is a list of scopes the authorization server supports. The list of scopes that can be requested are described below: https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly Permission to read CLRs for the user on the resource server platform. https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.upsert Permission to create or update CLRs for the user on the resource server platform. https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly Permission to read the profile for the user on the resource server platform. https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update Permission to update the profile for the user on the resource server platform. offline_access Permission to issue a `refresh_token` along with the `access_token`.	Required
`token_endpoint_auth_method`	String	String indicator of the requested authentication method for the token endpoint. In this specification only "client_secret_basic" is allowed: "client_secret_basic": The client application uses the HTTP Basic authentication method as defined in OAuth 2.0. If omitted, the default is "client_secret_basic".	Optional
`grant_types`	String[]	Array of OAuth 2.0 grant type strings. In this specification only "authorization_code" and refresh_token" are allowed: "authorization_code": The authorization code grant type defined in OAuth 2.0. "refresh_token": The refresh token grant type defined in OAuth 2.0. If omitted, the default behavior is that the client will use only the "authorization_code" grant type.	Optional
`response_types`	String[]	Array of OAuth 2.0 response type strings. In this specification only "code" is allowed: "code": The authorization code response type defined in OAuth 2.0. If omitted, the default is that the client will use only the "code" response type.	Optional
`contacts`	String[]	Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client application. Privacy constraints MUST be supported as applicable.	Optional

Example 24: Sample registration request

POST /connect/register HTTP/1.1
Host: auth.example.com
Accept: application/json
Content-Type: application/json; charset=utf-8

{
    "client_name": "Example Client Application",
    "client_uri": "https://client.example.com/",
    "logo_uri": "https://client.example.com/logo.png",
    "tos_uri": "https://client.example.com/terms",
    "policy_uri": "https://client.example.com/privacy",
    "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1",
    "software_version": "v4.0.30319",
    "redirect_uris": [
        "https://client.example.com/Authorize"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "grant_types": [
        "authorization_code",
        "refresh_token"
    ],
    "response_types": [
        "code"
    ],
    "scope": "https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.upsert https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update offline_access"
}

If the authorization server accepts the registration request, it will store the information provided in the request and respond HTTP 201 Created with a registration response that includes a set of client credentials for the client application to use when requesting access tokens. All the information provided by the client application MUST be returned to the client application, including modifications to the properties as the authorization server deems necessary. An example response looks like this:

Example 25: Sample registration response

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8

{
    "client_id": "4ad36680810420ed",
    "client_secret": "af7aa0d679778e12",
    "client_id_issued_at": 1565715850,
    "client_secret_expires_at": 1597338250,
    "client_name": "Example Client Application",
    "client_uri": "https://client.example.com/",
    "logo_uri": "https://client.example.com/logo.png",
    "tos_uri": "https://client.example.com/terms",
    "policy_uri": "https://client.example.com/privacy",
    "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1",
    "software_version": "v4.0.30319",
    "redirect_uris": [
        "https://client.example.com/Authorize"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "grant_types": [
        "authorization_code",
        "refresh_token"
    ],
    "response_types": [
        "code"
    ],
    "scope": "https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.upsert https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update offline_access"
}

The following table describes the properties present in the client registration response that were not included in the request. These are all REQUIRED properties.

Name	Type	Description	Required
`client_id`	String	An OAuth 2.0 client identifier string. The value SHOULD NOT be currently valid for any other registered client.	Required
`client_secret`	String	An OAuth 2.0 client secret string.	Required
`client_id_issued_at`	NonNegativeInteger	The time at which the client_id was issued. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of issuance.	Required
`client_secret_expires_at`	NonNegativeInteger	The time at which the `client_secret` will expire. MAY be 0 for no expiration. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.	Required

When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object describing the error in the response body. The properties used are:

Name	Type	Description	Required
`error`	RegistrationError	The error.	Required
`error`	ASCIIString	Human-readable ASCII text description of the error used for debugging.	Optional

7. Proofs (Signatures)

This section describes mechanisms for ensuring the authenticity and integrity of CLR Standard documents and payloads. At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential; that is, to be verifiable.

7.1 Proof Formats

The proof formats included in this specification fall into two categories:

JSON Web Token Proof - Somtimes called VC-JWT, this format has a single implementation: the credential is encoded into a JWT which is then signed and encoded as a JWS. The JSON Web Token proof is called an external proof because the proof wraps the credential object.
Linked Data Proofs - The credential is signed and the signature is used to form a Proof object which is appended to the credential. This format supports many different proof types. These are called embedded proofs because the proof is embedded in the data.

Note

The issuer MAY use multiple proofs. If multiple proofs are provided, the verifier MAY use any one proof to verify the credential.

A third category of proof format called Non-Signature Proof is not covered by this specification. This category includes proofs such as proof of work.

7.2 JSON Web Token Proof Format

This proof format relies on the well established JWT (JSON Web Token) [RFC7519] and JWS (JSON Web Signature) [RFC7515] specifications. A JSON Web Token Proof is a JWT signed and encoded as a Compact JWS string. The proof format is described in detail in [VC-JOSE-COSE], refered from Section 5.13 "Securing Mechanism Specifications" of Verifiable Credentials Data Model v2.0. That description allows several options which may inhibit interoperability. This specification limits the options while maintaining compatibility with [VC-DATA-MODEL-2.0] to help ensure interoperability.

Note

At the time of the completion of this specification, the JSON Web Token Proof Format of [VC-DATA-MODEL-2.0] was undergoing a revision process. [VC-JOSE-COSE] will collect and display the result of this revision. The modifications resulting from the incompatibility of the revision with what is contained in this document will be added in future revisions.

7.2.1 Terminology

Some of the terms used in this section include:

JWT - "JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted." [RFC7519]
JWS - "JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification." [RFC7515]
JWK - "A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key." [RFC7517]
Compact JWS - "A compact representation of a JWS." [RFC7515]

7.2.2 Overview

A JWS is a signed JWT with three parts separated by period (".") characters. Each part contains a base64url-encoded value.

JOSE Header - Describes the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. [RFC7515]
JWT Payload - The JSON object that will be signed. In this specification, the JWT Payload includes the ClrCredential.
JWS Signature - The computed signature of the JWT Payload.

The JOSE Header, JWT Payload, and JWS Signature are combined to form a Compact JWS. To transform a credential into a Compact JWS takes 4 steps:

Create the JOSE Header, specifying the signing algorithm to use
Create the JWT Payload from the credential to be signed
Compute the signature of the JWT Payload
Encode the resulting JWS as a Compact JWS

The resulting JWS proves that the issuer signed the JWT Payload turning the credential into a verifiable credential.

When using the JSON Web Token Proof Format, the proof property MAY be ommitted from the ClrCredential. If a Linked Data Proof is also provided, it MUST be created before the JSON Web Token Proof Format is created.

7.2.3 Create the JOSE Header

The JOSE Header is a JSON object with the following properties (also called JOSE Headers). Additional JOSE Headers are NOT allowed.

Property / JOSE Header	Type	Description	Required?
`alg`	String	The signing algorithm MUST be "RS256" as a minimum as defined in [RFC7518]. Support for other algorithms is permitted but their use limits interoperability. Later versions of this specification MAY add OPTIONAL support for other algorithms. See Section 6.1 RSA Key of the IMS Global Security Framework v1.1.	Required
`kid`	URI	A URI that can be dereferenced to an object of type JWK representing the public key used to verify the signature. If you do not include a `kid` property in the header, you MUST include the public key in the `jwk` property. Be careful not to accidentally expose the JWK representation of a private key. See RFC7517 for examples of private key representations. The `JWK` MUST never contain `"d"`.	Optional
`jwk`	JWK	A JWK representing the public key used to verify the signature. If you do not include a `jwk` property in the header, you MUST include the `kid` property. Be careful not to accidentally expose the JWK representation of a private key. See RFC7517 for examples of private key representations. The `JWK` MUST never contain `"d"`.	Optional
`typ`	String	If present, MUST be set to "JWT".	Optional

Example 26: Sample JOSE Header with reference to a public key in a JWKS

{
  "alg": "RS256",
  "kid": "https://example.edu/keys#key-1",
  "typ": "JWT"
}

7.2.4 Create the JWT Payload

If you are going to use both external and embedded proof formats, add the embedded proofs prior to creating the JWT Payload.

7.2.4.1 Sign Nested Credentials

A ClrCredential has nested verifiable credentials. The Verifiable Credentials Data Model v1.1 specification does not specify how to encode a JWT Payload when the credential has nested credentials (it does have an example of an encoded presentation with a nested credential). To help ensure interoperability, this specification defines how to encode the JWT Payload with nested credentials.

The JSON Web Token Proof for each nested credential MUST be created prior to creating the JWT Payload for the parent credential. Because the JSON Web Token Proof for each nested credential is a Compact JWS string rather than a JSON object, the data model for a ClrCredential with VC-JWT proof is ClrCredentialJwtPayload.

Create a JSON object using the ClrCredentialJwtPayload data model.
Copy all of the claims from the parent credential to the new JSON object except for the nested credentials.
Process each nested credential:
- If the nested credential is already signed with a JSON Web Token Proof, simply add the Compact JWS string to the new JSON object.
- If the nested credential is not signed with a JSON Web Token Proof, sign it with a JSON Web Token Proof and add the resulting Compact JWS string to the new JSON object.
Use the new JSON object to form the JWT Payload.

Example 27: Sample ClrCredential prior to signing the nested AchievementCredentials

{
  ...
  "credentialSubject": {
    "verifiableCredential": [
      {
        "id": "assertion1",
        ...
      },
      {
        "id": "assertion2",
        ...
      }
    ]
  }
}

Example 28: Sample ClrCredential after signing the nested AchievementCredentials

{
  ...
  "credentialSubject": {
    "verifiableCredential": [
      "header.payload.signature",
      "header.payload.signature"
    ]
  }
}

7.2.4.2 JWT Payload Format

The JWT Payload is the JSON object with the following properties (JWT Claims). Additional standard JWT Claims Names are allowed, but their relationship to the credential is not defined.

Property / Claim Name	Type	Description	Required?
`exp`	NumericDate	The `validUntil` property of the ClrCredential. Required if the ClrCredential has an `validUntil`.	Optional
`iss`	URI	The `issuer.id` property of the ClrCredential.	Required
`jti`	URI	The `id` property of the ClrCredential.	Required
`nbf`	NumericDate	The `validFrom` property of the ClrCredential.	Required
`sub`	URI	The `credentialSubject.id` property of the ClrCredential.	Required
`vc`	ClrCredential	The ClrCredential being signed.	Required

7.2.5 Create the Proof

Note: Sign and Encode the JWS

1EdTech strongly recommends using an existing, stable library for this step.

This section uses the follow notations:

JOSE Header - denotes the JSON string representation of the JOSE Header.
JWT Payload - denotes the JSON string representation of the JWT Payload.
BASE64URL(OCTETS) - denotes the base64url encoding of OCTETS per [RFC7515].
UTF8(STRING) - denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of Unicode [UNICODE] characters.
The concatenation of two values A and B is denoted as A || B.

The steps to sign and encode the credential as a Compact JWS are shown below:

Encode the JOSE Header as BASE64URL(UTF8(JOSE Header)).
Encode the JWT Payload as BASE64URL(JWT Payload).
Concatenate the encoded JOSE Header and the encoded JSW Payload as A | "." | B.
Calculate the JWS Signature for C as described in [RFC7515].
Encode the signature as BASE64URL(JWS Signature).
Concatenate C and E as C | "." | E.

The resulting string is the Compact JWS representation of the credential. The Compact JWS includes the credential AND acts as the proof for the credential.

7.2.6 Verify a ClrCredential

Verifiers that receive a ClrCredential in Compact JWS format MUST perform the following steps to verify the embedded credential.

Base64url-decode the JOSE Header.
If the header includes a kid property, Dereference the kid value to retrieve the public key JWK.
If the header includes a jwk property, convert the jwk value into the public key JWK.
Use the public key JWK to verify the signature as described in "Section 5.2 Message Signature or MAC Validation" of [RFC7515]. If the signature is not valid, the credential proof is not valid.

Note: Verifying the JWS Signature

1EdTech strongly recommends using an existing, stable library for this step.
Base64url-decode the JWT Payload segment of the Compact JWS and parse it into a JSON object.
Convert the value of the JWT Payload to a ClrCredential and continue with § 7.2.6.1 Verify a Credential VC-JWT Signature.

Note
Credentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) store the OpenBadgeCredential in the vc claim of the JWT Payload. In this case, the contents of the vc claim must be converted to an ClrCredential and continue with § 7.2.6.1 Verify a Credential VC-JWT Signature.

7.2.6.1 Verify a Credential VC-JWT Signature

The JSON object MUST have the iss claim, and the value MUST match the id of the issuer of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.
The JSON object MUST have the sub claim, and the value MUST match the id of the credentialSubject of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.
The JSON object MUST have the nbf claim, and the NumericDate value MUST be converted to a DateTime, and MUST equal the validFrom of the ClrCredentialJwtPayload object. If they do not match or if the validFrom has not yet occurred, the credential is not valid.
The JSON object MUST have the jti claim, and the value MUST match the id of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.
If the JSON object has the exp claim, the NumericDate MUST be converted to a DateTime, and MUST be used to set the value of the validUntil of the ClrCredentialJwtPayload object. If the credential has expired, the credential is not valid.

Note

Credentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they have issuanceDate and expirationDate instead of validFrom and validUntil, respectively

7.3 Linked Data Proof Format

This standard supports the Linked Data Proof format. In order to opt for this format you MUST use the Data Integrity EdDSA Cryptosuites v1.0 suite.

Note

Whenever possible, you should use a library or service to create and verify a Linked Data Proof.

7.3.1 Create the Proof

Perform these steps to attach a Linked Data Proof to the credential:

Create an instance of Multikey as shown in Section 2.1.1 DataIntegrityProof of [VC-DI-EDDSA].
Using the key material, sign the credential object as shown in Section 7.1 Proof Algothim of [DATA-INTEGRITY-SPEC] to produce a Proof as shown in Section 2.2.1 DataIntegrityProof of [VC-DI-EDDSA] with a proofPurpose of "assertionMethod".
Add the resulting proof object to the credential proof property.

7.3.2 Verify a ClrCredential Linked Data Signature

Verify the Linked Data Proof signature as shown in Section 7.2 Proof Verification Algorthim of [DATA-INTEGRITY-SPEC].

7.4 Key Management

Issuers will need to manage asymmetric keys. The mechanisms by which keys are minted and distributed is outside the scope of this specification. See Section 6. Key Management of the IMS Global Security Framework v1.1.

7.5 Dereferencing the Public Key

All the proof formats in this specification, and all Digital Integrity proofs in general, require the verifier to "dereference" the public key from a URI. Dereferencing means using the URI to get the public key in JWK format. This specification allows the use of an HTTP URL (e.g. https://1edtech.org/keys/1) or a DID URL (e.g. did:key:123), but only requires HTTP URL support.

8. Verification and Validation

Verification is the process to determine whether a verifiable credential is an authentic and timely statement of the issuer or presenter respectively. This includes checking that: the credential conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.

Validation is the process of assuring the verifiable credential meets the needs of the verifier and other dependent stakeholders. Validating verifiable credentials is outside the scope of this specification.

Note

The 1EdTech Validator performs verification as described here.

8.1 ClrCredential Verification

This section applies to Verifiable Credentials with a type of "ClrCredential".

Check that the ClrCredential conforms to the specification:
- If the ClrCredential has a credentialSchema property, and the type of the CredentialSchema object is "1EdTechJsonSchemaValidator2019", check that the credential conforms to JSON Schema as shown in 1EdTech JSON Schema Validator 2019. If it does not, the credential does not conform to the specification.
- Check that the credentialSubject is identified by an id and/or an identifier. If neither is present, the credential does not conform to the specification.
Note
ClrCredentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they have issuanceDate and expirationDate instead of validFrom and validUntil, respectively. The data model of these credentials and their corresponding JSON schemas, are described at § B.11 Verification Support Data Models and § B.9 Derived Types, respectively.
Check that the proof method is satisfied:
- If the ClrCredential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT), verify the signature as shown in § 7.2.6 Verify a ClrCredential. If the ClrCredential is signed using an embedded proof, verify the signature as shown in § 7.3.2 Verify a ClrCredential Linked Data Signature. If the signature cannot be verified, the proof method is not satisfied.
Note
The ClrCredential may have a VC-JWT proof and one or more Linked Data proofs. In this case, the Linked Data proofs will be attached to the ClrCredential in the vc claim of the signed JWT Payload. You may accept any one proof for verification. You do not need to verify all the signatures.
Refresh the ClrCredential:

Note
Refresh must be completed after checking the proof so that the verifier is not spoofed into receiving a refreshed ClrCredential from a bad actor.
- If the refreshService property is present, and the type of the RefreshService object is "ImsCredentialRefresh", refresh the credential as shown in 1EdTech Credential Refresh Service and then repeat steps 1 and 2. If the refresh is not successful, continue the verification process using the original ClrCredential.
  Note
  Only perform Refresh once. That is, do not complete Refresh a second time even if the refreshed ClrCredential also has a refreshService defined.
Check the status:
- A Credential is revoked if the credentialStatus property is present, and the type of the CredentialStatus object is "1EdTechRevocationList", and if the ClrCredential has been revoked as shown in 1EdTech Revocation List Status Method.
- If the current date and time is before the validFrom, the ClrCredential is not yet valid.
- If the current date and time is after the validUntil, the ClrCredential is expired.
Note
ClrCredentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they have issuanceDate and expirationDate instead of validFrom and validUntil, respectively. The data model of these credentials and their corresponding JSON schemas, are described at § B.11 Verification Support Data Models and § B.9 Derived Types, respectively.
Optionally verify the subject (recipient):

Note
This step is optional, but RECOMMENDED when the ClrCredential has been exchanged with the verifier as one of the § 4. CLR Standard Document Formats.
- A ClrCredential is about a person called the recipient. The recipient is identified in the credentialSubject (see ClrSubject) by id and/or one or more identifier (see IdentityObject). The id or identifier value to use for verification must be shared with the verifier in an out-of-band process such as by email. This is called the known value.
- To verify the recipient using a known id, simply compare the known id with the id in the ClrSubject. If they are equal then the recipient is verified.
- To verify the recipient using a known identifier such as email address follow these steps shown in § 8.2 Verify the Recipient Using an Identifier. If you find a match then the recipient is verified.
- If no match is found, the recipient is not verified.
Verify nested verifiable credentials:
- A ClrCredential usually contains nested verifiable credentials in the credentialSubject. A ClrCredential may also contain nested EndorsementCredentials. If the nested verifiable credential has a type of "AchievementCredential" or "OpenBadgeCredential", verify the nested credential as shown in section "OpenBadgeCredential Verification" of the Open Badges Specification v3.0. If the nested verifiable credential has a type of "EndorsementCredential", verify the nested credential as shown in section "EndorsementCredential Verification" of the Open Badges Specification v3.0.

If all the above steps pass, the ClrCredential may be treated as verified.

8.2 Verify the Recipient Using an Identifier

The known identifier MUST be a plaintext string value. The known identifier type MUST be one of the types in IdentifierTypeEnum or an extension type. For example, if the known identifier is an email address, the known identifier type is emailAddress.

The ClrCredential issuer may include multiple identifiers that can be used for verification. The verifier should compare the known identifier (e.g. known email address) with all the identifiers included by the issuer until a match is found.

If identifier.identityType does not match the known identifier type, skip to the next identifier.
If identifier.hashed is true, calculate the known identifier IdentityHash using the known identifier and the identifier.salt. If the known identifier IdentityHash matches the identifier.identityHash, the recipient is verified.
If identifier.hashed is false, and if the known identifier matches the identifier.identityHash, the recipient is verified.

9. Credential equality and comparison algorithm

Credential equality and comparison is the process to determine whether a verifiable credential is semantically equivalent to another one.

A Host SHOULD treat a credential as the same as another when both the issuer id and the ClrCredential id are equal after unescaping of any percent encoded characters [RFC3986] followed by truncation of leading and trailing whitespace.

If the two credentials are equal according to the above, then the credential with the newer validFrom is the more up-to-date representation and could be interpreted as a replacement of the prior issued credential.

9.1 Examples

9.1.1 Equality

Credentials A and B are equal since they have the same id and the same issuer.id.

Example 29: Sample Credential A

Credential
Verifiable Credential (with proof)
Verifiable Credential (as JWT)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [ "VerifiableCredential", "ClrCredential" ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": ["Profile"],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": ["ClrSubject"],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": ["VerifiableCredential", "AchievementCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": ["AchievementSubject"],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": ["Achievement"],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": ["Profile"]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [{
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [{
    "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
    "type": "1EdTechJsonSchemaValidator2019"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": [
              "Achievement"
            ],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": [
                "Profile"
              ]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "proof": [
          {
            "type": "DataIntegrityProof",
            "created": "2024-04-29T10:06:18Z",
            "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
            "cryptosuite": "eddsa-rdfc-2022",
            "proofPurpose": "assertionMethod",
            "proofValue": "z3kyX2eWRrRZWNqpQFu9CytoZ39s9Z7Z9JB7haFUUCHBes7Ui8Qa3fmfSa25M1zQCobqmzK1YVzJe8KRbc2dfAYWK"
          }
        ]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2024-04-29T10:06:19Z",
      "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z2971BzDRVZb18eddyXv39KHS2AKEkQFmjum8tPwgJky1AHDruFHqvjuyZLbsKwqznbJ18gGWEgwdxr4FYvawvF9x"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "sFDvfd-cgnI-RdGZGAsOBI8AqNqDpms10FslOb2VzVaL1AwAFMSPOLk2iRUWzaYup1MSNI
TN4vUV6-E0E8X_KUJBPKIDafOJmaS3X5w3mIeJRlx15io_qhMCUw0Qrd1XdimfJrmU4zFQzW7boMN7ue
s7L9DTrzx7GF-ArkOya5VX1Cm_mR3qpLdyLvf03NC2CsI8wtop4l9wLja4TlTnqEeWufos8-s5-Zy2-S
LQi1LTdzVDEI6LezasIhc7OwkbGVU_7owY5aw4VGojehXWN2h48JWYI_SIBjeGjLaP24H4CvulSxhuhP
Jt10RHOgMw1YhJ4Sk5q2qQGTJxJHBDtQ"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQ
SIsIm4iOiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT
0xrMmlSVVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxN
WlvX3FoTUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYM
UNtX21SM3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRa
TFMVGR6VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHa
kxhUDI0SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29ud
GV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwua
W1zZ2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvY29udGV4dC0zLjAuMy5qc29uIiwiaHR0cHM6Ly9wdXJsL
mltc2dsb2JhbC5vcmcvc3BlYy9vYi92M3AwL2V4dGVuc2lvbnMuanNvbiJdLCJpZCI6InVybjp1dWlkO
jkxNTM3ZGJhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZ
WRlbnRpYWwiLCJBY2hpZXZlbWVudENyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdLCJuYW1lIjoiRXhhbXBsZ
SBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwibmFtZSI6IkV4Y
W1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtc
GxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsInR5cGUiOlsiQWNoaWV2ZW1lbnRTdWJqZWN0I
l0sImFjaGlldmVtZW50Ijp7ImlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0M
mFjMTMwMDAyIiwidHlwZSI6WyJBY2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlld
mVtZW50IDEiLCJjcml0ZXJpYSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL
2E3NDY3ZWY2LTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvb
iI6IkFjaGlldmVtZW50IDEiLCJpbWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2Z
W1lbnRzL3NhbXBsZS5wbmciLCJ0eXBlIjoiSW1hZ2UifX19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZ
CI6Imh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX
3YycDBfY2xyY3JlZGVudGlhbF9zY2hlbWEuanNvbiIsInR5cGUiOiIxRWRUZWNoSnNvblNjaGVtYVZhb
GlkYXRvcjIwMTkifV0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJqd
GkiOiJ1cm46dXVpZDo5MTUzN2RiYS01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJzdWIiOiJka
WQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.fyPeBnaaPwY_OdFHpR0go6n4vB
sH9Wkvf1kZPnvmx0bv0IhJk-mpI8BX35KnVdhlahaHJT_fqH6Aj4EjCJt-iMHodv0nafiA-JoOgGpTNI
ysS7mnd6dOpzKZS9qKWZ5rYRjjhOM4uDPiKli35d-VG9b7ALZU_V2UZbJ1T7RrZVJ8xCpWKaolEkvK_A
NAMCTS-x2nerIsjWviCe6LEpTr0RwJHeXAPPRJ4N6qnZeKR_a-ZgHFioV-5ABWqqFqKwn4eX8SoNeIFB
b-UJpGg_qHl1C0nGU4MP__NALe27AnPHZKJeu0FtnuXDQ0swz2sKUAw6aFqxydRgXhTjINR4KUHQ"
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achie
vementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "iss": "https://example.edu/issuers/565049",
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT0xrMmlS
VVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxNWlvX3Fo
TUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYMUNtX21S
M3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRaTFMVGR6
VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHakxhUDI0
SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29udGV4dCI6
WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwuaW1zZ2xv
YmFsLm9yZy9zcGVjL2Nsci92MnAwL2NvbnRleHQtMi4wLjEuanNvbiIsImh0dHBzOi8vcHVybC5pbXNn
bG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4zLmpzb24iLCJodHRwczovL3B1cmwuaW1z
Z2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDovL2V4YW1w
bGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiQ2xy
Q3JlZGVudGlhbCJdLCJpc3N1ZXIiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1
MDQ5IiwidHlwZSI6WyJQcm9maWxlIl0sIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkifSwidmFsaWRG
cm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJuYW1lIjoiU2FtcGxlIFRyYW5zY3JpcHQiLCJjcmVk
ZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSIsInR5cGUiOlsiQ2xyU3ViamVjdCJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9p
SlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXAzYXlJNmV5SmxJam9pUVZGQlFpSXNJbXQwZVNJNkls
SlRRU0lzSW00aU9pSnpSa1IyWm1RdFkyZHVTUzFTWkVkYVIwRnpUMEpKT0VGeFRuRkVjRzF6TVRCR2My
eFBZakpXZWxaaFRERkJkMEZHVFZOUVQweHJNbWxTVlZkNllWbDFjREZOVTA1SlZFNDBkbFZXTmkxRk1F
VTRXRjlMVlVwQ1VFdEpSR0ZtVDBwdFlWTXpXRFYzTTIxSlpVcFNiSGd4TldsdlgzRm9UVU5WZHpCUmNt
UXhXR1JwYldaS2NtMVZOSHBHVVhwWE4ySnZUVTQzZFdWek4wdzVSRlJ5ZW5nM1IwWXRRWEpyVDNsaE5W
WllNVU50WDIxU00zRndUR1I1VEhabU1ETk9RekpEYzBrNGQzUnZjRFJzT1hkTWFtRTBWR3hVYm5GRlpW
ZDFabTl6T0Mxek5TMWFlVEl0VTB4UmFURk1WR1I2VmtSRlNUWk1aWHBoYzBsb1l6ZFBkMnRpUjFaVlh6
ZHZkMWsxWVhjMFZrZHZhbVZvV0ZkT01tZzBPRXBYV1VsZlUwbENhbVZIYWt4aFVESTBTRFJEZG5Wc1Uz
aG9kV2hRU25ReE1GSklUMmROZHpGWmFFbzBVMnMxY1RKeFVVZFVTbmhLU0VKRWRGRWlmWDAuZXlKQVky
OXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRq
SWlMQ0pvZEhSd2N6b3ZMM0IxY213dWFXMXpaMnh2WW1Gc0xtOXlaeTl6Y0dWakwyOWlMM1l6Y0RBdlky
OXVkR1Y0ZEMwekxqQXVNeTVxYzI5dUlpd2lhSFIwY0hNNkx5OXdkWEpzTG1sdGMyZHNiMkpoYkM1dmNt
Y3ZjM0JsWXk5dllpOTJNM0F3TDJWNGRHVnVjMmx2Ym5NdWFuTnZiaUpkTENKcFpDSTZJblZ5YmpwMWRX
bGtPamt4TlRNM1pHSmhMVFUyWTJJdE1URmxZeTFpWmpZekxUQXlOREpoWXpFek1EQXdNaUlzSW5SNWNH
VWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSkJZMmhwWlhabGJXVnVkRU55WldSbGJu
UnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkTENKdVlXMWxJam9pUlhoaGJY
QnNaU0JWYm1sMlpYSnphWFI1SW4wc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTURBNk1E
QTZNREJhSWl3aWJtRnRaU0k2SWtWNFlXMXdiR1VnVlc1cGRtVnljMmwwZVNCRVpXZHlaV1VpTENKamNt
VmtaVzUwYVdGc1UzVmlhbVZqZENJNmV5SnBaQ0k2SW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01U
SmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSXNJblI1Y0dVaU9sc2lRV05vYVdWMlpXMWxiblJUZFdKcVpX
TjBJbDBzSW1GamFHbGxkbVZ0Wlc1MElqcDdJbWxrSWpvaWRYSnVPblYxYVdRNllUYzBOamRsWmpZdE5U
WmpZaTB4TVdWakxXSm1Oak10TURJME1tRmpNVE13TURBeUlpd2lkSGx3WlNJNld5SkJZMmhwWlhabGJX
VnVkQ0pkTENKamNtVmhkRzl5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkZlN3aWJtRnRaU0k2SWtGamFH
bGxkbVZ0Wlc1MElERWlMQ0pqY21sMFpYSnBZU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pT
NWxaSFV2WVdOb2FXVjJaVzFsYm5SekwyRTNORFkzWldZMkxUVTJZMkl0TVRGbFl5MWlaall6TFRBeU5E
SmhZekV6TURBd01pOWpjbWwwWlhKcFlTSjlMQ0prWlhOamNtbHdkR2x2YmlJNklrRmphR2xsZG1WdFpX
NTBJREVpTENKcGJXRm5aU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWxaSFV2WVdOb2FX
VjJaVzFsYm5SekwzTmhiWEJzWlM1d2JtY2lMQ0owZVhCbElqb2lTVzFoWjJVaWZYMTlMQ0pqY21Wa1pX
NTBhV0ZzVTJOb1pXMWhJanBiZXlKcFpDSTZJbWgwZEhCek9pOHZjSFZ5YkM1cGJYTm5iRzlpWVd3dWIz
Sm5MM053WldNdlkyeHlMM1l5Y0RBdmMyTm9aVzFoTDJwemIyNHZZMnh5WDNZeWNEQmZZMnh5WTNKbFpH
VnVkR2xoYkY5elkyaGxiV0V1YW5OdmJpSXNJblI1Y0dVaU9pSXhSV1JVWldOb1NuTnZibE5qYUdWdFlW
WmhiR2xrWVhSdmNqSXdNVGtpZlYwc0ltbHpjeUk2SW1oMGRIQnpPaTh2WlhoaGJYQnNaUzVsWkhVdmFY
TnpkV1Z5Y3k4MU5qVXdORGtpTENKcWRHa2lPaUoxY200NmRYVnBaRG81TVRVek4yUmlZUzAxTm1OaUxU
RXhaV010WW1ZMk15MHdNalF5WVdNeE16QXdNRElpTENKemRXSWlPaUprYVdRNlpYaGhiWEJzWlRwbFlt
WmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaWZRLmZ5UGVCbmFhUHdZX09kRkhwUjBnbzZu
NHZCc0g5V2t2ZjFrWlBudm14MGJ2MEloSmstbXBJOEJYMzVLblZkaGxhaGFISlRfZnFINkFqNEVqQ0p0
LWlNSG9kdjBuYWZpQS1Kb09nR3BUTkl5c1M3bW5kNmRPcHpLWlM5cUtXWjVyWVJqamhPTTR1RFBpS2xp
MzVkLVZHOWI3QUxaVV9WMlVaYkoxVDdSclpWSjh4Q3BXS2FvbEVrdktfQU5BTUNUUy14Mm5lcklzald2
aUNlNkxFcFRyMFJ3SkhlWEFQUFJKNE42cW5aZUtSX2EtWmdIRmlvVi01QUJXcXFGcUt3bjRlWDhTb05l
SUZCYi1VSnBHZ19xSGwxQzBuR1U0TVBfX05BTGUyN0FuUEhaS0pldTBGdG51WERRMHN3ejJzS1VBdzZh
RnF4eWRSZ1hoVGpJTlI0S1VIUSJdLCJhY2hpZXZlbWVudCI6W3siaWQiOiJ1cm46dXVpZDphNzQ2N2Vm
Ni01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJ0eXBlIjpbIkFjaGlldmVtZW50Il0sImNyZWF0
b3IiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwidHlwZSI6WyJQcm9m
aWxlIl19LCJuYW1lIjoiQWNoaWV2ZW1lbnQgMSIsImNyaXRlcmlhIjp7ImlkIjoiaHR0cHM6Ly9leGFt
cGxlLmVkdS9hY2hpZXZlbWVudHMvYTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyL2Ny
aXRlcmlhIn0sImRlc2NyaXB0aW9uIjoiQWNoaWV2ZW1lbnQgMSIsImltYWdlIjp7ImlkIjoiaHR0cHM6
Ly9leGFtcGxlLmVkdS9hY2hpZXZlbWVudHMvc2FtcGxlLnBuZyIsInR5cGUiOiJJbWFnZSJ9fSx7Imlk
IjoidXJuOnV1aWQ6ZGQ4ODdmMGEtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidHlwZSI6WyJB
Y2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2
NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlldmVtZW50IDIiLCJjcml0ZXJpYSI6
eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL2RkODg3ZjBhLTU2Y2ItMTFlYy1i
ZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvbiI6IkFjaGlldmVtZW50IDIiLCJp
bWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL3NhbXBsZS5wbmciLCJ0
eXBlIjoiSW1hZ2UifX1dLCJhc3NvY2lhdGlvbiI6W3sidHlwZSI6IkFzc29jaWF0aW9uIiwiYXNzb2Np
YXRpb25UeXBlIjoiaXNQYXJlbnRPZiIsInNvdXJjZUlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0x
MWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidGFyZ2V0SWQiOiJ1cm46dXVpZDpkZDg4N2YwYS01NmNiLTEx
ZWMtYmY2My0wMjQyYWMxMzAwMDIifV19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZCI6Imh0dHBzOi8v
cHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX3YycDBfYWNoaWV2
ZW1lbnRjcmVkZW50aWFsX3NjaGVtYS5qc29uIiwidHlwZSI6IjFFZFRlY2hKc29uU2NoZW1hVmFsaWRh
dG9yMjAxOSJ9XSwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsImp0aSI6
Imh0dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJm
ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.nhPJN49knEyt6laDRd4e6LZGR0UcDLy0m-el5sS8_GDV
K9QJplbmRFQd5oclmV6lYf0612WIPKY5n_hqsK7aSoPpY4kVReAk8-PLvDvOI4MbDsqZEP5Y1NACyOQ0
cbcTtUZROdcuWFSpKol_xdrmectR7M6Xe_JW-7oVReGoyfpjgSxbNSj6ymBElNHHThz7pj9owxdAmwGV
MK9OczvQg_Bxyi7K1d0RxvR28FeqIn7xd3GCtnu8t5ixhxyFTsPCbKAmQ1H40o27-a3WDCW7KCSsLaKA
eMfn5CmrFvvRxyUixSi1IXhXFMvIN0E3neA74zP5WjvRYs18z2EdTF8I3Q

Example 30: Sample Credential B

Credential
Verifiable Credential (with proof)
Verifiable Credential (as JWT)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [ "VerifiableCredential", "ClrCredential" ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": ["Profile"],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": ["ClrSubject"],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": ["VerifiableCredential", "AchievementCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": ["AchievementSubject"],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": ["Achievement"],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": ["Profile"]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [{
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [{
    "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
    "type": "1EdTechJsonSchemaValidator2019"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": [
              "Achievement"
            ],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": [
                "Profile"
              ]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "proof": [
          {
            "type": "DataIntegrityProof",
            "created": "2024-04-29T10:06:19Z",
            "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
            "cryptosuite": "eddsa-rdfc-2022",
            "proofPurpose": "assertionMethod",
            "proofValue": "z4eFDedxvp7UDXjZPvVNWZU3vyWSYgV8vTBwkd5GSHnUWDGj6WrhTTD5PTRJgKgrVEjqRJPTHTL51b1Y45ERQQiuu"
          }
        ]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2024-04-29T10:06:19Z",
      "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z2GBkgArvX1eEgjt8xMPSYfrMh7aAvxUj1zN2NukQCHyWmGEJvdMsxsZQFE5BYpm3KMuqxtNjV3AKCZcsHVGM69sp"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "sFDvfd-cgnI-RdGZGAsOBI8AqNqDpms10FslOb2VzVaL1AwAFMSPOLk2iRUWzaYup1MSNI
TN4vUV6-E0E8X_KUJBPKIDafOJmaS3X5w3mIeJRlx15io_qhMCUw0Qrd1XdimfJrmU4zFQzW7boMN7ue
s7L9DTrzx7GF-ArkOya5VX1Cm_mR3qpLdyLvf03NC2CsI8wtop4l9wLja4TlTnqEeWufos8-s5-Zy2-S
LQi1LTdzVDEI6LezasIhc7OwkbGVU_7owY5aw4VGojehXWN2h48JWYI_SIBjeGjLaP24H4CvulSxhuhP
Jt10RHOgMw1YhJ4Sk5q2qQGTJxJHBDtQ"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQ
SIsIm4iOiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT
0xrMmlSVVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxN
WlvX3FoTUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYM
UNtX21SM3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRa
TFMVGR6VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHa
kxhUDI0SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29ud
GV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwua
W1zZ2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvY29udGV4dC0zLjAuMy5qc29uIiwiaHR0cHM6Ly9wdXJsL
mltc2dsb2JhbC5vcmcvc3BlYy9vYi92M3AwL2V4dGVuc2lvbnMuanNvbiJdLCJpZCI6InVybjp1dWlkO
jkxNTM3ZGJhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZ
WRlbnRpYWwiLCJBY2hpZXZlbWVudENyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdLCJuYW1lIjoiRXhhbXBsZ
SBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwibmFtZSI6IkV4Y
W1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtc
GxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsInR5cGUiOlsiQWNoaWV2ZW1lbnRTdWJqZWN0I
l0sImFjaGlldmVtZW50Ijp7ImlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0M
mFjMTMwMDAyIiwidHlwZSI6WyJBY2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlld
mVtZW50IDEiLCJjcml0ZXJpYSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL
2E3NDY3ZWY2LTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvb
iI6IkFjaGlldmVtZW50IDEiLCJpbWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2Z
W1lbnRzL3NhbXBsZS5wbmciLCJ0eXBlIjoiSW1hZ2UifX19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZ
CI6Imh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX
3YycDBfY2xyY3JlZGVudGlhbF9zY2hlbWEuanNvbiIsInR5cGUiOiIxRWRUZWNoSnNvblNjaGVtYVZhb
GlkYXRvcjIwMTkifV0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJqd
GkiOiJ1cm46dXVpZDo5MTUzN2RiYS01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJzdWIiOiJka
WQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.fyPeBnaaPwY_OdFHpR0go6n4vB
sH9Wkvf1kZPnvmx0bv0IhJk-mpI8BX35KnVdhlahaHJT_fqH6Aj4EjCJt-iMHodv0nafiA-JoOgGpTNI
ysS7mnd6dOpzKZS9qKWZ5rYRjjhOM4uDPiKli35d-VG9b7ALZU_V2UZbJ1T7RrZVJ8xCpWKaolEkvK_A
NAMCTS-x2nerIsjWviCe6LEpTr0RwJHeXAPPRJ4N6qnZeKR_a-ZgHFioV-5ABWqqFqKwn4eX8SoNeIFB
b-UJpGg_qHl1C0nGU4MP__NALe27AnPHZKJeu0FtnuXDQ0swz2sKUAw6aFqxydRgXhTjINR4KUHQ"
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achie
vementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "iss": "https://example.edu/issuers/565049",
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT0xrMmlS
VVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxNWlvX3Fo
TUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYMUNtX21S
M3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRaTFMVGR6
VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHakxhUDI0
SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29udGV4dCI6
WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwuaW1zZ2xv
YmFsLm9yZy9zcGVjL2Nsci92MnAwL2NvbnRleHQtMi4wLjEuanNvbiIsImh0dHBzOi8vcHVybC5pbXNn
bG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4zLmpzb24iLCJodHRwczovL3B1cmwuaW1z
Z2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDovL2V4YW1w
bGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiQ2xy
Q3JlZGVudGlhbCJdLCJpc3N1ZXIiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1
MDQ5IiwidHlwZSI6WyJQcm9maWxlIl0sIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkifSwidmFsaWRG
cm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJuYW1lIjoiU2FtcGxlIFRyYW5zY3JpcHQiLCJjcmVk
ZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSIsInR5cGUiOlsiQ2xyU3ViamVjdCJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9p
SlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXAzYXlJNmV5SmxJam9pUVZGQlFpSXNJbXQwZVNJNkls
SlRRU0lzSW00aU9pSnpSa1IyWm1RdFkyZHVTUzFTWkVkYVIwRnpUMEpKT0VGeFRuRkVjRzF6TVRCR2My
eFBZakpXZWxaaFRERkJkMEZHVFZOUVQweHJNbWxTVlZkNllWbDFjREZOVTA1SlZFNDBkbFZXTmkxRk1F
VTRXRjlMVlVwQ1VFdEpSR0ZtVDBwdFlWTXpXRFYzTTIxSlpVcFNiSGd4TldsdlgzRm9UVU5WZHpCUmNt
UXhXR1JwYldaS2NtMVZOSHBHVVhwWE4ySnZUVTQzZFdWek4wdzVSRlJ5ZW5nM1IwWXRRWEpyVDNsaE5W
WllNVU50WDIxU00zRndUR1I1VEhabU1ETk9RekpEYzBrNGQzUnZjRFJzT1hkTWFtRTBWR3hVYm5GRlpW
ZDFabTl6T0Mxek5TMWFlVEl0VTB4UmFURk1WR1I2VmtSRlNUWk1aWHBoYzBsb1l6ZFBkMnRpUjFaVlh6
ZHZkMWsxWVhjMFZrZHZhbVZvV0ZkT01tZzBPRXBYV1VsZlUwbENhbVZIYWt4aFVESTBTRFJEZG5Wc1Uz
aG9kV2hRU25ReE1GSklUMmROZHpGWmFFbzBVMnMxY1RKeFVVZFVTbmhLU0VKRWRGRWlmWDAuZXlKQVky
OXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRq
SWlMQ0pvZEhSd2N6b3ZMM0IxY213dWFXMXpaMnh2WW1Gc0xtOXlaeTl6Y0dWakwyOWlMM1l6Y0RBdlky
OXVkR1Y0ZEMwekxqQXVNeTVxYzI5dUlpd2lhSFIwY0hNNkx5OXdkWEpzTG1sdGMyZHNiMkpoYkM1dmNt
Y3ZjM0JsWXk5dllpOTJNM0F3TDJWNGRHVnVjMmx2Ym5NdWFuTnZiaUpkTENKcFpDSTZJblZ5YmpwMWRX
bGtPamt4TlRNM1pHSmhMVFUyWTJJdE1URmxZeTFpWmpZekxUQXlOREpoWXpFek1EQXdNaUlzSW5SNWNH
VWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSkJZMmhwWlhabGJXVnVkRU55WldSbGJu
UnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkTENKdVlXMWxJam9pUlhoaGJY
QnNaU0JWYm1sMlpYSnphWFI1SW4wc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTURBNk1E
QTZNREJhSWl3aWJtRnRaU0k2SWtWNFlXMXdiR1VnVlc1cGRtVnljMmwwZVNCRVpXZHlaV1VpTENKamNt
VmtaVzUwYVdGc1UzVmlhbVZqZENJNmV5SnBaQ0k2SW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01U
SmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSXNJblI1Y0dVaU9sc2lRV05vYVdWMlpXMWxiblJUZFdKcVpX
TjBJbDBzSW1GamFHbGxkbVZ0Wlc1MElqcDdJbWxrSWpvaWRYSnVPblYxYVdRNllUYzBOamRsWmpZdE5U
WmpZaTB4TVdWakxXSm1Oak10TURJME1tRmpNVE13TURBeUlpd2lkSGx3WlNJNld5SkJZMmhwWlhabGJX
VnVkQ0pkTENKamNtVmhkRzl5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkZlN3aWJtRnRaU0k2SWtGamFH
bGxkbVZ0Wlc1MElERWlMQ0pqY21sMFpYSnBZU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pT
NWxaSFV2WVdOb2FXVjJaVzFsYm5SekwyRTNORFkzWldZMkxUVTJZMkl0TVRGbFl5MWlaall6TFRBeU5E
SmhZekV6TURBd01pOWpjbWwwWlhKcFlTSjlMQ0prWlhOamNtbHdkR2x2YmlJNklrRmphR2xsZG1WdFpX
NTBJREVpTENKcGJXRm5aU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWxaSFV2WVdOb2FX
VjJaVzFsYm5SekwzTmhiWEJzWlM1d2JtY2lMQ0owZVhCbElqb2lTVzFoWjJVaWZYMTlMQ0pqY21Wa1pX
NTBhV0ZzVTJOb1pXMWhJanBiZXlKcFpDSTZJbWgwZEhCek9pOHZjSFZ5YkM1cGJYTm5iRzlpWVd3dWIz
Sm5MM053WldNdlkyeHlMM1l5Y0RBdmMyTm9aVzFoTDJwemIyNHZZMnh5WDNZeWNEQmZZMnh5WTNKbFpH
VnVkR2xoYkY5elkyaGxiV0V1YW5OdmJpSXNJblI1Y0dVaU9pSXhSV1JVWldOb1NuTnZibE5qYUdWdFlW
WmhiR2xrWVhSdmNqSXdNVGtpZlYwc0ltbHpjeUk2SW1oMGRIQnpPaTh2WlhoaGJYQnNaUzVsWkhVdmFY
TnpkV1Z5Y3k4MU5qVXdORGtpTENKcWRHa2lPaUoxY200NmRYVnBaRG81TVRVek4yUmlZUzAxTm1OaUxU
RXhaV010WW1ZMk15MHdNalF5WVdNeE16QXdNRElpTENKemRXSWlPaUprYVdRNlpYaGhiWEJzWlRwbFlt
WmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaWZRLmZ5UGVCbmFhUHdZX09kRkhwUjBnbzZu
NHZCc0g5V2t2ZjFrWlBudm14MGJ2MEloSmstbXBJOEJYMzVLblZkaGxhaGFISlRfZnFINkFqNEVqQ0p0
LWlNSG9kdjBuYWZpQS1Kb09nR3BUTkl5c1M3bW5kNmRPcHpLWlM5cUtXWjVyWVJqamhPTTR1RFBpS2xp
MzVkLVZHOWI3QUxaVV9WMlVaYkoxVDdSclpWSjh4Q3BXS2FvbEVrdktfQU5BTUNUUy14Mm5lcklzald2
aUNlNkxFcFRyMFJ3SkhlWEFQUFJKNE42cW5aZUtSX2EtWmdIRmlvVi01QUJXcXFGcUt3bjRlWDhTb05l
SUZCYi1VSnBHZ19xSGwxQzBuR1U0TVBfX05BTGUyN0FuUEhaS0pldTBGdG51WERRMHN3ejJzS1VBdzZh
RnF4eWRSZ1hoVGpJTlI0S1VIUSJdLCJhY2hpZXZlbWVudCI6W3siaWQiOiJ1cm46dXVpZDphNzQ2N2Vm
Ni01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJ0eXBlIjpbIkFjaGlldmVtZW50Il0sImNyZWF0
b3IiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwidHlwZSI6WyJQcm9m
aWxlIl19LCJuYW1lIjoiQWNoaWV2ZW1lbnQgMSIsImNyaXRlcmlhIjp7ImlkIjoiaHR0cHM6Ly9leGFt
cGxlLmVkdS9hY2hpZXZlbWVudHMvYTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyL2Ny
aXRlcmlhIn0sImRlc2NyaXB0aW9uIjoiQWNoaWV2ZW1lbnQgMSIsImltYWdlIjp7ImlkIjoiaHR0cHM6
Ly9leGFtcGxlLmVkdS9hY2hpZXZlbWVudHMvc2FtcGxlLnBuZyIsInR5cGUiOiJJbWFnZSJ9fSx7Imlk
IjoidXJuOnV1aWQ6ZGQ4ODdmMGEtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidHlwZSI6WyJB
Y2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2
NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlldmVtZW50IDIiLCJjcml0ZXJpYSI6
eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL2RkODg3ZjBhLTU2Y2ItMTFlYy1i
ZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvbiI6IkFjaGlldmVtZW50IDIiLCJp
bWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL3NhbXBsZS5wbmciLCJ0
eXBlIjoiSW1hZ2UifX1dLCJhc3NvY2lhdGlvbiI6W3sidHlwZSI6IkFzc29jaWF0aW9uIiwiYXNzb2Np
YXRpb25UeXBlIjoiaXNQYXJlbnRPZiIsInNvdXJjZUlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0x
MWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidGFyZ2V0SWQiOiJ1cm46dXVpZDpkZDg4N2YwYS01NmNiLTEx
ZWMtYmY2My0wMjQyYWMxMzAwMDIifV19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZCI6Imh0dHBzOi8v
cHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX3YycDBfYWNoaWV2
ZW1lbnRjcmVkZW50aWFsX3NjaGVtYS5qc29uIiwidHlwZSI6IjFFZFRlY2hKc29uU2NoZW1hVmFsaWRh
dG9yMjAxOSJ9XSwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsImp0aSI6
Imh0dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJm
ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.nhPJN49knEyt6laDRd4e6LZGR0UcDLy0m-el5sS8_GDV
K9QJplbmRFQd5oclmV6lYf0612WIPKY5n_hqsK7aSoPpY4kVReAk8-PLvDvOI4MbDsqZEP5Y1NACyOQ0
cbcTtUZROdcuWFSpKol_xdrmectR7M6Xe_JW-7oVReGoyfpjgSxbNSj6ymBElNHHThz7pj9owxdAmwGV
MK9OczvQg_Bxyi7K1d0RxvR28FeqIn7xd3GCtnu8t5ixhxyFTsPCbKAmQ1H40o27-a3WDCW7KCSsLaKA
eMfn5CmrFvvRxyUixSi1IXhXFMvIN0E3neA74zP5WjvRYs18z2EdTF8I3Q

Since they also have the same validFrom both are up-to-date.

9.1.2 Comparison

Credentials C and D are equal since they have the same id and the same issuer.id.

Example 31: Sample Credential C

Credential
Verifiable Credential (with proof)
Verifiable Credential (as JWT)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [ "VerifiableCredential", "ClrCredential" ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": ["Profile"],
    "name": "Example University"
  },
  "validFrom": "2010-03-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": ["ClrSubject"],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": ["VerifiableCredential", "AchievementCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": ["AchievementSubject"],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": ["Achievement"],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": ["Profile"]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [{
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [{
    "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
    "type": "1EdTechJsonSchemaValidator2019"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-03-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": [
              "Achievement"
            ],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": [
                "Profile"
              ]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "proof": [
          {
            "type": "DataIntegrityProof",
            "created": "2024-04-29T10:06:19Z",
            "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
            "cryptosuite": "eddsa-rdfc-2022",
            "proofPurpose": "assertionMethod",
            "proofValue": "z4eFDedxvp7UDXjZPvVNWZU3vyWSYgV8vTBwkd5GSHnUWDGj6WrhTTD5PTRJgKgrVEjqRJPTHTL51b1Y45ERQQiuu"
          }
        ]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2024-04-29T10:06:19Z",
      "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z5yhQVegJUzZMp4kCNZ51WNtz4aF1vJia4Dk8pud3snQ8mb9TaSJUaGodHTESQoa6nPBGDwfjidzQYouNsKZrcgj5"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "sFDvfd-cgnI-RdGZGAsOBI8AqNqDpms10FslOb2VzVaL1AwAFMSPOLk2iRUWzaYup1MSNI
TN4vUV6-E0E8X_KUJBPKIDafOJmaS3X5w3mIeJRlx15io_qhMCUw0Qrd1XdimfJrmU4zFQzW7boMN7ue
s7L9DTrzx7GF-ArkOya5VX1Cm_mR3qpLdyLvf03NC2CsI8wtop4l9wLja4TlTnqEeWufos8-s5-Zy2-S
LQi1LTdzVDEI6LezasIhc7OwkbGVU_7owY5aw4VGojehXWN2h48JWYI_SIBjeGjLaP24H4CvulSxhuhP
Jt10RHOgMw1YhJ4Sk5q2qQGTJxJHBDtQ"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-03-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQ
SIsIm4iOiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT
0xrMmlSVVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxN
WlvX3FoTUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYM
UNtX21SM3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRa
TFMVGR6VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHa
kxhUDI0SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29ud
GV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwua
W1zZ2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvY29udGV4dC0zLjAuMy5qc29uIiwiaHR0cHM6Ly9wdXJsL
mltc2dsb2JhbC5vcmcvc3BlYy9vYi92M3AwL2V4dGVuc2lvbnMuanNvbiJdLCJpZCI6InVybjp1dWlkO
jkxNTM3ZGJhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZ
WRlbnRpYWwiLCJBY2hpZXZlbWVudENyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdLCJuYW1lIjoiRXhhbXBsZ
SBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwibmFtZSI6IkV4Y
W1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtc
GxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsInR5cGUiOlsiQWNoaWV2ZW1lbnRTdWJqZWN0I
l0sImFjaGlldmVtZW50Ijp7ImlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0M
mFjMTMwMDAyIiwidHlwZSI6WyJBY2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlld
mVtZW50IDEiLCJjcml0ZXJpYSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL
2E3NDY3ZWY2LTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvb
iI6IkFjaGlldmVtZW50IDEiLCJpbWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2Z
W1lbnRzL3NhbXBsZS5wbmciLCJ0eXBlIjoiSW1hZ2UifX19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZ
CI6Imh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX
3YycDBfY2xyY3JlZGVudGlhbF9zY2hlbWEuanNvbiIsInR5cGUiOiIxRWRUZWNoSnNvblNjaGVtYVZhb
GlkYXRvcjIwMTkifV0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJqd
GkiOiJ1cm46dXVpZDo5MTUzN2RiYS01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJzdWIiOiJka
WQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.fyPeBnaaPwY_OdFHpR0go6n4vB
sH9Wkvf1kZPnvmx0bv0IhJk-mpI8BX35KnVdhlahaHJT_fqH6Aj4EjCJt-iMHodv0nafiA-JoOgGpTNI
ysS7mnd6dOpzKZS9qKWZ5rYRjjhOM4uDPiKli35d-VG9b7ALZU_V2UZbJ1T7RrZVJ8xCpWKaolEkvK_A
NAMCTS-x2nerIsjWviCe6LEpTr0RwJHeXAPPRJ4N6qnZeKR_a-ZgHFioV-5ABWqqFqKwn4eX8SoNeIFB
b-UJpGg_qHl1C0nGU4MP__NALe27AnPHZKJeu0FtnuXDQ0swz2sKUAw6aFqxydRgXhTjINR4KUHQ"
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achie
vementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "iss": "https://example.edu/issuers/565049",
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT0xrMmlS
VVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxNWlvX3Fo
TUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYMUNtX21S
M3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRaTFMVGR6
VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHakxhUDI0
SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29udGV4dCI6
WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwuaW1zZ2xv
YmFsLm9yZy9zcGVjL2Nsci92MnAwL2NvbnRleHQtMi4wLjEuanNvbiIsImh0dHBzOi8vcHVybC5pbXNn
bG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4zLmpzb24iLCJodHRwczovL3B1cmwuaW1z
Z2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDovL2V4YW1w
bGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiQ2xy
Q3JlZGVudGlhbCJdLCJpc3N1ZXIiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1
MDQ5IiwidHlwZSI6WyJQcm9maWxlIl0sIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkifSwidmFsaWRG
cm9tIjoiMjAxMC0wMy0wMVQwMDowMDowMFoiLCJuYW1lIjoiU2FtcGxlIFRyYW5zY3JpcHQiLCJjcmVk
ZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSIsInR5cGUiOlsiQ2xyU3ViamVjdCJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9p
SlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXAzYXlJNmV5SmxJam9pUVZGQlFpSXNJbXQwZVNJNkls
SlRRU0lzSW00aU9pSnpSa1IyWm1RdFkyZHVTUzFTWkVkYVIwRnpUMEpKT0VGeFRuRkVjRzF6TVRCR2My
eFBZakpXZWxaaFRERkJkMEZHVFZOUVQweHJNbWxTVlZkNllWbDFjREZOVTA1SlZFNDBkbFZXTmkxRk1F
VTRXRjlMVlVwQ1VFdEpSR0ZtVDBwdFlWTXpXRFYzTTIxSlpVcFNiSGd4TldsdlgzRm9UVU5WZHpCUmNt
UXhXR1JwYldaS2NtMVZOSHBHVVhwWE4ySnZUVTQzZFdWek4wdzVSRlJ5ZW5nM1IwWXRRWEpyVDNsaE5W
WllNVU50WDIxU00zRndUR1I1VEhabU1ETk9RekpEYzBrNGQzUnZjRFJzT1hkTWFtRTBWR3hVYm5GRlpW
ZDFabTl6T0Mxek5TMWFlVEl0VTB4UmFURk1WR1I2VmtSRlNUWk1aWHBoYzBsb1l6ZFBkMnRpUjFaVlh6
ZHZkMWsxWVhjMFZrZHZhbVZvV0ZkT01tZzBPRXBYV1VsZlUwbENhbVZIYWt4aFVESTBTRFJEZG5Wc1Uz
aG9kV2hRU25ReE1GSklUMmROZHpGWmFFbzBVMnMxY1RKeFVVZFVTbmhLU0VKRWRGRWlmWDAuZXlKQVky
OXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRq
SWlMQ0pvZEhSd2N6b3ZMM0IxY213dWFXMXpaMnh2WW1Gc0xtOXlaeTl6Y0dWakwyOWlMM1l6Y0RBdlky
OXVkR1Y0ZEMwekxqQXVNeTVxYzI5dUlpd2lhSFIwY0hNNkx5OXdkWEpzTG1sdGMyZHNiMkpoYkM1dmNt
Y3ZjM0JsWXk5dllpOTJNM0F3TDJWNGRHVnVjMmx2Ym5NdWFuTnZiaUpkTENKcFpDSTZJblZ5YmpwMWRX
bGtPamt4TlRNM1pHSmhMVFUyWTJJdE1URmxZeTFpWmpZekxUQXlOREpoWXpFek1EQXdNaUlzSW5SNWNH
VWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSkJZMmhwWlhabGJXVnVkRU55WldSbGJu
UnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkTENKdVlXMWxJam9pUlhoaGJY
QnNaU0JWYm1sMlpYSnphWFI1SW4wc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTURBNk1E
QTZNREJhSWl3aWJtRnRaU0k2SWtWNFlXMXdiR1VnVlc1cGRtVnljMmwwZVNCRVpXZHlaV1VpTENKamNt
VmtaVzUwYVdGc1UzVmlhbVZqZENJNmV5SnBaQ0k2SW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01U
SmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSXNJblI1Y0dVaU9sc2lRV05vYVdWMlpXMWxiblJUZFdKcVpX
TjBJbDBzSW1GamFHbGxkbVZ0Wlc1MElqcDdJbWxrSWpvaWRYSnVPblYxYVdRNllUYzBOamRsWmpZdE5U
WmpZaTB4TVdWakxXSm1Oak10TURJME1tRmpNVE13TURBeUlpd2lkSGx3WlNJNld5SkJZMmhwWlhabGJX
VnVkQ0pkTENKamNtVmhkRzl5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkZlN3aWJtRnRaU0k2SWtGamFH
bGxkbVZ0Wlc1MElERWlMQ0pqY21sMFpYSnBZU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pT
NWxaSFV2WVdOb2FXVjJaVzFsYm5SekwyRTNORFkzWldZMkxUVTJZMkl0TVRGbFl5MWlaall6TFRBeU5E
SmhZekV6TURBd01pOWpjbWwwWlhKcFlTSjlMQ0prWlhOamNtbHdkR2x2YmlJNklrRmphR2xsZG1WdFpX
NTBJREVpTENKcGJXRm5aU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWxaSFV2WVdOb2FX
VjJaVzFsYm5SekwzTmhiWEJzWlM1d2JtY2lMQ0owZVhCbElqb2lTVzFoWjJVaWZYMTlMQ0pqY21Wa1pX
NTBhV0ZzVTJOb1pXMWhJanBiZXlKcFpDSTZJbWgwZEhCek9pOHZjSFZ5YkM1cGJYTm5iRzlpWVd3dWIz
Sm5MM053WldNdlkyeHlMM1l5Y0RBdmMyTm9aVzFoTDJwemIyNHZZMnh5WDNZeWNEQmZZMnh5WTNKbFpH
VnVkR2xoYkY5elkyaGxiV0V1YW5OdmJpSXNJblI1Y0dVaU9pSXhSV1JVWldOb1NuTnZibE5qYUdWdFlW
WmhiR2xrWVhSdmNqSXdNVGtpZlYwc0ltbHpjeUk2SW1oMGRIQnpPaTh2WlhoaGJYQnNaUzVsWkhVdmFY
TnpkV1Z5Y3k4MU5qVXdORGtpTENKcWRHa2lPaUoxY200NmRYVnBaRG81TVRVek4yUmlZUzAxTm1OaUxU
RXhaV010WW1ZMk15MHdNalF5WVdNeE16QXdNRElpTENKemRXSWlPaUprYVdRNlpYaGhiWEJzWlRwbFlt
WmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaWZRLmZ5UGVCbmFhUHdZX09kRkhwUjBnbzZu
NHZCc0g5V2t2ZjFrWlBudm14MGJ2MEloSmstbXBJOEJYMzVLblZkaGxhaGFISlRfZnFINkFqNEVqQ0p0
LWlNSG9kdjBuYWZpQS1Kb09nR3BUTkl5c1M3bW5kNmRPcHpLWlM5cUtXWjVyWVJqamhPTTR1RFBpS2xp
MzVkLVZHOWI3QUxaVV9WMlVaYkoxVDdSclpWSjh4Q3BXS2FvbEVrdktfQU5BTUNUUy14Mm5lcklzald2
aUNlNkxFcFRyMFJ3SkhlWEFQUFJKNE42cW5aZUtSX2EtWmdIRmlvVi01QUJXcXFGcUt3bjRlWDhTb05l
SUZCYi1VSnBHZ19xSGwxQzBuR1U0TVBfX05BTGUyN0FuUEhaS0pldTBGdG51WERRMHN3ejJzS1VBdzZh
RnF4eWRSZ1hoVGpJTlI0S1VIUSJdLCJhY2hpZXZlbWVudCI6W3siaWQiOiJ1cm46dXVpZDphNzQ2N2Vm
Ni01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJ0eXBlIjpbIkFjaGlldmVtZW50Il0sImNyZWF0
b3IiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwidHlwZSI6WyJQcm9m
aWxlIl19LCJuYW1lIjoiQWNoaWV2ZW1lbnQgMSIsImNyaXRlcmlhIjp7ImlkIjoiaHR0cHM6Ly9leGFt
cGxlLmVkdS9hY2hpZXZlbWVudHMvYTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyL2Ny
aXRlcmlhIn0sImRlc2NyaXB0aW9uIjoiQWNoaWV2ZW1lbnQgMSIsImltYWdlIjp7ImlkIjoiaHR0cHM6
Ly9leGFtcGxlLmVkdS9hY2hpZXZlbWVudHMvc2FtcGxlLnBuZyIsInR5cGUiOiJJbWFnZSJ9fSx7Imlk
IjoidXJuOnV1aWQ6ZGQ4ODdmMGEtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidHlwZSI6WyJB
Y2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2
NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlldmVtZW50IDIiLCJjcml0ZXJpYSI6
eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL2RkODg3ZjBhLTU2Y2ItMTFlYy1i
ZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvbiI6IkFjaGlldmVtZW50IDIiLCJp
bWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL3NhbXBsZS5wbmciLCJ0
eXBlIjoiSW1hZ2UifX1dLCJhc3NvY2lhdGlvbiI6W3sidHlwZSI6IkFzc29jaWF0aW9uIiwiYXNzb2Np
YXRpb25UeXBlIjoiaXNQYXJlbnRPZiIsInNvdXJjZUlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0x
MWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidGFyZ2V0SWQiOiJ1cm46dXVpZDpkZDg4N2YwYS01NmNiLTEx
ZWMtYmY2My0wMjQyYWMxMzAwMDIifV19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZCI6Imh0dHBzOi8v
cHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX3YycDBfYWNoaWV2
ZW1lbnRjcmVkZW50aWFsX3NjaGVtYS5qc29uIiwidHlwZSI6IjFFZFRlY2hKc29uU2NoZW1hVmFsaWRh
dG9yMjAxOSJ9XSwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsImp0aSI6
Imh0dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJm
ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.AaRZFxdsQhj3NsOR_vwJeZl44HS51lmex0mJ-3yHNcbh
Wx4xTMCdSo-QgG2ACkg561hW6CwQf1Zct63fn7eoYDTfDffbniwJoFVZjLZKXw0bEBbPLkeuqHfn2Uyv
kB65xK5OJkfMWUMnKF66R1CjFICXkjpL-YxZa3PMWa0IfoX1Z5V9EaK9dENs_Inqu_CxYzQjJN7DfMyF
y8CbJErcgcIn1UuKwKvd1UVpBvIYbw-H4KO3CtYFBjgblIBJaYE11WZzcmBPKIJXG4-_qTZbgRtMa9Q8
2al-23BG3rWDqhvoJVgGtsdLaQ6C8Gx7jDtIBr-JROMucz1NMupK3E8uhA

Example 32: Sample Credential D

Credential
Verifiable Credential (with proof)
Verifiable Credential (as JWT)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [ "VerifiableCredential", "ClrCredential" ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": ["Profile"],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": ["ClrSubject"],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": ["VerifiableCredential", "AchievementCredential"],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": ["AchievementSubject"],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": ["Achievement"],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": ["Profile"]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [{
          "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": ["Achievement"],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": ["Profile"]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [{
    "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
    "type": "1EdTechJsonSchemaValidator2019"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
        ],
        "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
        "type": [
          "VerifiableCredential",
          "AchievementCredential"
        ],
        "issuer": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ],
          "name": "Example University"
        },
        "validFrom": "2010-01-01T00:00:00Z",
        "name": "Example University Degree",
        "credentialSubject": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
            "type": [
              "Achievement"
            ],
            "creator": {
              "id": "https://example.edu/issuers/565049",
              "type": [
                "Profile"
              ]
            },
            "name": "Achievement 1",
            "criteria": {
              "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
            },
            "description": "Achievement 1",
            "image": {
              "id": "https://example.edu/achievements/sample.png",
              "type": "Image"
            }
          }
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "proof": [
          {
            "type": "DataIntegrityProof",
            "created": "2024-04-29T10:06:19Z",
            "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
            "cryptosuite": "eddsa-rdfc-2022",
            "proofPurpose": "assertionMethod",
            "proofValue": "z4eFDedxvp7UDXjZPvVNWZU3vyWSYgV8vTBwkd5GSHnUWDGj6WrhTTD5PTRJgKgrVEjqRJPTHTL51b1Y45ERQQiuu"
          }
        ]
      }
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2024-04-29T10:06:19Z",
      "verificationMethod": "https://example.edu/issuers/565049#z6MksjqWB2HRHnZjuz4J581mX2tcEsgHSruU42TuvjtYy9pG",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z2GBkgArvX1eEgjt8xMPSYfrMh7aAvxUj1zN2NukQCHyWmGEJvdMsxsZQFE5BYpm3KMuqxtNjV3AKCZcsHVGM69sp"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "sFDvfd-cgnI-RdGZGAsOBI8AqNqDpms10FslOb2VzVaL1AwAFMSPOLk2iRUWzaYup1MSNI
TN4vUV6-E0E8X_KUJBPKIDafOJmaS3X5w3mIeJRlx15io_qhMCUw0Qrd1XdimfJrmU4zFQzW7boMN7ue
s7L9DTrzx7GF-ArkOya5VX1Cm_mR3qpLdyLvf03NC2CsI8wtop4l9wLja4TlTnqEeWufos8-s5-Zy2-S
LQi1LTdzVDEI6LezasIhc7OwkbGVU_7owY5aw4VGojehXWN2h48JWYI_SIBjeGjLaP24H4CvulSxhuhP
Jt10RHOgMw1YhJ4Sk5q2qQGTJxJHBDtQ"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "ClrCredential"
  ],
  "issuer": {
    "id": "https://example.edu/issuers/565049",
    "type": [
      "Profile"
    ],
    "name": "Example University"
  },
  "validFrom": "2010-01-01T00:00:00Z",
  "name": "Sample Transcript",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": [
      "ClrSubject"
    ],
    "verifiableCredential": [
      "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQ
SIsIm4iOiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT
0xrMmlSVVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxN
WlvX3FoTUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYM
UNtX21SM3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRa
TFMVGR6VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHa
kxhUDI0SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29ud
GV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwua
W1zZ2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvY29udGV4dC0zLjAuMy5qc29uIiwiaHR0cHM6Ly9wdXJsL
mltc2dsb2JhbC5vcmcvc3BlYy9vYi92M3AwL2V4dGVuc2lvbnMuanNvbiJdLCJpZCI6InVybjp1dWlkO
jkxNTM3ZGJhLTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZ
WRlbnRpYWwiLCJBY2hpZXZlbWVudENyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdLCJuYW1lIjoiRXhhbXBsZ
SBVbml2ZXJzaXR5In0sInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwibmFtZSI6IkV4Y
W1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtc
GxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSIsInR5cGUiOlsiQWNoaWV2ZW1lbnRTdWJqZWN0I
l0sImFjaGlldmVtZW50Ijp7ImlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0M
mFjMTMwMDAyIiwidHlwZSI6WyJBY2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9le
GFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlld
mVtZW50IDEiLCJjcml0ZXJpYSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL
2E3NDY3ZWY2LTU2Y2ItMTFlYy1iZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvb
iI6IkFjaGlldmVtZW50IDEiLCJpbWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2Z
W1lbnRzL3NhbXBsZS5wbmciLCJ0eXBlIjoiSW1hZ2UifX19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZ
CI6Imh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX
3YycDBfY2xyY3JlZGVudGlhbF9zY2hlbWEuanNvbiIsInR5cGUiOiIxRWRUZWNoSnNvblNjaGVtYVZhb
GlkYXRvcjIwMTkifV0sImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvaXNzdWVycy81NjUwNDkiLCJqd
GkiOiJ1cm46dXVpZDo5MTUzN2RiYS01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJzdWIiOiJka
WQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEifQ.fyPeBnaaPwY_OdFHpR0go6n4vB
sH9Wkvf1kZPnvmx0bv0IhJk-mpI8BX35KnVdhlahaHJT_fqH6Aj4EjCJt-iMHodv0nafiA-JoOgGpTNI
ysS7mnd6dOpzKZS9qKWZ5rYRjjhOM4uDPiKli35d-VG9b7ALZU_V2UZbJ1T7RrZVJ8xCpWKaolEkvK_A
NAMCTS-x2nerIsjWviCe6LEpTr0RwJHeXAPPRJ4N6qnZeKR_a-ZgHFioV-5ABWqqFqKwn4eX8SoNeIFB
b-UJpGg_qHl1C0nGU4MP__NALe27AnPHZKJeu0FtnuXDQ0swz2sKUAw6aFqxydRgXhTjINR4KUHQ"
    ],
    "achievement": [
      {
        "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 1",
        "criteria": {
          "id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 1",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      },
      {
        "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
        "type": [
          "Achievement"
        ],
        "creator": {
          "id": "https://example.edu/issuers/565049",
          "type": [
            "Profile"
          ]
        },
        "name": "Achievement 2",
        "criteria": {
          "id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac
130002/criteria"
        },
        "description": "Achievement 2",
        "image": {
          "id": "https://example.edu/achievements/sample.png",
          "type": "Image"
        }
      }
    ],
    "association": [
      {
        "type": "Association",
        "associationType": "isParentOf",
        "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
        "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
      }
    ]
  },
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achie
vementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "iss": "https://example.edu/issuers/565049",
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJzRkR2ZmQtY2duSS1SZEdaR0FzT0JJOEFxTnFEcG1zMTBGc2xPYjJWelZhTDFBd0FGTVNQT0xrMmlS
VVd6YVl1cDFNU05JVE40dlVWNi1FMEU4WF9LVUpCUEtJRGFmT0ptYVMzWDV3M21JZUpSbHgxNWlvX3Fo
TUNVdzBRcmQxWGRpbWZKcm1VNHpGUXpXN2JvTU43dWVzN0w5RFRyeng3R0YtQXJrT3lhNVZYMUNtX21S
M3FwTGR5THZmMDNOQzJDc0k4d3RvcDRsOXdMamE0VGxUbnFFZVd1Zm9zOC1zNS1aeTItU0xRaTFMVGR6
VkRFSTZMZXphc0loYzdPd2tiR1ZVXzdvd1k1YXc0VkdvamVoWFdOMmg0OEpXWUlfU0lCamVHakxhUDI0
SDRDdnVsU3hodWhQSnQxMFJIT2dNdzFZaEo0U2s1cTJxUUdUSnhKSEJEdFEifX0.eyJAY29udGV4dCI6
WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3B1cmwuaW1zZ2xv
YmFsLm9yZy9zcGVjL2Nsci92MnAwL2NvbnRleHQtMi4wLjEuanNvbiIsImh0dHBzOi8vcHVybC5pbXNn
bG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4zLmpzb24iLCJodHRwczovL3B1cmwuaW1z
Z2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDovL2V4YW1w
bGUuZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiQ2xy
Q3JlZGVudGlhbCJdLCJpc3N1ZXIiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1
MDQ5IiwidHlwZSI6WyJQcm9maWxlIl0sIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkifSwidmFsaWRG
cm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJuYW1lIjoiU2FtcGxlIFRyYW5zY3JpcHQiLCJjcmVk
ZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMy
MSIsInR5cGUiOlsiQ2xyU3ViamVjdCJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9p
SlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXAzYXlJNmV5SmxJam9pUVZGQlFpSXNJbXQwZVNJNkls
SlRRU0lzSW00aU9pSnpSa1IyWm1RdFkyZHVTUzFTWkVkYVIwRnpUMEpKT0VGeFRuRkVjRzF6TVRCR2My
eFBZakpXZWxaaFRERkJkMEZHVFZOUVQweHJNbWxTVlZkNllWbDFjREZOVTA1SlZFNDBkbFZXTmkxRk1F
VTRXRjlMVlVwQ1VFdEpSR0ZtVDBwdFlWTXpXRFYzTTIxSlpVcFNiSGd4TldsdlgzRm9UVU5WZHpCUmNt
UXhXR1JwYldaS2NtMVZOSHBHVVhwWE4ySnZUVTQzZFdWek4wdzVSRlJ5ZW5nM1IwWXRRWEpyVDNsaE5W
WllNVU50WDIxU00zRndUR1I1VEhabU1ETk9RekpEYzBrNGQzUnZjRFJzT1hkTWFtRTBWR3hVYm5GRlpW
ZDFabTl6T0Mxek5TMWFlVEl0VTB4UmFURk1WR1I2VmtSRlNUWk1aWHBoYzBsb1l6ZFBkMnRpUjFaVlh6
ZHZkMWsxWVhjMFZrZHZhbVZvV0ZkT01tZzBPRXBYV1VsZlUwbENhbVZIYWt4aFVESTBTRFJEZG5Wc1Uz
aG9kV2hRU25ReE1GSklUMmROZHpGWmFFbzBVMnMxY1RKeFVVZFVTbmhLU0VKRWRGRWlmWDAuZXlKQVky
OXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRq
SWlMQ0pvZEhSd2N6b3ZMM0IxY213dWFXMXpaMnh2WW1Gc0xtOXlaeTl6Y0dWakwyOWlMM1l6Y0RBdlky
OXVkR1Y0ZEMwekxqQXVNeTVxYzI5dUlpd2lhSFIwY0hNNkx5OXdkWEpzTG1sdGMyZHNiMkpoYkM1dmNt
Y3ZjM0JsWXk5dllpOTJNM0F3TDJWNGRHVnVjMmx2Ym5NdWFuTnZiaUpkTENKcFpDSTZJblZ5YmpwMWRX
bGtPamt4TlRNM1pHSmhMVFUyWTJJdE1URmxZeTFpWmpZekxUQXlOREpoWXpFek1EQXdNaUlzSW5SNWNH
VWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSkJZMmhwWlhabGJXVnVkRU55WldSbGJu
UnBZV3dpWFN3aWFYTnpkV1Z5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkTENKdVlXMWxJam9pUlhoaGJY
QnNaU0JWYm1sMlpYSnphWFI1SW4wc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTURBNk1E
QTZNREJhSWl3aWJtRnRaU0k2SWtWNFlXMXdiR1VnVlc1cGRtVnljMmwwZVNCRVpXZHlaV1VpTENKamNt
VmtaVzUwYVdGc1UzVmlhbVZqZENJNmV5SnBaQ0k2SW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01U
SmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSXNJblI1Y0dVaU9sc2lRV05vYVdWMlpXMWxiblJUZFdKcVpX
TjBJbDBzSW1GamFHbGxkbVZ0Wlc1MElqcDdJbWxrSWpvaWRYSnVPblYxYVdRNllUYzBOamRsWmpZdE5U
WmpZaTB4TVdWakxXSm1Oak10TURJME1tRmpNVE13TURBeUlpd2lkSGx3WlNJNld5SkJZMmhwWlhabGJX
VnVkQ0pkTENKamNtVmhkRzl5SWpwN0ltbGtJam9pYUhSMGNITTZMeTlsZUdGdGNHeGxMbVZrZFM5cGMz
TjFaWEp6THpVMk5UQTBPU0lzSW5SNWNHVWlPbHNpVUhKdlptbHNaU0pkZlN3aWJtRnRaU0k2SWtGamFH
bGxkbVZ0Wlc1MElERWlMQ0pqY21sMFpYSnBZU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pT
NWxaSFV2WVdOb2FXVjJaVzFsYm5SekwyRTNORFkzWldZMkxUVTJZMkl0TVRGbFl5MWlaall6TFRBeU5E
SmhZekV6TURBd01pOWpjbWwwWlhKcFlTSjlMQ0prWlhOamNtbHdkR2x2YmlJNklrRmphR2xsZG1WdFpX
NTBJREVpTENKcGJXRm5aU0k2ZXlKcFpDSTZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWxaSFV2WVdOb2FX
VjJaVzFsYm5SekwzTmhiWEJzWlM1d2JtY2lMQ0owZVhCbElqb2lTVzFoWjJVaWZYMTlMQ0pqY21Wa1pX
NTBhV0ZzVTJOb1pXMWhJanBiZXlKcFpDSTZJbWgwZEhCek9pOHZjSFZ5YkM1cGJYTm5iRzlpWVd3dWIz
Sm5MM053WldNdlkyeHlMM1l5Y0RBdmMyTm9aVzFoTDJwemIyNHZZMnh5WDNZeWNEQmZZMnh5WTNKbFpH
VnVkR2xoYkY5elkyaGxiV0V1YW5OdmJpSXNJblI1Y0dVaU9pSXhSV1JVWldOb1NuTnZibE5qYUdWdFlW
WmhiR2xrWVhSdmNqSXdNVGtpZlYwc0ltbHpjeUk2SW1oMGRIQnpPaTh2WlhoaGJYQnNaUzVsWkhVdmFY
TnpkV1Z5Y3k4MU5qVXdORGtpTENKcWRHa2lPaUoxY200NmRYVnBaRG81TVRVek4yUmlZUzAxTm1OaUxU
RXhaV010WW1ZMk15MHdNalF5WVdNeE16QXdNRElpTENKemRXSWlPaUprYVdRNlpYaGhiWEJzWlRwbFlt
WmxZakZtTnpFeVpXSmpObVl4WXpJM05tVXhNbVZqTWpFaWZRLmZ5UGVCbmFhUHdZX09kRkhwUjBnbzZu
NHZCc0g5V2t2ZjFrWlBudm14MGJ2MEloSmstbXBJOEJYMzVLblZkaGxhaGFISlRfZnFINkFqNEVqQ0p0
LWlNSG9kdjBuYWZpQS1Kb09nR3BUTkl5c1M3bW5kNmRPcHpLWlM5cUtXWjVyWVJqamhPTTR1RFBpS2xp
MzVkLVZHOWI3QUxaVV9WMlVaYkoxVDdSclpWSjh4Q3BXS2FvbEVrdktfQU5BTUNUUy14Mm5lcklzald2
aUNlNkxFcFRyMFJ3SkhlWEFQUFJKNE42cW5aZUtSX2EtWmdIRmlvVi01QUJXcXFGcUt3bjRlWDhTb05l
SUZCYi1VSnBHZ19xSGwxQzBuR1U0TVBfX05BTGUyN0FuUEhaS0pldTBGdG51WERRMHN3ejJzS1VBdzZh
RnF4eWRSZ1hoVGpJTlI0S1VIUSJdLCJhY2hpZXZlbWVudCI6W3siaWQiOiJ1cm46dXVpZDphNzQ2N2Vm
Ni01NmNiLTExZWMtYmY2My0wMjQyYWMxMzAwMDIiLCJ0eXBlIjpbIkFjaGlldmVtZW50Il0sImNyZWF0
b3IiOnsiaWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwidHlwZSI6WyJQcm9m
aWxlIl19LCJuYW1lIjoiQWNoaWV2ZW1lbnQgMSIsImNyaXRlcmlhIjp7ImlkIjoiaHR0cHM6Ly9leGFt
cGxlLmVkdS9hY2hpZXZlbWVudHMvYTc0NjdlZjYtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyL2Ny
aXRlcmlhIn0sImRlc2NyaXB0aW9uIjoiQWNoaWV2ZW1lbnQgMSIsImltYWdlIjp7ImlkIjoiaHR0cHM6
Ly9leGFtcGxlLmVkdS9hY2hpZXZlbWVudHMvc2FtcGxlLnBuZyIsInR5cGUiOiJJbWFnZSJ9fSx7Imlk
IjoidXJuOnV1aWQ6ZGQ4ODdmMGEtNTZjYi0xMWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidHlwZSI6WyJB
Y2hpZXZlbWVudCJdLCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2
NTA0OSIsInR5cGUiOlsiUHJvZmlsZSJdfSwibmFtZSI6IkFjaGlldmVtZW50IDIiLCJjcml0ZXJpYSI6
eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL2RkODg3ZjBhLTU2Y2ItMTFlYy1i
ZjYzLTAyNDJhYzEzMDAwMi9jcml0ZXJpYSJ9LCJkZXNjcmlwdGlvbiI6IkFjaGlldmVtZW50IDIiLCJp
bWFnZSI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5lZHUvYWNoaWV2ZW1lbnRzL3NhbXBsZS5wbmciLCJ0
eXBlIjoiSW1hZ2UifX1dLCJhc3NvY2lhdGlvbiI6W3sidHlwZSI6IkFzc29jaWF0aW9uIiwiYXNzb2Np
YXRpb25UeXBlIjoiaXNQYXJlbnRPZiIsInNvdXJjZUlkIjoidXJuOnV1aWQ6YTc0NjdlZjYtNTZjYi0x
MWVjLWJmNjMtMDI0MmFjMTMwMDAyIiwidGFyZ2V0SWQiOiJ1cm46dXVpZDpkZDg4N2YwYS01NmNiLTEx
ZWMtYmY2My0wMjQyYWMxMzAwMDIifV19LCJjcmVkZW50aWFsU2NoZW1hIjpbeyJpZCI6Imh0dHBzOi8v
cHVybC5pbXNnbG9iYWwub3JnL3NwZWMvY2xyL3YycDAvc2NoZW1hL2pzb24vY2xyX3YycDBfYWNoaWV2
ZW1lbnRjcmVkZW50aWFsX3NjaGVtYS5qc29uIiwidHlwZSI6IjFFZFRlY2hKc29uU2NoZW1hVmFsaWRh
dG9yMjAxOSJ9XSwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmVkdS9pc3N1ZXJzLzU2NTA0OSIsImp0aSI6
Imh0dHA6Ly9leGFtcGxlLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJm
ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.nhPJN49knEyt6laDRd4e6LZGR0UcDLy0m-el5sS8_GDV
K9QJplbmRFQd5oclmV6lYf0612WIPKY5n_hqsK7aSoPpY4kVReAk8-PLvDvOI4MbDsqZEP5Y1NACyOQ0
cbcTtUZROdcuWFSpKol_xdrmectR7M6Xe_JW-7oVReGoyfpjgSxbNSj6ymBElNHHThz7pj9owxdAmwGV
MK9OczvQg_Bxyi7K1d0RxvR28FeqIn7xd3GCtnu8t5ixhxyFTsPCbKAmQ1H40o27-a3WDCW7KCSsLaKA
eMfn5CmrFvvRxyUixSi1IXhXFMvIN0E3neA74zP5WjvRYs18z2EdTF8I3Q

The credential C is the up-to-date representation because it has a more recent validFrom (2010-03-01T00:00:00Z).

10. Verifiable Credentials Extensions

The Verifiable Credentials Data Model v2.0 standard defines several types of extensions to enable "permissionless innovation". Conformant extensions are tracked in the Verifiable Credentials Extension Registry.

This standard references four VC Extensions:

A Proof Method called DataIntegrityProof defined at Data Integrity EdDSA Cryptosuites v1.0
A Status Method called 1EdTech Revocation List Status Method
A Refresh Method called 1EdTech Credential Refresh Service
A Data Schema Validation Method called 1EdTech JSON Schema Validator 2019

Note

The 1EdTech extensions are designed to work with any verifiable credential and may be contributed to the [VC-EXTENSION-REGISTRY] in the future.

A. Serialization

The data model as described in Appendix § B. Data Models is the canonical structural representation of an Comprehensive Learner Record verifiable credential (ClrCredential). All serializations are representations of that data model in a specific format. This section specifies how the data model is realized in JSON-LD and plain JSON.

A.1 JSON

The data model can be encoded in Javascript Object Notation (JSON) [RFC8259] by mapping property types in the Data Model to JSON types as follows:

Numeric values representable as [IEEE-754] MUST be represented as a JSON Number.
Boolean values MUST be represented as a JSON Boolean.
Sequence values MUST be represented as an JSON Array, NOT as a single value.
Unordered sets (i.e. 0..* and 1..* multiplicities) of values MUST be represented as an JSON Array, NOT as a single value.
Complex types (i.e. not primitive types or derived types) MUST be represented as an JSON Object, NOT as a URI.
Other values MUST be represented as a JSON String.
Null values and empty arrays MUST be ommitted from the serialized JSON. This includes empty Arrays.

A.2 JSON-LD

[JSON-LD] is a JSON-based format used to serialize Linked Data. The syntax is designed to easily integrate into deployed systems already using JSON, and provides a smooth upgrade path from JSON to [JSON-LD]. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.

Instances of the data model are encoded in [JSON-LD] in the same way they are encoded in JSON (Section § A.1 JSON), with the addition of the @context property. The JSON-LD context is described in detail in the [JSON-LD] specification and its use is elaborated on in Section § C. Extending and Profiling this Standard.

Multiple contexts MAY be used or combined to express any arbitrary information about verifiable credentials in idiomatic JSON. The JSON-LD context for all verifiable credentials, available at https://www.w3.org/ns/credentials/v2, is a static document that is never updated and can therefore be downloaded and cached client side. The associated vocabulary document for the Verifiable Credentials Data Model is available at https://www.w3.org/2018/credentials. The JSON-LD context for Comprehensive Learner Record verifiable credentials is available at https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json. The associated vocabulary document for the Comprehensive Learner Record Data Model is available at https://purl.imsglobal.org/spec/clr/v2p0/context/clr_v2p0.html. Comprehensive Learner Record verifiable credentials MUST be serialized with both JSON-LD contexts.

Note

Though this specification requires that a @context property be present, it is not required that the value of the @context property be processed using JSON-LD. This is to support processing using plain JSON libraries, such as those that might be used when the verifiable credential is encoded as a JWT. All libraries or processors MUST ensure that the order of the values in the @context property is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.

Example 33: JSON-LD @context serialization

"@context": [
  "https://www.w3.org/ns/credentials/v2",
  "https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json",
  "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
]

A.2.1 Compacted document form

[JSON-LD11-API] defines a compaction process for [JSON-LD11] documents, applying a context to shorten several fields of the document. The purpose of compaction is making the document to be represented in a form that is tailored to the use of the JSON-LD document directly as JSON.

One of the transformations made by this compaction process is representing properties with only one value as string or maps, while properties with multiple values are represented as an array of strings or maps.

The JSON-LD binding for Comprehensive Learner Record verifiable credentials (ClrCredential) MAY use singular values compaction in some attributes in the data model, such they can be expressed as a string – when having only one value – or an array of strings – when having multiple values.

The properties that may be compacted are listed in the following table:

Class	Property
Achievement	`type`
AchievementCredential	`type`
AchievementCredential	`credentialSchema`
AchievementCredential	`proof`
AchievementCredential	`termsOfUse`
AchievementSubject	`type`
Address	`type`
Alignment	`type`
ClrCredential	`type`
ClrCredential	`credentialSchema`
ClrCredential	`termsOfUse`
ClrCredential	`proof`
EndorsementCredential	`type`
EndorsementCredential	`credentialSchema`
EndorsementCredential	`proof`
EndorsementCredential	`termsOfUse`
EndorsementSubject	`type`
Evidence	`type`
Profile	`type`
Related	`type`
Result	`type`
ResultDescription	`type`
RubricCriterionLevel	`type`
VerifiableCredential	`type`
VerifiableCredential	`proof`
VerifiableCredential	`credentialSchema`
VerifiableCredential	`termsOfUse`

A.2.1.1 Schemas

When using the compacted document form, the resulting document MAY not pass canonical JSON Schema files. This MAY end up in an unsuccessful verification of the credential, specially when the CredentialSchema property is used. To solve this, JSON Schema files compatible with [JSON-LD11-API] compaction process are available online:

Implementations using CredentialSchema MAY rely on this JSON schema files as valid values.

B. Data Models

B.1 ClrCredential Data Models

The data models in this section are specific to Comprehensive Learner Record Standard v2.0.

B.1.1 ClrCredential

A ClrCredential is a CLR with all the properties needed to conform with a Verifiable Credential as defined in the [VC-DATA-MODEL-2.0].

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first three items are the URLs `https://www.w3.org/ns/credentials/v2`, `https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json`, `https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json`.	[1..*]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI `VerifiableCredential`, and one of the items MUST be the IRI `ClrCredential`.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
name	`String`	The name of the CLR. May be displayed by wallet user interfaces.	[1]
description	`String`	Optional description of the CLR. May be displayed by wallet user interfaces.	[0..1]
endorsement	`EndorsementCredential`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with the VC-JWT proof format.	[0..*]
image	`Image`	Optional image representing the CLR. May be displayed by wallet user interfaces. If present, MUST represent a PNG or SVG image. MAY be a 'baked' image.	[0..1]
partial	`Boolean`	True if CLR does not contain all the assertions known by the publisher for the learner at the time the CLR is issued. Useful if you are sending a small set of achievements in real time when they are achieved. If False or omitted, the CLR SHOULD be interpreted as containing all the assertions for the learner known by the publisher at the time of issue.	[0..1]
credentialSubject	`ClrSubject`	The learner that is the subject of this CLR credential.	[1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
issuer	`ProfileRef`	A description of the individual, entity, or organization that issued the credential.	[1]
validFrom	`DateTimeZ`	Timestamp of when the credential becomes valid.	[1]
validUntil	`DateTimeZ`	If the credential has some notion of validity period, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered invalid.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.1.2 ClrSubject

A collection of information about the learner that is the subject of this CLR credential.

Property	Type	Description	Multiplicity
id	`URI`	An identifier for the recipient of the CLR credential. Either `id` or at least one `identifier` is required.	[0..1]
type	`IRI`	The property MUST contain the IRI `ClrSubject`.	[1..*]
identifier	`IdentityObject`	Other identifiers for the recipient of the CLR credential. Either `id` or at least one `identifier`is required.	[0..*]
achievement	`Achievement`	The set of achievements the CLR issuer expects the learner to achieve.	[0..*]
verifiableCredential	`VerifiableCredential`	A set of AchievementCredentials, OpenBadgeCredentials, and other VerifiableCredentials the learner has been awarded. The credential issuers may not be the same entity as the ClrCredential issuer, but the ClrCredential's credential subject is guaranteed to be the same person as the credential subject of each included credential, even if they use different identifiers.	[1..*]
association	`Association`	Associations describe the semantic relationship between source and target achievements and their assertions.	[0..*]
This class can be extended with additional properties.

B.1.3 Association

An Association describes the semantic relationship between two achievements and the credentials that assert those achievements.

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be 'Association'.	[1]
associationType	`AssociationType Enumeration`	The type of relationship between a source achievement and a target achievement. For example the source achievement is the child of the target achievement.	[1]
sourceId	`URI`	The `id` of the source achievement.	[1]
targetId	`URI`	The `id` of the target achievement.	[1]

B.1.4 AssociationType Enumeration

A vocabulary of association types. Associations describe the semantic relationship between two achievements.

Term	Description
exactMatchOf	The target is derived from the source.
isChildOf	To represent the structural relationship in a taxonomy between parent and child. The source is a child of the target.
isParentOf	To represent the structural relationship in a taxonomy between parent and child. The source is a parent of the target.
isPartOf	The source of the association is included either physically or logically in the target. This classifies an Achievement as being logically or semantically contained as a subset of the target.
isPeerOf	The source is a peer of the target. Where IsRelatedTo is intended to show relationships within a topic or domain, isPeerOf shows an approximation of relationships across topics or domains.
isRelatedTo	The source of the association is related to the target in some way that is not better described by another association type.
precedes	The source of the association comes before the target of the association in time or order.
replacedBy	The source of the association has been supplanted by, displaced by, or superseded by the target of the association.

B.2 CLR Proof Data Models

The data models in this section are used by the § 7.2 JSON Web Token Proof Format applied to a ClrCredential.

B.2.1 ClrCredentialJwtPayload

Represents a Comprehensive Learner Record (CLR) expressed to conform with the vc claim in JSON Web Token Proof Format [VC-DATA-MODEL]. Nested credentials are represented as Compact JWS strings.

Property	Type	Description	Multiplicity
credentialSubject	`ClrSubjectJwtPayload`	Claims about the learner.	[1]
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/ns/credentials/v2'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[0..1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential'.	[1..*]
issuer	`ProfileRef`	A description of the individual, entity, or organization that issued the credential.	[1]
validFrom	`DateTimeZ`	Timestamp of when the credential becomes valid.	[1]
validUntil	`DateTimeZ`	If the credential has some notion of validity period, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered invalid.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first three items are the URLs `https://www.w3.org/ns/credentials/v2`, `https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json`, `https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json`.	[1..*]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI `VerifiableCredential`, and one of the items MUST be the IRI `ClrCredential`.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
name	`String`	The name of the CLR. May be displayed by wallet user interfaces.	[1]
description	`String`	Optional description of the CLR. May be displayed by wallet user interfaces.	[0..1]
endorsement	`EndorsementCredential`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with the VC-JWT proof format.	[0..*]
image	`Image`	Optional image representing the CLR. May be displayed by wallet user interfaces. If present, MUST represent a PNG or SVG image. MAY be a 'baked' image.	[0..1]
partial	`Boolean`	True if CLR does not contain all the assertions known by the publisher for the learner at the time the CLR is issued. Useful if you are sending a small set of achievements in real time when they are achieved. If False or omitted, the CLR SHOULD be interpreted as containing all the assertions for the learner known by the publisher at the time of issue.	[0..1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
This class can be extended with additional properties.

B.2.2 ClrSubjectJwtPayload

Claims about the subject learner.

Property	Type	Description	Multiplicity
verifiableCredential	`CompactJws`	The set of achievements the publisher claims have been awarded to the learner in Compact JWS format. The CLR issuer publisher may not be the same entity as the assertion issuers, but the CLR subject MUST be the same entity as the assertion subjects even if they have different indentifiers.	[1..*]
id	`URI`	The identity of the credential subject.	[0..1]
id	`URI`	An identifier for the recipient of the CLR credential. Either `id` or at least one `identifier` is required.	[0..1]
type	`IRI`	The property MUST contain the IRI `ClrSubject`.	[1..*]
identifier	`IdentityObject`	Other identifiers for the recipient of the CLR credential. Either `id` or at least one `identifier`is required.	[0..*]
achievement	`Achievement`	The set of achievements the CLR issuer expects the learner to achieve.	[0..*]
association	`Association`	Associations describe the semantic relationship between source and target achievements and their assertions.	[0..*]
This class can be extended with additional properties.

B.3 CLR API Data Models

The data models in this section are used by the § 5. CLR Standard API.

B.3.1 GetClrCredentialsResponse

Property	Type	Description	Multiplicity
credential	`ClrCredential`	ClrCredentials that have not been signed with the VC-JWT Proof Format MUST be in the `credential` array.	[0..*]
compactJwsString	`CompactJws`	ClrCredentials that have been signed with the VC-JWT Proof Format MUST be in the `compactJwsString` array.	[0..*]

B.4 Shared Credential Data Models

The data models in this section are shared by Open Badges Specification v3.0 and Comprehensive Learner Record Standard v2.0.

B.4.1 Achievement

A collection of information about the accomplishment recognized by the Assertion. Many assertions may be created corresponding to one Achievement.

Property	Type	Description	Multiplicity
id	`URI`	Unique URI for the Achievement.	[1]
type	`IRI`		[1..*]
alignment	`Alignment`	An object describing which objectives or educational standards this achievement aligns to, if any.	[0..*]
achievementType	`AchievementType Enumeration`	The type of achievement. This is an extensible vocabulary.	[0..1]
creator	`Profile`	The person or organization that created the achievement definition.	[0..1]
creditsAvailable	`Float`	Credit hours associated with this entity, or credit hours possible. For example 3.0.	[0..1]
criteria	`Criteria`	Criteria describing how to earn the achievement.	[1]
description	`String`	A short description of the achievement.	[1]
endorsement	`EndorsementCredential`	Allows endorsers to make specific claims about the Achievement. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the Achievement. These endorsements are signed with the VC-JWT proof format.	[0..*]
fieldOfStudy	`String`	Category, subject, area of study, discipline, or general branch of knowledge. Examples include Business, Education, Psychology, and Technology.	[0..1]
humanCode	`String`	The code, generally human readable, associated with an achievement.	[0..1]
image	`Image`	An image representing the achievement.	[0..1]
inLanguage	`LanguageCode`	The language of the achievement.	[0..1]
name	`String`	The name of the achievement.	[1]
otherIdentifier	`IdentifierEntry`	A list of identifiers for the described entity.	[0..*]
related	`Related`	The related property identifies another Achievement that should be considered the same for most purposes. It is primarily intended to identify alternate language editions or previous versions of Achievements.	[0..*]
resultDescription	`ResultDescription`	The set of result descriptions that may be asserted as results with this achievement.	[0..*]
specialization	`String`	Name given to the focus, concentration, or specific area of study defined in the achievement. Examples include 'Entrepreneurship', 'Technical Communication', and 'Finance'.	[0..1]
tag	`String`	One or more short, human-friendly, searchable, keywords that describe the type of achievement.	[0..*]
version	`String`	The version property allows issuers to set a version string for an Achievement. This is particularly useful when replacing a previous version with an update.	[0..1]
This class can be extended with additional properties.

B.4.2 AchievementCredential

AchievementCredentials are representations of an awarded achievement, used to share information about a achievement belonging to one earner. Maps to a Verifiable Credential as defined in the [VC-DATA-MODEL-2.0]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/ns/credentials/v2', and the second item is a URI with the value 'https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential', and one of the items MUST be the URI 'AchievementCredential' or the URI 'OpenBadgeCredential'.	[1..*]
name	`String`	The name of the credential for display purposes in wallets. For example, in a list of credentials and in detail views.	[0..1]
description	`String`	The short description of the credential for display purposes in wallets.	[0..1]
image	`Image`	The image representing the credential for display purposes in wallets.	[0..1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
credentialSubject	`AchievementSubject`	The recipient of the achievement.	[1]
endorsement	`EndorsementCredential`	Allows endorsers to make specific claims about the credential, and the achievement and profiles in the credential. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the credential, and the achievement and profiles in the credential. These endorsements are signed with the VC-JWT proof format.	[0..*]
evidence	`Evidence`	A description of the work that the recipient did to earn the achievement. This can be a page that links out to other pages if linking directly to the work is infeasible.	[0..*]
issuer	`ProfileRef`	A description of the individual, entity, or organization that issued the credential.	[1]
validFrom	`DateTimeZ`	Timestamp of when the credential becomes valid.	[1]
validUntil	`DateTimeZ`	If the credential has some notion of validity period, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered invalid.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.4.3 AchievementSubject

A collection of information about the recipient of an achievement. Maps to Credential Subject in [VC-DATA-MODEL-2.0].

Property	Type	Description	Multiplicity
id	`URI`	An identifier for the Credential Subject. Either `id` or at least one `identifier` MUST be supplied.	[0..1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'AchievementSubject'.	[1..*]
activityEndDate	`DateTime`	The datetime the activity ended.	[0..1]
activityStartDate	`DateTime`	The datetime the activity started.	[0..1]
creditsEarned	`Float`	The number of credits earned, generally in semester or quarter credit hours. This field correlates with the Achievement `creditsAvailable` field.	[0..1]
achievement	`Achievement`	The achievement being awarded.	[1]
identifier	`IdentityObject`	Other identifiers for the recipient of the achievement. Either `id` or at least one `identifier` MUST be supplied.	[0..*]
image	`Image`	An image representing this user's achievement. If present, this must be a PNG or SVG image, and should be prepared via the 'baking' instructions. An 'unbaked' image for the achievement is defined in the Achievement class and should not be duplicated here.	[0..1]
licenseNumber	`String`	The license number that was issued with this credential.	[0..1]
narrative	`Markdown`	A narrative that connects multiple pieces of evidence. Likely only present at this location if evidence is a multi-value array.	[0..1]
result	`Result`	The set of results being asserted.	[0..*]
role	`String`	Role, position, or title of the learner when demonstrating or performing the achievement or evidence of learning being asserted. Examples include 'Student President', 'Intern', 'Captain', etc.	[0..1]
source	`Profile`	The person, organization, or system that assessed the achievement on behalf of the issuer. For example, a school may assess the achievement, while the school district issues the credential.	[0..1]
term	`String`	The academic term in which this assertion was achieved.	[0..1]
This class can be extended with additional properties.

B.4.4 Address

An address for the described entity.

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Address'.	[1..*]
addressCountry	`String`	A country.	[0..1]
addressCountryCode	`CountryCode`	A country code. The value must be a ISO 3166-1 alpha-2 country code [ISO3166-1].	[0..1]
addressRegion	`String`	A region within the country.	[0..1]
addressLocality	`String`	A locality within the region.	[0..1]
streetAddress	`String`	A street address within the locality.	[0..1]
postOfficeBoxNumber	`String`	A post office box number for PO box addresses.	[0..1]
postalCode	`String`	A postal code.	[0..1]
geo	`GeoCoordinates`	The geographic coordinates of the location.	[0..1]
This class can be extended with additional properties.

B.4.5 Alignment

Describes an alignment between an achievement and a node in an educational framework.

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Alignment'.	[1..*]
targetCode	`String`	If applicable, a locally unique string identifier that identifies the alignment target within its framework and/or targetUrl.	[0..1]
targetDescription	`String`	Short description of the alignment target.	[0..1]
targetName	`String`	Name of the alignment.	[1]
targetFramework	`String`	Name of the framework the alignment target.	[0..1]
targetType	`AlignmentTargetType Enumeration`	The type of the alignment target node.	[0..1]
targetUrl	`URL`	URL linking to the official description of the alignment target, for example an individual standard within an educational framework.	[1]
This class can be extended with additional properties.

B.4.6 Criteria

Descriptive metadata about the achievements necessary to be recognized with an assertion of a particular achievement. This data is added to the Achievement class so that it may be rendered when the achievement assertion is displayed, instead of simply a link to human-readable criteria external to the achievement. Embedding criteria allows either enhancement of an external criteria page or increased portability and ease of use by allowing issuers to skip hosting the formerly-required external criteria page altogether. Criteria is used to allow would-be recipients to learn what is required of them to be recognized with an assertion of a particular achievement. It is also used after the assertion is awarded to a recipient to let those inspecting earned achievements know the general requirements that the recipients met in order to earn it.

Note

Implementations SHOULD provide, at least, one of the id or narrative fields.

Property	Type	Description	Multiplicity
id	`URI`	The URI of a webpage that describes in a human-readable format the criteria for the achievement.	[0..1]
narrative	`Markdown`	A narrative of what is needed to earn the achievement. Markdown is allowed.	[0..1]
This class can be extended with additional properties.

B.4.7 EndorsementCredential

A verifiable credential that asserts a claim about an entity. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/ns/credentials/v2', and the second item is a URI with the value 'https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json'.	[1..*]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential', and one of the items MUST be the URI 'EndorsementCredential'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
name	`String`	The name of the credential for display purposes in wallets. For example, in a list of credentials and in detail views.	[1]
description	`String`	The short description of the credential for display purposes in wallets.	[0..1]
credentialSubject	`EndorsementSubject`	The individual, entity, organization, assertion, or achievement that is endorsed and the endorsement comment.	[1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
issuer	`ProfileRef`	A description of the individual, entity, or organization that issued the credential.	[1]
validFrom	`DateTimeZ`	Timestamp of when the credential becomes valid.	[1]
validUntil	`DateTimeZ`	If the credential has some notion of validity period, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered invalid.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.4.8 EndorsementSubject

A collection of information about the subject of the endorsement.

Property	Type	Description	Multiplicity
id	`URI`	The identifier of the individual, entity, organization, assertion, or achievement that is endorsed.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'EndorsementSubject'.	[1..*]
endorsementComment	`Markdown`	Allows endorsers to make a simple claim in writing about the entity.	[0..1]
This class can be extended with additional properties.

B.4.9 Evidence

Descriptive metadata about evidence related to the achievement assertion. Each instance of the evidence class present in an assertion corresponds to one entity, though a single entry can describe a set of items collectively. There may be multiple evidence entries referenced from an assertion. The narrative property is also in scope of the assertion class to provide an overall description of the achievement related to the assertion in rich text. It is used here to provide a narrative of achievement of the specific entity described. If both the description and narrative properties are present, displayers can assume the narrative value goes into more detail and is not simply a recapitulation of description.

Property	Type	Description	Multiplicity
id	`URI`	The URL of a webpage presenting evidence of achievement or the evidence encoded as a Data URI. The schema of the webpage is undefined.	[0..1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Evidence'.	[1..*]
narrative	`Markdown`	A narrative that describes the evidence and process of achievement that led to an assertion.	[0..1]
name	`String`	A descriptive title of the evidence.	[0..1]
description	`String`	A longer description of the evidence.	[0..1]
genre	`String`	A string that describes the type of evidence. For example, Poetry, Prose, Film.	[0..1]
audience	`String`	A description of the intended audience for a piece of evidence.	[0..1]
This class can be extended with additional properties.

B.4.10 GeoCoordinates

The geographic coordinates of a location.

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'GeoCoordinates'.	[1]
latitude	`Float`	The latitude of the location [WGS84].	[1]
longitude	`Float`	The longitude of the location [WGS84].	[1]
This class can be extended with additional properties.

B.4.11 IdentifierEntry

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'IdentifierEntry'.	[1]
identifier	`Identifier`	An identifier.	[1]
identifierType	`IdentifierTypeEnum Enumeration`	The identifier type.	[1]

B.4.12 IdentityObject

A collection of information about the recipient of an achievement.

Property	Type	Description	Multiplicity
type	`IRI`	MUST be the IRI 'IdentityObject'.	[1]
hashed	`Boolean`	Whether or not the `identityHash` value is hashed.	[1]
identityHash	`IdentityHash`	Either the IdentityHash of the identity or the plaintext value. If it's possible that the plaintext transmission and storage of the identity value would leak personally identifiable information where there is an expectation of privacy, it is strongly recommended that an IdentityHash be used.	[1]
identityType	`IdentifierTypeEnum Enumeration`	The identity type.	[1]
salt	`String`	If the `identityHash` is hashed, this should contain the string used to salt the hash. If this value is not provided, it should be assumed that the hash was not salted.	[0..1]

B.4.13 Image

Metadata about images that represent assertions, achieve or profiles. These properties can typically be represented as just the id string of the image, but using a fleshed-out document allows for including captions and other applicable metadata.

Property	Type	Description	Multiplicity
id	`URI`	The URI or Data URI of the image.	[1]
type	`IRI`	MUST be the IRI 'Image'.	[1]
caption	`String`	The caption for the image.	[0..1]

B.4.14 Profile

A Profile is a collection of information that describes the entity or organization using Open Badges. Issuers must be represented as Profiles, and endorsers, or other entities may also be represented using this vocabulary. Each Profile that represents an Issuer may be referenced in many BadgeClasses that it has defined. Anyone can create and host an Issuer file to start issuing Open Badges. Issuers may also serve as recipients of Open Badges, often identified within an Assertion by specific properties, like their url or contact email address.

Property	Type	Description	Multiplicity
id	`URI`	Unique URI for the Issuer/Profile file.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Profile'.	[1..*]
name	`String`	The name of the entity or organization.	[0..1]
url	`URI`	The homepage or social media profile of the entity, whether individual or institutional. Should be a URL/URI Accessible via HTTP.	[0..1]
phone	`PhoneNumber`	A phone number.	[0..1]
description	`String`	A short description of the issuer entity or organization.	[0..1]
endorsement	`EndorsementCredential`	Allows endorsers to make specific claims about the individual or organization represented by this profile. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the individual or organization represented by this profile. These endorsements are signed with the VC-JWT proof format.	[0..*]
image	`Image`	An image representing the issuer. This must be a PNG or SVG image.	[0..1]
email	`EmailAddress`	An email address.	[0..1]
address	`Address`	An address for the individual or organization.	[0..1]
otherIdentifier	`IdentifierEntry`	A list of identifiers for the described entity.	[0..*]
official	`String`	If the entity is an organization, `official` is the name of an authorized official of the organization.	[0..1]
parentOrg	`Profile`	The parent organization of the entity.	[0..1]
familyName	`String`	Family name. In the western world, often referred to as the 'last name' of a person.	[0..1]
givenName	`String`	Given name. In the western world, often referred to as the 'first name' of a person.	[0..1]
additionalName	`String`	Additional name. Includes what is often referred to as 'middle name' in the western world.	[0..1]
patronymicName	`String`	Patronymic name.	[0..1]
honorificPrefix	`String`	Honorific prefix(es) preceding a person's name (e.g. 'Dr', 'Mrs' or 'Mr').	[0..1]
honorificSuffix	`String`	Honorific suffix(es) following a person's name (e.g. 'M.D, PhD').	[0..1]
familyNamePrefix	`String`	Family name prefix. As used in some locales, this is the leading part of a family name (e.g. 'de' in the name 'de Boer').	[0..1]
dateOfBirth	`Date`	Birthdate of the person.	[0..1]
This class can be extended with additional properties.

Identifies a related achievement.

Property	Type	Description	Multiplicity
id	`URI`	The related achievement.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Related'.	[1..*]
inLanguage	`LanguageCode`	The language of the related achievement.	[0..1]
version	`String`	The version of the related achievement.	[0..1]
This class can be extended with additional properties.

B.4.16 Result

Describes a result that was achieved.

Property	Type	Description	Multiplicity
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'Result'.	[1..*]
achievedLevel	`URI`	If the result represents an achieved rubric criterion level (e.g. Mastered), the value is the `id` of the RubricCriterionLevel in linked ResultDescription.	[0..1]
alignment	`Alignment`	The alignments between this result and nodes in external frameworks. This set of alignments are in addition to the set of alignments defined in the corresponding ResultDescription object.	[0..*]
resultDescription	`URI`	An achievement can have many result descriptions describing possible results. The value of `resultDescription` is the `id` of the result description linked to this result. The linked result description must be in the achievement that is being asserted.	[0..1]
status	`ResultStatusType Enumeration`	The status of the achievement. Required if `resultType` of the linked ResultDescription is Status.	[0..1]
value	`String`	A string representing the result of the performance, or demonstration, of the achievement. For example, 'A' if the recipient received an A grade in class.	[0..1]
This class can be extended with additional properties.

B.4.17 ResultDescription

Describes a possible achievement result.

Property	Type	Description	Multiplicity
id	`URI`	The unique URI for this result description. Required so a result can link to this result description.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'ResultDescription'.	[1..*]
alignment	`Alignment`	Alignments between this result description and nodes in external frameworks.	[0..*]
allowedValue	`String`	An ordered list of allowed values. The values should be ordered from low to high as determined by the achievement creator.	[0..*]
name	`String`	The name of the result.	[1]
requiredLevel	`URI`	The `id` of the rubric criterion level required to pass as determined by the achievement creator.	[0..1]
requiredValue	`String`	A value from `allowedValue` or within the range of `valueMin` to `valueMax` required to pass as determined by the achievement creator.	[0..1]
resultType	`ResultType Enumeration`	The type of result this description represents. This is an extensible enumerated vocabulary.	[1]
rubricCriterionLevel	`RubricCriterionLevel`	An ordered array of rubric criterion levels that may be asserted in the linked result. The levels should be ordered from low to high as determined by the achievement creator.	[0..*]
valueMax	`String`	The maximum possible `value` that may be asserted in a linked result.	[0..1]
valueMin	`String`	The minimum possible `value` that may be asserted in a linked result.	[0..1]
This class can be extended with additional properties.

B.4.18 RubricCriterionLevel

Describes a rubric criterion level.

Property	Type	Description	Multiplicity
id	`URI`	The unique URI for this rubric criterion level. Required so a result can link to this rubric criterion level.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI 'RubricCriterionLevel'.	[1..*]
alignment	`Alignment`	Alignments between this rubric criterion level and a rubric criterion levels defined in external frameworks.	[0..*]
description	`String`	Description of the rubric criterion level.	[0..1]
level	`String`	The rubric performance level in terms of success.	[0..1]
name	`String`	The name of the rubric criterion level.	[1]
points	`String`	The points associated with this rubric criterion level.	[0..1]
This class can be extended with additional properties.

B.4.19 VerifiableCredential

A Verifiable Credential as defined in the [VC-DATA-MODEL-2.0]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/ns/credentials/v2'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[0..1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential'.	[1..*]
issuer	`ProfileRef`	A description of the individual, entity, or organization that issued the credential.	[1]
validFrom	`DateTimeZ`	Timestamp of when the credential becomes valid.	[1]
validUntil	`DateTimeZ`	If the credential has some notion of validity period, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered invalid.	[0..1]
credentialSubject	`CredentialSubject`	The subject of the credential.	[1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.4.20 ProfileRef

A description of the individual, entity, or organization that issued the credential. Either a URI with the Unique URI for the Issuer/Profile file, or a Profile object MUST be supplied.

The ultimate representation of this class is a choice of exactly one of the classes in the following set:

Type Description

Profile A Profile is a collection of information that describes the entity or organization using Open Badges. Issuers must be represented as Profiles, and endorsers, or other entities may also be represented using this vocabulary. Each Profile that represents an Issuer may be referenced in many BadgeClasses that it has defined. Anyone can create and host an Issuer file to start issuing Open Badges. Issuers may also serve as recipients of Open Badges, often identified within an Assertion by specific properties, like their url or contact email address.

URI A NormalizedString that respresents a Uniform Resource Identifier (URI).

B.4.21 CredentialSchema

Identify the type and location of a data schema.

Property	Type	Description	Multiplicity
id	`URI`	The value MUST be a URI identifying the schema file. One instance of `CredentialSchema` MUST have an `id` that is the URL of the JSON Schema for this credential defined by this specification.	[1]
type	`IRI`	The value MUST identify the type of data schema validation. One instance of `CredentialSchema` MUST have a `type` of 'JsonSchemaValidator2019'.	[1]
This class can be extended with additional properties.

B.4.22 CredentialStatus

The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.

Property	Type	Description	Multiplicity
id	`URI`	The value MUST be the URL of the issuer's credential status method.	[1]
type	`IRI`	The name of the credential status method.	[1]
This class can be extended with additional properties.

B.4.23 CredentialSubject

Claims about the credential subject. Maps to Credential Subject as defined in the [VC-DATA-MODEL-2.0].

Property	Type	Description	Multiplicity
id	`URI`	The identity of the credential subject.	[0..1]
This class can be extended with additional properties.

B.4.24 Proof

A JSON-LD Linked Data proof.

Property	Type	Description	Multiplicity
type	`IRI`	Signature suite used to produce proof.	[1]
created	`DateTime`	Date the proof was created.	[0..1]
cryptosuite	`String`	The suite used to create the proof.	[0..1]
challenge	`String`	A value chosen by the verifier to mitigate authentication proof replay attacks.	[0..1]
domain	`String`	The domain of the proof to restrict its use to a particular target.	[0..1]
nonce	`String`	A value chosen by the creator of proof to randomize proof values for privacy purposes.	[0..1]
proofPurpose	`String`	The purpose of the proof to be used with `verificationMethod`. MUST be 'assertionMethod'.	[0..1]
proofValue	`String`	Value of the proof.	[0..1]
verificationMethod	`URI`	The URL of the public key that can verify the signature.	[0..1]
This class can be extended with additional properties.

B.4.25 RefreshService

The information in RefreshService is used to refresh the verifiable credential.

Property	Type	Description	Multiplicity
id	`URI`	The value MUST be the URL of the issuer's refresh service.	[1]
type	`IRI`	The name of the refresh service method.	[1]
This class can be extended with additional properties.

B.4.26 TermsOfUse

Terms of use can be utilized by an issuer or a holder to communicate the terms under which a verifiable credential or verifiable presentation was issued

Property	Type	Description	Multiplicity
id	`URI`	The value MUST be a URI identifying the term of use.	[0..1]
type	`IRI`	The value MUST identify the type of the terms of use.	[1]
This class can be extended with additional properties.

B.4.27 Context

JSON-LD Context. Either a URI with the context definition or a Map with a local context definition MUST be supplied.

The ultimate representation of this class is a choice of exactly one of the classes in the following set:

Type	Description
`Map`	A map representing an object with unknown, arbitrary properties
`URI`	A `NormalizedString` that respresents a Uniform Resource Identifier (URI).

B.4.28 Map

A map representing an object with unknown, arbitrary properties

Property	Type	Description	Multiplicity
This class can be extended with additional properties.

B.4.29 AchievementType Enumeration

The type of achievement, for example 'Award' or 'Certification'. This is an extensible enumerated vocabulary. Extending the vocabulary makes use of a naming convention.

Term	Description
Achievement	Represents a generic achievement.
ApprenticeshipCertificate	Credential earned through work-based learning and earn-and-learn models that meet standards and are applicable to industry trades and professions. This is an exact match of `ApprenticeshipCertificate` in [CTDL-TERMS].
Assessment	Direct, indirect, formative, and summative evaluation or estimation of the nature, ability, or quality of an entity, performance, or outcome of an action. This is an exact match of `Assessment` in [CTDL-TERMS].
Assignment	Represents the result of a curricular, or co-curricular assignment or exam.
AssociateDegree	College/university award for students typically completing the first one to two years of post secondary school education. Equivalent to an award at UNESCO ISCED 2011, Level 5. This is an exact match of `AssociateDegree` in [CTDL-TERMS].
Award	Represents an award.
Badge	Visual symbol containing verifiable claims in accordance with the Open Badges specification and delivered digitally. This is an exact match of `Badge` in [CTDL-TERMS].
BachelorDegree	College/university award for students typically completing three to five years of education where course work and activities advance skills beyond those of the first one to two years of college/university study. Equivalent to an award at UNESCO ISCED 2011, Level 6. Use for 5-year cooperative (work-study) programs. A cooperative plan provides for alternate class attendance and employment in business, industry, or government; thus, it allows students to combine actual work experience with their college studies. Also includes bachelor's degrees in which the normal 4 years of work are completed in 3 years. This is an exact match of `BachelorDegree` in [CTDL-TERMS].
Certificate	Credential that designates requisite knowledge and skills of an occupation, profession, or academic program. This is an exact match of `Certificate` in [CTDL-TERMS].
CertificateOfCompletion	Credential that acknowledges completion of an assignment, training or other activity. A record of the activity may or may not exist, and the credential may or may not be designed as preparation for another resource such as a credential, assessment, or learning opportunity. This is an exact match of `CertificateOfCompletion` in [CTDL-TERMS].
Certification	Time-limited, revocable, renewable credential awarded by an authoritative body for demonstrating the knowledge, skills, and abilities to perform specific tasks or an occupation. Certifications can typically be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process. Description of revocation criteria for a specific Certification should be defined using Revocation Profile. This is an exact match of `Certification` in [CTDL-TERMS].
CommunityService	Represents community service.
Competency	Measurable or observable knowledge, skill, or ability necessary to successful performance of a person. This is an exact match of `Competency` in [CTDL-ASN-TERMS].
Course	Represents a course completion.
CoCurricular	Represents a co-curricular activity.
Degree	Academic credential conferred upon completion of a program or course of study, typically over multiple years at a college or university. This is an exact match of `Degree` in [CTDL-TERMS].
Diploma	Credential awarded by educational institutions for successful completion of a course of study or its equivalent. This is an exact match of `Diploma` in [CTDL-TERMS].
DoctoralDegree	Highest credential award for students who have completed both a bachelor's degree and a master's degree or their equivalent as well as independent research and/or a significant project or paper. Equivalent to UNESCO ISCED, Level 8. This is an exact match of `DoctoralDegree` in [CTDL-TERMS].
Fieldwork	Represents practical activities that are done away school, college, or place of work. Includes internships and practicums.
GeneralEducationDevelopment	(GED) Credential awarded by examination that demonstrates that an individual has acquired secondary school-level academic skills. Equivalent to a secondary school diploma, based on passing a state- or province-selected examination such as GED, HiSET, or TASC; or to an award at UNESCO ISCED 2011 Levels 2 or 3. This is an exact match of `GeneralEducationDevelopment` in [CTDL-TERMS].
JourneymanCertificate	Credential awarded to skilled workers on successful completion of an apprenticeship in industry trades and professions. This is an exact match of `JourneymanCertificate` in [CTDL-TERMS].
LearningProgram	Set of learning opportunities that leads to an outcome, usually a credential like a degree or certificate. This is an exact match of `LearningProgram` in [CTDL-TERMS].
License	Credential awarded by a government agency or other authorized organization that constitutes legal authority to do a specific job and/or utilize a specific item, system or infrastructure and are typically earned through some combination of degree or certificate attainment, certifications, assessments, work experience, and/or fees, and are time-limited and must be renewed periodically. This is an exact match of `License` in [CTDL-TERMS].
Membership	Represents membership.
ProfessionalDoctorate	Doctoral degree conferred upon completion of a program providing the knowledge and skills for the recognition, credential, or license required for professional practice. Equivalent to an award at UNESCO ISCED 2011, Level 8. This is an exact match of `ProfessionalDoctorate` in [CTDL-TERMS].
QualityAssuranceCredential	Credential assuring that an organization, program, or awarded credential meets prescribed requirements and may include development and administration of qualifying examinations. This is an exact match of `QualityAssuranceCredential` in [CTDL-TERMS].
MasterCertificate	Credential awarded upon demonstration through apprenticeship of the highest level of skills and performance in industry trades and professions. This is an exact match of `MasterCertificate` in [CTDL-TERMS].
MasterDegree	Credential awarded for a graduate level course of study where course work and activities advance skills beyond those of the bachelor's degree or its equivalent. Equivalent to an award at UNESCO ISCED 2011, Level 7. This is an exact match of `MasterDegree` in [CTDL-TERMS].
MicroCredential	Credential that addresses a subset of field-specific knowledge, skills, or competencies; often developmental with relationships to other micro-credentials and field credentials. This is an exact match of `MicroCredential` in [CTDL-TERMS].
ResearchDoctorate	Doctoral degree conferred for advanced work beyond the master level, including the preparation and defense of a thesis or dissertation based on original research, or the planning and execution of an original project demonstrating substantial artistic or scholarly achievement. Equivalent to an award at UNESCO ISCED 2011, Level 8. This is an exact match of `ResearchDoctorate` in [CTDL-TERMS].
SecondarySchoolDiploma	Diploma awarded by secondary education institutions for successful completion of a secondary school program of study. Equivalent to an award at UNESCO ISCED 2011 Levels 2 or 3. This is an exact match of `SecondarySchoolDiploma` in [CTDL-TERMS].
This enumeration can be extended with new, proprietary terms. The new terms must start with the substring 'ext:'.

B.4.30 AlignmentTargetType Enumeration

The type of the alignment target node in the target framework.

Term	Description
ceasn:Competency	An alignment to a CTDL-ASN/CTDL competency published by Credential Engine.
ceterms:Credential	An alignment to a CTDL Credential published by Credential Engine.
CFItem	An alignment to a CASE Framework Item.
CFRubric	An alignment to a CASE Framework Rubric.
CFRubricCriterion	An alignment to a CASE Framework Rubric Criterion.
CFRubricCriterionLevel	An alignment to a CASE Framework Rubric Criterion Level.
CTDL	An alignment to a Credential Engine Item.
This enumeration can be extended with new, proprietary terms. The new terms must start with the substring 'ext:'.

B.4.31 IdentifierTypeEnum Enumeration

Term	Description
name
sourcedId
systemId
productId
userName
accountId
emailAddress
nationalIdentityNumber
isbn
issn
lisSourcedId
oneRosterSourcedId
sisSourcedId
ltiContextId
ltiDeploymentId
ltiToolId
ltiPlatformId
ltiUserId
identifier
This enumeration can be extended with new, proprietary terms. The new terms must start with the substring 'ext:'.

B.4.32 ResultType Enumeration

The type of result. This is an extensible enumerated vocabulary. Extending the vocabulary makes use of a naming convention.

Term	Description
GradePointAverage	The result is a grade point average.
LetterGrade	The result is a letter grade.
Percent	The result is a percent score.
PerformanceLevel	The result is a performance level.
PredictedScore	The result is a predicted score.
RawScore	The result is a raw score.
Result	A generic result.
RubricCriterion	The result is from a rubric criterion.
RubricCriterionLevel	The result is a rubric criterion level.
RubricScore	The result represents a rubric score with both a name and a numeric value.
ScaledScore	The result is a scaled score.
Status	The result conveys the status of the achievement.
This enumeration can be extended with new, proprietary terms. The new terms must start with the substring 'ext:'.

B.4.33 ResultStatusType Enumeration

Defined vocabulary to convey the status of an achievement.

Term	Description
Completed	The learner has successfully completed the achievement. This is the default status if no status result is included.
Enrolled	The learner is enrolled in the activity described by the achievement.
Failed	The learner has unsuccessfully completed the achievement.
InProgress	The learner has started progress in the activity described by the achievement.
OnHold	The learner has completed the activity described by the achievement, but successful completion has not been awarded, typically for administrative reasons.
Provisional	The learner has completed the activity described by the achievement, but the completed result has not yet been confirmed.
Withdrew	The learner withdrew from the activity described by the achievement before completion.

B.5 Shared API Security Data Models

The data models in this section are shared by all 1EdTech service specifications.

B.5.1 ServiceDescriptionDocument

The Service Description Document (SDD) is a machine readable document that contains the description of the service features supported by the Provider/Platform. The SDD is an OpenAPI 3.0 (JSON) [OPENAPIS-3.0] structured document that MUST be a profiled version of the OpenAPI 3.0 (JSON) file provided provided with this specification. This profiled version contains all of the details about the supported set of service end-points, the supported optional data fields, definitions of the proprietary data fields supplied using the permitted extension mechanisms, definitions of the available proprietary endpoints, and information about the security mechanisms.

Note

Only a subset of the object properties are shown here.

Property	Type	Description	Multiplicity
openapi	`String`	This string MUST be the semantic version number of the OpenAPI Specification version that the OpenAPI document uses. The openapi field SHOULD be used by tooling specifications and clients to interpret the OpenAPI document. This is not related to the API info.version string.	[1]
info	`OpenApiInfo`	Information about the API and the resource server. Note The proprietary fields `x-imssf-image` and `x-imssf-privacyPolicyUrl` are found here.	[1]
components	`OpenApiComponents`	Holds a set of reusable objects for different aspects of the OAS. Note The proprietary field `x-imssf-registrationUrl` is found in the `securitySchemes` components.	[1]
This class can be extended with additional properties.

B.5.2 OpenApiComponents

Holds a set of reusable objects for different aspects of the OAS. All objects defined within the components object will have no effect on the API unless they are explicitly referenced from properties outside the components object.

Note

Only a subset of the object properties are shown here.

Property	Type	Description	Multiplicity
securitySchemes	`OpenApiSecuritySchemes`	The Map of security scheme objects supported by this specification.	[1]
This class can be extended with additional properties.

B.5.3 OpenApiInfo

The object provides metadata about the API. The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.

Note

Only a subset of the object properties are shown here.

Property	Type	Description	Multiplicity
termsOfService	`URL`	A fully qualified URL to the resource server's terms of service.	[1]
title	`String`	The name of the resource server.	[1]
version	`String`	The version of the API.	[1]
x-imssf-image	`URI`	An image representing the resource server. MAY be a Data URI or the URL where the image may be found.	[0..1]
x-imssf-privacyPolicyUrl	`URL`	A fully qualified URL to the resource server's privacy policy.	[1]
This class can be extended with additional properties.

B.5.4 OpenApiOAuth2SecurityScheme

Defines an OAuth2 security scheme that can be used by the operations.

Note

Only a subset of the object properties are shown here.

Property	Type	Description	Multiplicity
type	`String`	MUST be the string `oauth2`.	[1]
description	`String`	A short description for the security scheme.	[0..1]
x-imssf-registrationUrl	`URL`	A fully qualified URL to the Client Registration endpoint.	[1]
This class can be extended with additional properties.

B.5.5 OpenApiSecuritySchemes

The Map of security scheme objects supported by this specification.

Note

Only a subset of the object properties are shown here.

Property	Type	Description	Multiplicity
OAuth2ACG	`OpenApiOAuth2SecurityScheme`	REQUIRED if the authorization server supports the Authorization Code Grant Flow.	[0..1]

B.6 Shared API Data Models

The data models in this section are shared by all 1EdTech service specifications.

B.6.1 Imsx_StatusInfo

This is the container for the status code and associated information returned within the HTTP messages received from the Service Provider.

Property	Type	Description	Multiplicity
imsx_codeMajor	`Imsx_CodeMajor Enumeration`	The code major value (from the corresponding enumerated vocabulary).	[1]
imsx_severity	`Imsx_Severity Enumeration`	The severity value (from the corresponding enumerated vocabulary).	[1]
imsx_description	`String`	A human readable description supplied by the entity creating the status code information.	[0..1]
imsx_codeMinor	`Imsx_CodeMinor`	The set of reported code minor status codes.	[0..1]

B.6.2 Imsx_CodeMajor Enumeration

This is the set of primary status report values i.e. the major code assigned to the status block. This is used in conjunction with the 'Severity' structure in the status object.

Term	Description
failure	Denotes that the transaction request has failed. The detailed reason will be reported in the accompanying 'codeMinor' fields.
processing	Denotes that the request is being processed at the destination or there has been a local transmission failure. This value is used in asynchronous services.
success	Denotes that the request has been successfully completed. If the associated 'severity' value is 'warning' then the request has been partially successful i.e. best effort by the service provider. Other parts of the status information may provide more insight into a partial success response.
unsupported	Denotes that the service provider does not support the requested operation. This is the required default response for an unsupported operation by an implementation.

B.6.3 Imsx_Severity Enumeration

This is the context for the status report values. This is used in conjunction with the 'CodeMajor' structure in the status object.

Term	Description
error	A catastrophic error has occurred in processing the request and so the request was not completed (the Service Provider may not even have received the request).
status	The request has been completed and a response was received from the Service Provider.
warning	The request has only been partially completed. For an asynchronous service a further response should be expected.

B.6.4 Imsx_CodeMinor

This is the container for the set of code minor status codes reported in the responses from the Service Provider.

Property	Type	Description	Multiplicity
imsx_codeMinorField	`Imsx_CodeMinorField`	Each reported code minor status code.	[1..*]

B.6.5 Imsx_CodeMinorField

This is the container for a single code minor status code.

Property	Type	Description	Multiplicity
imsx_codeMinorFieldName	`NormalizedString`	This should contain the identity of the system that has produced the code minor status code report.	[1]
imsx_codeMinorFieldValue	`Imsx_CodeMinorFieldValue Enumeration`	The code minor status code (this is a value from the corresponding enumerated vocabulary).	[1]

B.6.6 Imsx_CodeMinorFieldValue Enumeration

This is the set of codeMinor status codes that are used to provide further insight into the completion status of the end-to-end transaction i.e. this should be used to provide more information than would be supplied by an HTTP code.

Term	Description
forbidden	This is used to indicate that the server can be reached and process the request but refuses to take any further action. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '403'.
fullsuccess	The request has been fully and successfully implemented by the service provider. For a REST binding this will have an HTTP code of '200' for a successful search request.
internal_server_error	This should be used only if there is catastrophic error and there is not a more appropriate code. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '500'.
invalid_data	This error condition may occur if a JSON request/response body contains well-formed (i.e. syntactically correct), but semantically erroneous, JSON instructions. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and a HTTP code of '422'.
invalid_query_parameter	An invalid data query parameter field was supplied and the query could not be processed. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '400'.
misdirected_request	This is used to indicate that the request was made with a protocol that is not supported by the server. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '421'.
not_acceptable	This is used to indicate that the server cannot provide a response with a Content-Type that matches any of the content types in the request Accept header. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '406'.
not_allowed	This is used to indicate that the server does not allow the HTTP method. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '405'.
not_found	This is used to indicate that the server did not find the resource. This would be accompanied by the 'codeMajor/severity' values of 'failure/status' and for a REST binding a HTTP code of '404'.
not_modified	This is used to indicate that the server did not modify the resource. This would be accompanied by the 'codeMajor/severity' values of 'success/status' and for a REST binding a HTTP code of '304'.
server_busy	The server is receiving too many requests. Retry at a later time. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '429'.
unauthorizedrequest	The request was not correctly authorised. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code of '401'.
unknown	Any other error occurred. This would be accompanied by the 'codeMajor/severity' values of 'failure/error' and for a REST binding a HTTP code corresponding to the error.

B.7 Shared OAuth 2.0 Models

The data models in this section are shared by all 1EdTech service specifications.

B.7.1 AuthorizationError Vocabulary

This is the set of ASCII error code strings that may be returned in response to a client authorization request. See Section 4.1 of [RFC6749].

Term	Description
invalid_request	The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.
unauthorized_client	The client is not authorized to request an authorization code using this method.
access_denied	The resource owner or authorization server denied the request.
unsupported_response_type	The authorization server does not support obtaining an authorization code using this method.
invalid_scope	The requested scope is invalid, unknown, or malformed.
server_error	The authorization server encountered an unexpected condition that prevented it from fulfilling the request. (This error code is needed because a 500 Internal Server Error HTTP status code cannot be returned to the client via an HTTP redirect.)
temporarily_unavailable	The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server. (This error code is needed because a 503 Service Unavailable HTTP status code cannot be returned to the client via an HTTP redirect.)

B.7.2 RegistrationError Vocabulary

This is the set of ASCII error code strings that may be returned in response to a client registration request. See [RFC7591].

Term	Description
invalid_redirect_uri	The value of one or more redirection URIs is invalid.
invalid_client_metadata	The value of one of the client metadata fields is invalid and the server has rejected this request. Note that an authorization server MAY choose to substitute a valid value for any requested parameter of a client's metadata.
invalid_software_statement	The software statement presented is invalid. This MUST only be returned if a Software Statement has been supplied in the registration request. Use of a Software Statement is NOT RECOMMENDED.
unapproved_software_statement	The software statement presented is not approved for use by this authorization server. This MUST only be returned if a Software Statement has been supplied in the registration request. Use of a Software Statement is NOT RECOMMENDED.

B.7.3 TokenError Vocabulary

This is the set of ASCII error code strings that may be returned in response to a client token request. See Section 5.2 of [RFC6749].

Term	Description
invalid_request	The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
invalid_client	Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client.
invalid_grant	The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
unauthorized_client	The authenticated client is not authorized to use this authorization grant type.
unsupported_grant_type	The authorization grant type is not supported by the authorization server.
unsupported_token_type	The authorization server does not support the revocation of the presented token type. That is, the client tried to revoke an access token on a server not supporting this feature.
invalid_scope	The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.

B.8 Shared Proof Models

The data models for the JSON Web Token Proof Format (VC-JWT) [VC-DATA-MODEL-2.0] is shared by all 1EdTech Digital Credentials specifications.

B.8.1 Multikey

Property	Type	Description	Multiplicity
id	`URI`	The `id` of the verification method MUST be the JWK thumbprint calculated from the `publicKeyMultibase` property value according to [MULTIBASE].	[1]
type	`String`	The `type` of the verification method MUST be the string `DataIntegrityProof`.	[0..1]
cryptosuite	`String`	The `cryptosuite` of the verification method MUST be the string `eddsa-rdf-2022`.	[1]
controller	`URI`	The identify of the entity that controls this public key.	[0..1]
publicKeyMultibase	`String`	The `publicKeyMultibase` property of the verification method MUST be a public key encoded according to [MULTICODEC] and formatted according to [MULTIBASE]. The multicodec encoding of a Ed25519 public key is the two-byte prefix `0xed01` followed by the 32-byte public key data.	[1]

B.8.2 JWK

A JSON Web Key (JWK) formatted according to [RFC7517].

Property	Type	Description	Multiplicity
kty	`String`	The `kty` (key type) parameter identifies the cryptographic algorithm family used with the key, such as `RSA` or `EC`.	[1]
use	`String`	The `use` (public key use) parameter identifies the intended use of the public key, such as `sig` (signature) or `end` (encryption).	[0..1]
key_ops	`String`	The `key_ops` (key operations) parameter identifies the operation(s) for which the key is intended to be used, such as `sign` (compute digital signature or MAC) or `verify` (verify digital signature or MAC).	[0..1]
alg	`String`	The `alg` (algorithm) parameter identifies the algorithm intended for use with the key, such as `RS256` or `PS256`.	[0..1]
kid	`String`	The `kid` (key ID) parameter is used to match a specific key.	[0..1]
x5u	`URI`	The `x5u` (X.509 URL) parameter is a URI that refers to a resource for an X.509 public key certificate or certificate chain [RFC5280].	[0..1]
x5c	`String`	The `x5c` (X.509 certificate chain) parameter contains a chain of one or more PKIX certificates [RFC5280].	[0..*]
x5t	`String`	The `x5t` (X.509 certificate SHA-1 thumbprint) parameter is a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate [RFC5280].	[0..1]
x5t_S256	`String`	The `x5t#S256` (X.509 certificate SHA-256 thumbprint) parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate [RFC5280].	[0..1]
This class can be extended with additional properties.

B.8.3 JWKS

A JWK Set (JWKS) formatted according to [RFC7517].

Property	Type	Description	Multiplicity
keys	`JWK`	A JWK Set is a JSON object that represents a set of JWKs.	[1..*]

B.9 Derived Types

The derived types in this section are shared by all 1EdTech specifications.

Type	Description
ASCIIString	An ASCII [RFC20] string. The string MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
BaseTerm	A term in an enumeration which serves as a common term for all other entries in this enumeration, and as such is less specific. The lexical constraints are the same as for `Term`.
CompactJws	A `String` in Compact JWS format [RFC7515].
CountryCode	A two-digit ISO 3166-1 alpha-2 country code [ISO3166-1].
DateTimeZ	A `DateTime` with the trailing timezone specifier included, e.g. `2021-09-07T02:09:59+02:00`
EmailAddress	A `NormalizedString` representing an email address.
Identifier	A `NormalizedString` that functions as an identifier.
IdentityHash	A `String` consisting of an algorithm identifier, a `$` separator, and a hash across an identifier and an optionally appended salt string. The only supported algorithms are MD5 [RFC1321] and SHA-256 [FIPS-180-4], identified by the strings 'md5' and 'sha256' respectively. Identifiers and salts MUST be encoded in UTF-8 prior to hashing, and the resulting hash MUST be expressed in hexadecimal using uppercase (A-F, 0-9) or lowercase character (a-f, 0-9) sets. For example: 'sha256$b5809d8a92f8858436d7e6b87c12ebc0ae1eac4baecc2c0b913aee2c922ef399' represents the result of calculating a SHA-256 hash on the string 'a@example.comKosher'. in which the email identifier 'a@example.com' is salted with 'Kosher'
IRI	A `NormalizedString` that represents an Internationalized Resource Identifier (IRI), which extends the ASCII characters subset of the Uniform Resource Identifier (URI).
LanguageCode	A language code [BCP47].
Markdown	A `String` that may contain Markdown.
NumericDate	An `Integer` representing the number of seconds from from 1970-01-01T00:00:00Z UTC until the specified UTC data/time, ignoring leap seconds.
PhoneNumber	A `NormalizedString` representing a phone number.
Term	A term in an enumeration. The lexical constraints are the same as for `Token`.
URI	A `NormalizedString` that respresents a Uniform Resource Identifier (URI).
URL	A `URI` that represents a Uniform Resource Locator (URL).
UUID	An `Identifier` with the lexical restrictions of a UUID [RFC4122]

B.10 Primitive Types

The primitive types in this section are shared by all 1EdTech specifications.

Type	Description
Boolean	A boolean, expressed as `true` or `false`
Date	An [ISO8601] calendar date using the syntax YYYY-MM-DD.
DateTime	An [ISO8601] time using the syntax YYYY-MM-DDThh:mm:ss.
Float
Integer
Language	A language code [BCP47].
Namespace	A namespace data type for defining data from a context other than that as the default for the data model. This is used for importing other data models.
NonNegativeInteger
NormalizedString	A `String` conforming to the `normalizedString` definition in [XMLSCHEMA-2].
PositiveInteger
String	Character strings.

B.11 Verification Support Data Models

The data models in this section are used by the § 8. Verification and Validation process for supporting older credentials created with [VC-DATA-MODEL].

B.11.1 AnyClrCredential

AnyClrCredential represents an ClrCredential that might be built using [VC-DATA-MODEL] or [VC-DATA-MODEL-2.0]. The scope of this class is only for verification purposes. It is not intended to be used in the creation of new credentials, where the [[[#clrcredential]] class MUST be used.

The ultimate representation of this class is a choice of exactly one of the classes in the following set:

Type	Description
`ClrCredentialv1p1`	A ClrCredential is a CLR with all the properties needed to conform with a Verifiable Credential as defined in the [VC-DATA-MODEL].
`ClrCredential`	A ClrCredential is a CLR with all the properties needed to conform with a Verifiable Credential as defined in the [VC-DATA-MODEL-2.0].

B.11.2 ClrCredentialv1p1

A ClrCredential is a CLR with all the properties needed to conform with a Verifiable Credential as defined in the [VC-DATA-MODEL].

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first three items are the URLs `https://www.w3.org/2018/credentials/v1`, `https://purl.imsglobal.org/spec/clr/v2p0/context-2.0.1.json`, `https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json`.	[1..*]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the IRI `VerifiableCredential`, and one of the items MUST be the IRI `ClrCredential`.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
name	`String`	The name of the CLR. May be displayed by wallet user interfaces.	[1]
description	`String`	Optional description of the CLR. May be displayed by wallet user interfaces.	[0..1]
endorsement	`EndorsementCredentialv1p1`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the ClrCredential, or any AssertionCredential, Achievement, or Profile referenced in the ClrCredential. These endorsements are signed with the VC-JWT proof format.	[0..*]
image	`Image`	Optional image representing the CLR. May be displayed by wallet user interfaces. If present, MUST represent a PNG or SVG image. MAY be a 'baked' image.	[0..1]
partial	`Boolean`	True if CLR does not contain all the assertions known by the publisher for the learner at the time the CLR is issued. Useful if you are sending a small set of achievements in real time when they are achieved. If False or omitted, the CLR SHOULD be interpreted as containing all the assertions for the learner known by the publisher at the time of issue.	[0..1]
credentialSubject	`ClrSubjectv1p1`	The learner that is the subject of this CLR credential.	[1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `issuanceDate` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `issuanceDate`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
issuer	`Profilev1p1`	A description of the individual, entity, or organization that issued the credential.	[1]
issuanceDate	`DateTimeZ`	Timestamp of when the credential was issued.	[1]
expirationDate	`DateTimeZ`	If the credential has some notion of expiry, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered expired.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.11.3 ClrSubjectv1p1

A collection of information about the learner that is the subject of this CLR credential.

Property	Type	Description	Multiplicity
id	`URI`	An identifier for the recipient of the CLR credential. Either `id` or at least one `identifier` is required.	[0..1]
type	`IRI`	The property MUST contain the IRI `ClrSubject`.	[1..*]
identifier	`IdentityObject`	Other identifiers for the recipient of the CLR credential. Either `id` or at least one `identifier`is required.	[0..*]
achievement	`Achievementv1p1`	The set of achievements the CLR issuer expects the learner to achieve.	[0..*]
verifiableCredential	`VerifiableCredentialv1p1`	A set of AchievementCredentials, OpenBadgeCredentials, and other VerifiableCredentials the learner has been awarded. The credential issuers may not be the same entity as the ClrCredential issuer, but the ClrCredential's credential subject is guaranteed to be the same person as the credential subject of each included credential, even if they use different identifiers.	[1..*]
association	`Association`	Associations describe the semantic relationship between source and target achievements and their assertions.	[0..*]
This class can be extended with additional properties.

B.12 Shared Verification Support Data Models

The data models in this section are shared by Open Badges Specification v3.0 and Comprehensive Learner Record Standard v2.0.

B.12.1 AnyAchievementCredential

AnyAchievementCredential represents an AchievementCredential that might be built using [VC-DATA-MODEL] or [VC-DATA-MODEL-2.0]. The scope of this class is only for verification purposes. It is not intended to be used in the creation of new credentials, where the § B.4.2 AchievementCredential class MUST be used.

The ultimate representation of this class is a choice of exactly one of the classes in the following set:

Type Description

AchievementCredential AchievementCredentials are representations of an awarded achievement, used to share information about a achievement belonging to one earner. Maps to a Verifiable Credential as defined in the [VC-DATA-MODEL-2.0]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

AchievementCredentialv1p1 AchievementCredentials are representations of an awarded achievement, used to share information about a achievement belonging to one earner. Maps to a Verifiable Credential as defined in the [VC-DATA-MODEL]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

B.12.2 AchievementCredentialv1p1

AchievementCredentials are representations of an awarded achievement, used to share information about a achievement belonging to one earner. Maps to a Verifiable Credential as defined in the [VC-DATA-MODEL]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/2018/credentials/v1', and the second item is a URI with the value 'https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential', and one of the items MUST be the URI 'AchievementCredential' or the URI 'OpenBadgeCredential'.	[1..*]
name	`String`	The name of the credential for display purposes in wallets. For example, in a list of credentials and in detail views.	[1]
description	`String`	The short description of the credential for display purposes in wallets.	[0..1]
image	`Image`	The image representing the credential for display purposes in wallets.	[0..1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
credentialSubject	`AchievementSubjectv1p1`	The recipient of the achievement.	[1]
endorsement	`EndorsementCredentialv1p1`	Allows endorsers to make specific claims about the credential, and the achievement and profiles in the credential. These endorsements are signed with a Data Integrity proof format.	[0..*]
endorsementJwt	`CompactJws`	Allows endorsers to make specific claims about the credential, and the achievement and profiles in the credential. These endorsements are signed with the VC-JWT proof format.	[0..*]
evidence	`Evidence`		[0..*]
issuer	`Profilev1p1`	A description of the individual, entity, or organization that issued the credential.	[1]
issuanceDate	`DateTimeZ`	Timestamp of when the credential was issued.	[1]
expirationDate	`DateTimeZ`	If the credential has some notion of expiry, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered expired.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.12.3 AnyEndorsementCredential

AnyEndorsementCredential represents an EndorsementCredential that might be built using [VC-DATA-MODEL] or [VC-DATA-MODEL-2.0]. The scope of this class is only for verification purposes. It is not intended to be used in the creation of new credentials, where the [[[#endorsementcredential]] class MUST be used.

The ultimate representation of this class is a choice of exactly one of the classes in the following set:

Type	Description
`EndorsementCredential`	A verifiable credential that asserts a claim about an entity. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the `proof` property.
`EndorsementCredentialv1p1`	A verifiable credential that asserts a claim about an entity. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the `proof` property.

B.12.4 EndorsementCredentialv1p1

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/2018/credentials/v1', and the second item is a URI with the value 'https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json'.	[1..*]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential', and one of the items MUST be the URI 'EndorsementCredential'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[1]
name	`String`	The name of the credential for display purposes in wallets. For example, in a list of credentials and in detail views.	[1]
description	`String`	The short description of the credential for display purposes in wallets.	[0..1]
credentialSubject	`EndorsementSubject`	The individual, entity, organization, assertion, or achievement that is endorsed and the endorsement comment.	[1]
awardedDate	`DateTimeZ`	Timestamp of when the credential was awarded. `validFrom` is used to determine the most recent version of a Credential in conjunction with `issuer` and `id`. Consequently, the only way to update a Credental is to update the `validFrom`, losing the date when the Credential was originally awarded. `awardedDate` is meant to keep this original date.	[0..1]
issuer	`Profilev1p1`	A description of the individual, entity, or organization that issued the credential.	[1]
issuanceDate	`DateTimeZ`	Timestamp of when the credential was issued.	[1]
expirationDate	`DateTimeZ`	If the credential has some notion of expiry, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered expired.	[0..1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not allowed to perform (a prohibition), or allowed to perform (a permission) if it is to accept the verifiable credentia	[0..*]
This class can be extended with additional properties.

B.12.5 VerifiableCredentialv1p1

A Verifiable Credential as defined in the [VC-DATA-MODEL]. As described in § 7. Proofs (Signatures), at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential. In the case of an embedded proof, the credential MUST append the proof in the proof property.

Property	Type	Description	Multiplicity
@context	`Context`	The value of the `@context` property MUST be an ordered set where the first item is a URI with the value 'https://www.w3.org/2018/credentials/v1'.	[1..*]
id	`URI`	Unambiguous reference to the credential.	[0..1]
type	`IRI`	The value of the type property MUST be an unordered set. One of the items MUST be the URI 'VerifiableCredential'.	[1..*]
issuer	`Profilev1p1`	A description of the individual, entity, or organization that issued the credential.	[1]
issuanceDate	`DateTimeZ`	Timestamp of when the credential was issued.	[1]
expirationDate	`DateTimeZ`	If the credential has some notion of expiry, this indicates a timestamp when a credential should no longer be considered valid. After this time, the credential should be considered expired.	[0..1]
credentialSubject	`CredentialSubject`	The subject of the credential.	[1]
proof	`Proof`	If present, one or more embedded cryptographic proofs that can be used to detect tampering and verify the authorship of the credential.	[0..*]
credentialSchema	`CredentialSchema`	The value of the `credentialSchema` property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.	[0..*]
credentialStatus	`CredentialStatus`	The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked.	[0..1]
refreshService	`RefreshService`	The information in RefreshService is used to refresh the verifiable credential.	[0..1]
termsOfUse	`TermsOfUse`	The value of the `termsOfUse` property tells the verifier what actions it is required to perform (an obligation), not

You are here

Comprehensive Learner Record Standard Version 2.0

Abstract

1. Overview

1.1 Audiences

1.2 Document Set

1.2.1 OpenAPI 3.0 Files

1.2.2 JSON-LD Context File

1.2.3 JSON Schema

1.3 Conformance Statements

1.4 Terminology

1.5 Conceptual Model

2. Use Cases

2.1 Categories

2.2 Recent graduate wants to hold a copy of their own official transcript

2.3 Job applicant provides proof of degree and transcript to potential employer

2.4 Job applicant provides proof of degree and specific courses/engagements from the CLR

2.5 Higher Ed Competency-Based Education

2.6 Issuer Asserting All Student Achievements Comprehensively as a CLR

2.7 Issuer Asserting Partial Transcript at Intermediate Points in Learning Journey

2.8 Issuer Asserting Student Up to Date Partial Transcript of Achievements as CLR on Request

2.9 Internal Organizational Staff Development and Promotion

2.10 Upskilling with Higher Ed Professional/Continuing Education (via Georgia Tech - Matt Lisle)

2.11 Teacher Placement with a District

2.12 Professional Licensure Test Taker results

2.13 Students in Tutoring Program

3. Getting Started

3.1 Implementation Guide

3.2 Conformance and Certification

4. CLR Standard Document Formats

4.1 File Format

4.2 Web Resource

4.3 Image Format

4.3.1 PNGs

4.3.1.1 Baking

4.3.1.2 Extracting

4.3.2 SVG

4.3.2.1 Baking

4.3.2.2 Extracting

5. CLR Standard API

5.1 Architecture

5.2 Secure REST Endpoints

Scopes

5.2.1 getCredentials

Request

Responses

5.2.2 upsertCredential

Request

Responses

5.2.3 getProfile

Request

Responses

5.2.4 putProfile

Request

Responses

5.3 Service Discovery Endpoint

5.3.1 getServiceDescription

Request

Responses

5.4 Paging

5.5 Retry Behavior

6. CLR Standard API Security

6.1 Using OAuth 2.0 Authorization Code Grant

6.1.1 ACG - Registration

6.1.2 ACG - Obtaining Tokens

ACG - Authorization Request

ACG - Authorization Response

Authorization Error Response

ACG - Access Token Request

ACG - Access Token Response

Access Token Error Response

6.1.3 ACG - Authenticating with Tokens

6.2 Token Refresh

Token Refresh Request

Token Refresh Response

6.3 Token Revocation

Token Revocation Request

Token Revocation Response

6.4 Dynamic Client Registration

Request the Service Description Document