Technical Implementation Plan

It's important to ensure that you will actually be able to recognize all of the achievements you wish to recognize. Typically, an "issuer" system holds achievement configuration, gathers information on which learners have earned awards of which achievements, and then issues LERs as VCs as learners accept them into a credential wallet or similar system. We distinguish the concept of an award (an internal record of qualification for a credential) from the issued credential (which is expressed in standardized data formats and cryptographically signed).

‍

The workflow you use will be highly dependent on the systems in which underlying data is stored, the product(s) used for awarding and issuing, and the team you are working with. There may be direct integrations and automations available to you that streamline your work but impose requirements on how team members have to execute certain processes. Some example award workflows include:

‍

• A direct integration between web applications with an API and API key. E.g.: an issuer system that can automatically award course completion credentials based on a direct integration with a Student Information System and configuration of options and filters.
• Manual bulk award by exporting a spreadsheet from a source system and uploading it to an issuer system on a regular schedule. E.g. Events staff export registration lists for professional development seminars after each event, rename the "Email Address" column to "email", and upload to award the badge specific for that event.
• Individual awards could be made by peer or instructor invitation from the issuer system web application.
• Some achievements may be open for learner application with or without a requirement for review by certain qualified staff.

In order for LER issued as VCs to flow smoothly to connect holders to opportunities, components need to be in place to serve issuers, holders, and verifiers, and they need to support common standards and protocols for how credentials will be structured and how they will move around. While you likely won’t be building everything from scratch, it is useful to understand the processes and procedures, as well as the data flow through the system so you can explain it at a high level to your team members and/or nontechnical partners.

‍

The VC lifecycle refers to the stages that an LER issued as a VC goes through from awarding and issuing (by an issuer), being received, stored, and managed (by the subject or holder, often in a "wallet"), to being verified and the contents processed, interpreted, and used to connect people to learning and employment opportunities.

It is important to ensure LERs issued as VCs are interoperable across education providers, workforce development agencies, digital wallets, employers, and other involved systems for VCs to be able to flow between them. We’ve provided a general overview of the key considerations and components for demonstrating VCs across the LER lifecycle. Even if your project does not encompass all lifecycle roles, it is useful to understand and test credential flow all the way to verification and processing.

If your project is implementing LERs as VCs, the Verifiable Credentials Data Model provides the envelope, but there must be an additional open data specification defining the "credential type" with which to format the message. Each Verifiable Credential has a specific credential type, and there are several options that support LER content. To issue a Verifiable Credential for a degree, badge, certificate, or micro-credential, these concepts are implemented according to the rules of an LER credential type specification. All components of the system need to support this credential type. We identify that the Open Badges (OB 3.0) specification is a practical choice for credential type, as it enables a number of components suitable for SBHA use cases and activities. Comprehensive Learner Record (CLR 2.0) may be additionally used to package together multiple OB or other type VCs. The European Learning Model (ELM) may become widely used as well, especially within Europe.

LERs issued as VCs may include skills and content-rich data, are based on international open data standards that enable interoperability, and are verifiable usually based on digital/cryptographic signatures made by their issuers.

‍

The Verifiable Credentials Data model and the credential type specifications like Open Badges largely define the format of data, and additional layers compatible with these standards cover the process by which data moves between entities. There are a number of implementation choices involved in using these open data standards. Interoperability is not guaranteed just because you've implemented one standard, but the template for this section guides you through documenting and checking the compatibility of your approach throughout the VC lifecycle.

‍

A more complete map of the credential lifecycle for a project, like the example below, might show additional connections based on open standards, direct integrations, or human-mediated processes. Registries, such as simple issuer lists or public services like the Credential Registry, may be used to enhance trust or link additional descriptive metadata to issued VCs. Explore the expectations of each entity involved (systems operating on behalf of users), and document the data flows for each relationship between them. Ensure an approach is selected for each document format issue and data flow, and track the implementation and testing status of data flows as your project progresses to avoid late-breaking interoperability problems.