Comprehensive Learner Record Standard Version 2.0
Spec Version 2.0
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 .
© 2024 1EdTech™ Consortium, Inc. All Rights Reserved.
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.
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").
- 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.
- 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.
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.
- 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
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
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
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
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)
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.
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.
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.
<?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[...]]>
.
<?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.
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
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}
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
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 |
GET /ims/clr/v2p0/credentials?limit=2&offset=0 HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json
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.
Request
POST /ims/clr/v2p0/credentials
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
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 |
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"
}
}
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
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 |
GET /ims/clr/v2p0/profile HTTP/1.1
Host: example.edu
Authorization: Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92
Accept: application/json
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
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
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 |
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"
}
{
"@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
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 |
GET /ims/clr/v2p0/discovery HTTP/1.1
Host: example.edu
Accept: application/json
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. |
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.
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 |
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 |
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
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:
|
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:
|
Optional |
grant_types |
String[] |
Array of OAuth 2.0 grant type strings. In this specification only "authorization_code" and
refresh_token" are allowed:
|
Optional |
response_types |
String[] |
Array of OAuth 2.0 response type strings. In this specification only "code" is allowed:
|
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 |
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:
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.
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.
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 |
{
"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.
{
...
"credentialSubject": {
"verifiableCredential": [
{
"id": "assertion1",
...
},
{
"id": "assertion2",
...
}
]
}
}
{
...
"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
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
forC
as described in [RFC7515]. - Encode the signature as
BASE64URL(JWS Signature)
. - Concatenate
C
andE
asC | "." | 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 thekid
value to retrieve the public key JWK.If the header includes a
jwk
property, convert thejwk
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 Signature1EdTech 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.
NoteCredentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) store the OpenBadgeCredential in thevc
claim of the JWT Payload. In this case, the contents of thevc
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 theid
of theissuer
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 theid
of thecredentialSubject
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 thevalidFrom
of the ClrCredentialJwtPayload object. If they do not match or if thevalidFrom
has not yet occurred, the credential is not valid. - The JSON object MUST have the
jti
claim, and the value MUST match theid
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 thevalidUntil
of the ClrCredentialJwtPayload object. If the credential has expired, the credential is not valid.
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.
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.
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 thetype
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 anid
and/or anidentifier
. If neither is present, the credential does not conform to the specification.
NoteClrCredentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they haveissuanceDate
andexpirationDate
instead ofvalidFrom
andvalidUntil
, 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.- If the ClrCredential has a
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.
NoteThe 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 thevc
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:
NoteRefresh 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 thetype
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.NoteOnly perform Refresh once. That is, do not complete Refresh a second time even if the refreshed ClrCredential also has arefreshService
defined.
- If the
Check the status:
- A Credential is revoked if the
credentialStatus
property is present, and thetype
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.
NoteClrCredentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they haveissuanceDate
andexpirationDate
instead ofvalidFrom
andvalidUntil
, 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.- A Credential is revoked if the
Optionally verify the subject (recipient):
NoteThis 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) byid
and/or one or moreidentifier
(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.
- A ClrCredential is about a person called the recipient. The recipient is identified in the
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 atype
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 atype
of "EndorsementCredential", verify the nested credential as shown in section "EndorsementCredential Verification" of the Open Badges Specification v3.0.
- A ClrCredential usually contains nested verifiable credentials in the
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 nextidentifier
. - If
identifier.hashed
istrue
, calculate the known identifier IdentityHash using the known identifier and theidentifier.salt
. If the known identifier IdentityHash matches theidentifier.identityHash
, the recipient is verified. - If
identifier.hashed
isfalse
, and if the known identifier matches theidentifier.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
.
{
"@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
{
"@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
.
{
"@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
{
"@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
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..*
and1..*
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.
@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.
"@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:
- ClrCredential JSON schema
- GetClrCredentialsResponse JSON schema
- Profile JSON schema
- Imsx_StatusInfo JSON schema
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.
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] |
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. |
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.
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.
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.
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.
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.
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.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
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/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 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. |