Modeling Educational Verifiable Credentials

1. Introduction

1.1. Goals

Document a simple foundational recommendation for which to research and pursue digital credentials solutions for use cases related to education, workface, and achievements in alignment with W3C Verifiable Credentials to inform standards bodies and those working in the digital credentials ecosystem
Use this foundation to advance and communicate the benefits of VCs
Provide examples that demonstrate alignment of use of VCs and potential exploration
Generalize implementation guidance for the VC-EDU community and the communities it straddles (healthcare etc.)

1.2. Problem Statement & Brief History

Many Verifiable Credentials pilots in the education space are having to invent their own schemas, despite the wealth of previous art in the educational data standards communities. That is for multiple reasons:

The focus of the VC community has been very much on the “envelope” and not the contents
Educational data standards are not easily approachable in a general way to outsiders: where does one start depending on use case? locale?
Educational data standards have rich domain-specific vocabularies, taxonomies, and ontologies, but may have additional assumptions that data has been exchanged between trusted authorities (directly from issuer/clearing house to relying party), and therefore are not clearly adaptable to minimized/selective disclosure schemes.

Open Badges made it possible for an achievement to be recognized in a data format that could be shared and verified online or digitally signed by issuers. Over time, a desire to describe these achievements with more human and machine meaning increased. Over the same period of time, web standards at the W3C, Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs), established models for online claims, like digital credentials in education, to be cryptographically authenticated while giving holders of the credentials more persistent access to their credentials and more privacy options.

This created a need for 1) standards like Open Badges to align with the W3C standards so that these credentials could operate like other verifiable claims on the web, and 2) technology vendors and technologists to understand how to create, communicate, and interpret achievement claims to serve the needs of all of the parties involved.

The [LER-WRAPPER] effort bootstrapped the alignment of existing educational data standards via the LER/VC wrapper. This enabled technology providers to build interoperable tooling at the wrapper/envelope level, staying agnostic to the contents, while enabling discoverability of metadata. This effort attempts to extend upon those efforts, enabling interoperability/mapping via enriched linked data.

This effort attempts to bridge the VC ecosystem to the robust work already done in the educational data standards space, to enable reuse of the great work done by experts in the space. Our main goal is discoverability of educational data standards frameworks, and informing implementors of how to use these in VCs.

Our work will help inform VC-EDU pilots, but will be forwarded as recommendations to relevant educational data standards bodies, representatives of which are active in this group. Educational data standards bodies rely on validation through real world use, which the umbrella of the W3C-CCG can provide.

1.3. Requirements & Scope

1.3.1. Requirements

We are targeting the Verifiable Credential data model
This assumes use of linked data (e.g. RDF/JSON-LD)
Specifically, we assume critical data fields must use structured, machine readable content, but additional presentations may be included (e.g. machine-readable plus PDF for human readable/backcompat)
Support display integrity for scenarios where a human is in the loop performing additional verification.
International-aware

1.3.2. Out of Scope

Deeper/structural changes such as degree audits, learning pathways, or actual standardization prior to implementation.
VC-EDU can only release draft recommendations, but the standardization work needs to happen in the proper SDO; e.g. IEEE CM4LTS (for ILR recommendations), 1EdTech(for Open Badges & CLR recommendations), etc. We will coordinate with the proper SDOs to do that work

2. Data Model

2.1. Contexts

Contexts used in the same sense as in [VC-DATA-MODEL]: “where 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”. For the VC-EDU model, the second URI should be https://w3c-ccg.github.io/vc-ed-models/context.json. It is required that JSON-ld be used for education credential to accommodate potential multiple contexts.

2.2. ID

ID is used in the same sense as in [VC-DATA-MODEL]. It MAY be used to represent a unique identifier for the VC. If included, it MUST be a URI and if it is a URL, it should be dereferencable containing machine-readable information about the id, not the VC itself in consideration of privacy concerns.

2.3. Type

Types are used in the same sense as in [VC-DATA-MODEL]. Types map to the @contexts and for the VC-EDU model include both “VerifiableCredential” and “VerifiableEducationCredential”. Other education models, such as Open Badges, specify the types to be used.

2.4. Issuer

2.5. Issuer

Issuer is used in the same sense as in [VC-DATA-MODEL] with no additional semantics; the issuer is simply an entity that makes a claim about the subject. The issuer doesn’t necessarily have relationship to learning experience that led to the credential

Issuer structure basic requirements are specified in [VC-DATA-MODEL]: "The value of the issuer property MUST be either a URI or an object containing an id property." The only required property from [VC-DATA-MODEL] is [id]. This document provides the following additional guidelines for implementers.

RECOMMEND: Use dereferenceable URIs for discoverability.
For the object form of issuer:
- REQUIRED: use [id], as required by [VC-DATA-MODEL]
- MAY: Use a [type] field for disambiguation
- MAY: Use schema.org types [Person] or [Organization] (or extensions) for interoperability
- RECOMMEND: Use [name] for display (such as in credential wallets)
- REQUIRED: If additional properties are included to describe the issuer, they should be sourced from a linked-data standard that is referenced in the context file.

2.5.1. Joint Issuers

[VC-DATA-MODEL] syntax currently allows for one issuer, which is overly restrictive for some use cases. Two options are possible for implementers:

Ceate a merged entity comprising multiple issuers. This may be appropriate if the merged entity is long-lived
- This is equivalent to solving the problem at the DID level (i.e. DID doc with multiple controllers)

2.6. Issuance Date

IssuanceDate is used in the same sense as in [VC-DATA-MODEL].

2.7. Credential Subject

CredentialSubject is used in the same sense as in [VC-DATA-MODEL]: is “defined as a set of objects that contain one or more properties that are each related to a subject of the verifiable credential.” This document provides the following guidelines for implementers:

In the object of the [credentialSubject]:

REQUIRED: use [id], as required by [VC-DATA-MODEL]; many implementations use Decentralized Identifiers.
REQUIRED: use [achievement] (alias to schema.org type [hasCredential]; achievement is an object containing:
- REQUIRED: [name]
- REQUIRED: [description]

2.8. Proof

Proof should follow the requirements and recommendations made by the [VC-DATA-MODEL].

2.9. Expiration

ExpirationDate is used in the same sense as in [VC-DATA-MODEL].

2.10. Evidence

Evidence is used in the same sense as in [VC-DATA-MODEL]. For Open Badges, evidence is. This issue being discussed as part of Open Badges 3.0

2.11. Credential Status

Credential Status is used in the same sense as in [VC-DATA-MODEL].

3. Examples

3.1. Basic Verifiable Education Credential

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3c-ccg.github.io/vc-ed-models/contexts/v05/context.json"
  ],
  "type": [
    "VerifiableCredential",
    "VerifiableEducationCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
    "name": "Education Insitution"
  },
  "issuanceDate": "2022-05-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:123456778rdf43ewer46d",
    "achievement": {
      "name": "Name of the achievement",
      "description": "Description of the achievement"
    }
  }
}

3.2. Base Verifiable Education Credential

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3c-ccg.github.io/vc-ed-models/contexts/v05/context.json"
  ],
  "type": [
    "VerifiableCredential",
    "VerifiableEducationCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
    "name": "Education Insitution"
  },
  "issuanceDate": "2022-05-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:123456778rdf43ewer46d",
    "achievement": {
      "name": "Name of the achievement",
      "description": "Description of the achievement"
    }
  }
}

3.3. Base Verifiable Education Credential with CTDL Properties

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3c-ccg.github.io/vc-ed-models/contexts/v05/context.json",
    "http://credreg.net/ctdl/schema/context/json"
  ],
  "type": [
    "VerifiableCredential",
    "VerifiableEducationCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
    "name": "Education Insitution"
  },
  "issuanceDate": "2022-05-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:123456778rdf43ewer46d",
    "achievement": {
      "name": "Name of the achievement",
      "description": "Description of the achievement",
      "ceterms:LearningMethod": {"learnMethod":"Applied"}
    }
  }
}

3.4. Diploma Issued as an Open Badge

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "id": "urn:uuid:a63a60be-f4af-491c-87fc-2c8fd3007a58",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "name": "Name of this Open Badge Instance",
  "issuer": {
    "type": ["Profile"],
    "id": "did:key:z6MktiSzqF9kqwdU8VkdBKx56EYzXfpgnNPUAGznpicNiWfn",
    "name": "Issuing Institution"
  },
  "issuanceDate": "2022-11-14T00:00:00Z",
  "credentialSubject": {
    "type": ["AchievementSubject"],
    "id": "did:key:123",
    "achievement": {
      "id": "urn:uuid:bd6d9316-f7ae-4073-a1e5-2f7f5bd22922",
      "type": ["Achievement"],
      "achievementType": "BachelorDegree",
      "name": "Bachelor Degree",
      "description": "This credential represents a bachelor degree",
      "criteria": {
        "type": "Criteria",
        "narrative": "Fulfill requirements set by issuing institution"
      }
    }
  }
}

4. Appendix

4.1. About CTDL/Credential Engine

https://credreg.net/ provides documentation for a family of RDF-based schemas for describing credentials and competencies
https://schema.org/EducationalOccupationalCredential was created to complement the CTDL
CTDL serializations
- CTDL JSON LD serializations: https://credreg.net/ctdl/schema
- CTDL ASN JSON LD serializations: https://credreg.net/ctdlasn/schema.
Examples of open badge and CLR references to CTDL: https://credreg.net/quickstart/ilwrguide.
Credential Finder: https://credentialfinder.org/
- Examples of credentials and competency frameworks (published using CTDL) are available via the Credential Finder
- The information seen in the Finder is from the CTDL and CTDL ASN encoded JSON LD in the Registry.
- From any detail page in the Finder, at bottom, right corner click on the JSON LD icon(s) to see the raw metadata. In the examples below, use the URIs to the data.
- The URIs can be to: credentials, organizations, learning opportunities, assessments, competency frameworks and competencies. Soon you can add pathways, transfer value and accredit action to the list.
Credential classes: https://credreg.net/page/typeslist
CTDL is a living language and can support multiple profiles and languages for internationalization https://credreg.net/page/typeslist
CTID definition: https://credreg.net/ctdl/terms#ctid
CTDL ASN (Competency frameworks) https://credreg.net/ctdlasn/terms. Use the main menu to see the CTDL ASN Handbook, serializations, mapping tool.
CTDL Samples: https://credreg.net/ctdl/samples

4.2. About Open Badges & CLR /1EdTech

Our main goal is discoverability of educational data standards frameworks, and informing implementers of how to use these in VCs. For example, in 2021, the VC-EDU Task Force agreed to propose to 1EdTech (formerly IMS Global) to align Open Badges to the VC Data model. This resulted in a new charter for Open Badges 3.0 and Comprehensive Learner Record (CLR) 2.0.

[Open Badges 3.0 Candidate Final](https://1edtech.github.io/openbadges-specification/ob_v3p0.html)