| Notes |
Building the digital
credential infrastructure
for the future
A White Paper by the Digital Credentials Consortium
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 1
Editors :
• Kim Hamilton Duffy (Chair, W3C Credentials Community Group)
• Hans Pongratz (CIO, TUM)
• J. Philipp Schmidt (Director, Learning Initiative, MIT Media Lab)
Contributing Authors:
• James Chartrand (McMaster University)
• Stuart Freeman (Applications Developer, C21U, Georgia Tech)
• Ulrich Gallersdörfer (TUM)
• Matt Lisle (Director of Digital Learning Technologies, C21U, Georgia Tech)
• Alexander Mühle (Hasso Plattner Institute, University of Potsdam)
• Sélinde van Engelenburg (Delft University of Technology)
Lead Reviewing Author:
• Krishna Rajagopal (William A. M. Burden Professor of Physics, Dean for Digital Learning, MIT)
Reviewing Authors:
• Nimisha Asthagiri (Chief Architect, edX)
• Matteo Bertazzo (Product Manager, CINECA)
• Michael Burke (Registrar, Harvard)
• Brian Canavan (Senior Associate Registrar, MIT)
• Paolo Cherubini (former Deputy Rector, University of Milano-Bicocca; Steering Committee for Learn
ing & Teaching, EUA, University of Milano-Bicocca)
• Ike Chuang (Senior Associate Dean of Digital Learning, MIT)
• Camille Crittenden (Executive Director, CITRIS and the Banatao Institute, UC Berkeley)
• Darek DeFreece (Managing Director, New Academic Ventures, UC Berkeley)
• Julien DePauw (Tecnológico de Monterrey)
• Jeff Dieffenbach (Associate Director, Integrated Learning Initiative, MIT)
• Dick H.J. Epema (Professor of Computer Science, Delft University of Technology)
• Jose Escamilla (TecLab Director, Tecnológico de Monterrey)
• Matthias Gottlieb (Senior Researcher, TUM)
• Steven Harmon (Director of Innovation, C21U, Georgia Tech)
• Oliver Heyer (Research, Teaching and Learning Services: Director of Projects, Development and
Operations, UC Berkeley)
• Irving Hidrogo (Educational Technology Project manager, Tecnológico de Monterrey)
• Michael Kan (Executive Director of HarvardX, Harvard)
• Timo Kos (Executive Director, Extension School, Delft University of Technology)
• Henry Leitner (Chief Innovation Officer and Associate Dean, Senior Lecturer on Computer Science,
Harvard)
• Nida van Leersum (Policy Advisor, Delft University of Technology)
• Gary Matkin (Dean of Continuing Education, UC Irvine)
• Mihnea Moldoveneau (Vice Dean of Learning and Innovation, University of Toronto)
• Melissa Pool (University Registrar, McMaster University)
• Ishwar K. Puri (Professor and Dean of Engineering, McMaster University)
• Jan Renz (Research Scientist, Hasso Plattner Institute, University of Potsdam)
• Bertha Saldivar (Technologies for Education, Tecnológico de Monterrey)
• Sanjay Sarma (Fred Fort Flowers and Daniel Fort Flowers Professor of Mechanical Engineering, VicePresident for Open Learning, MIT)
• Brian Subirana (Director, Auto-ID Lab, MIT)
• Marinke Sussenbach (Manager Education and Student Affairs, Delft University of Technology)
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 2
• Tracy Tan (Director, MicroMasters Program, MIT)
• Dustin Tingley (Deputy Vice Provost for Advances in Learning, Professor of Government, Harvard)
• Willem van Valkenburg (Manager Teaching & Learning Services, Delft University of Technology)
• Diana Wu (Dean, UC Berkeley Extension and New Academic Ventures, UC Berkeley)
• Maria White (Assistant Dean of Engineering, McMaster University)
• Alan Wolf (Managing Director of Academic Technology Services, Harvard)
• Walter Wong (University Registrar, UC Berkeley)
External Reviewers:
We are grateful for the comments, questions, and other input received from the following individuals.
Inclusion in the list below is not meant to constitute endorsement. Any errors in the final white paper are the
responsibility of the authors.
• Alessandro Aglietti (Co-founder, Growbit)
• Roman Beck (Professor in Information Systems and Blockchain Economist, IT University of
Copenhagen)
• Hennie Bulstra (Convenor User Group Diplomas and Credentials, European Blockchain Partnership)
• William Claxton (Founder and CEO, NextID)
• Perrine de Coëtlogon (Chargée de mission Blockchain & Education, University of Lille)
• Brian Fleming (Executive Director, Sandbox Collaborative, Southern New Hampshire University)
• Lorenzo Gentile (Research Assistant, University of Copenhagen)
• Andrew Law (Director Business Innovation, The Open University, UK)
• Herman de Leeuw (Executive Director, Groningen Declaration Network)
• Kerri Lemoie (Tech Strategist & Researcher, OpenWorks Group)
• Mark Leuba (VP Product Management, IMS Global)
• Phil Long (Special Advisor, UTO, Arizona State University; Senior Scholar, CNDLS, Georgetown University)
• Snorre Lothar von Gohren Edwin (CTO, Diwala)
• Lluís Alfons Ariño Martín (CIO, Universitat Rovira i Virgili)
• Greg Nadeau (Manager, Public Consulting Group and Chair, IMS Global Comprehensive Learner Record
CLR Workgroup)
• Nate Otto (Director, Badgr Platform, Concentric Sky)
• Simone Ravaioli (Director Strategic Partnerships, Digitary)
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 3
About the Digital Credentials Consortium
The Digital Credentials Consortium was founded by leading universities with expertise in the
design of verifiable digital credentials. Together, we are designing an infrastructure for digital
credentials of academic achievement.
Delft University of Technology (The Netherlands)
Georgia Institute of Technology (USA)
Harvard University (USA)
Hasso Plattner Institute, University of Potsdam (Germany)
Massachusetts Institute of Technology (USA)
McMaster University (Canada)
Tecnologico De Monterrey (Mexico)
TU Munich (Germany)
UC Berkeley (USA)
UC Irvine (USA)
University of Milano-Bicocca (Italy)
University of Toronto (Canada)
Founding Members
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 4
II Features of the System
Issue/Receive Credential
Store/Retrieve/Manage Credential
Share Credential
Verify Credential
Revoke Credential
Reissue Credential
Onboard Issuer
Prove Control of Credential
III Components of the System
Foundations
Open, Trust-Promoting
Credential Data Model
Credential Ecosystem Standards and Protocols
Entities in the Credential Ecosystem
Credential Exchange Protocols
Verification Procedure
Flexible Identity Model
Background: paper-based credentials
Flexible Identity Model, supporting the growth of Self-Sovereign Methods
Components
Open Source Reference Implementations
Issuer Libraries
Learner Libraries
Relying Party Libraries
Services and Tools
18
18
18
19
20
20
21
21
21
21
22
22
23
23
24
24
24
13
13
14
14
15
16
16
17
17
Table of Contents
Context
The Case for Digital Academic Credentials
What is a Digital Credential? (Documents vs Envelopes)
A University-led Effort - Digital Credentials Consortium
Guiding Principles
About this white paper
I Scope, Requirements, Terminology
Scope
Requirements
Prioritize learner agency and privacy
Enable Trust
Support Diverse Use-Cases and Technology Best-Practices
Terminology
6
6
6
7
8
8
9
9
9
9
10
11
12
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 5
Issuing Services and Integration into Student Information Systems
Verification Service
Learner-Focused Tools
Consortium-Maintained Registries
Trusted Issuer Registry
Credential Status Registry
External Infrastructure
Credential Storage
Learner Identity Providers
IV Other Considerations
Decentralized Infrastructure and Blockchains
Benefits
Redundancy
Immutability
Timestamping
Cautions and Risks
Implementation Plans
Relationship to Other Credential Standards and Initiatives
Privacy by Design and Compliance with Frameworks
The GDPR as an Applicable Framework
Design for Privacy
Technology Design
Guidelines and Requirements
Compliance
Audit Records
Appendix - Blockchain archetypes
Appendix - Terminology Alignment
Verifiable Credentials Data Model
Verifiable Credentials Use Cases
NIST Draft Whitepaper: Emerging Blockchain Identity Management Systems
References
24
25
25
25
26
26
26
26
27
27
27
27
27
28
28
28
29
30
31
31
31
32
32
33
34
35
37
37
37
37
38
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 6
Context
The Case for Digital Academic Credentials
Technology is profoundly changing higher education, but the way we issue and manage
academic credentials, which represent learning outcomes and achievements, has not yet taken
advantage of the possibilities of digital technology.
What would an academic degree look like if it was designed today? Or a professional certificate?
Or a certificate for an online course? As the question of trusted verification and authentication of
learning and credentials poses itself with increased urgency we need to redesign the way we
issue, recognize and transact with academic credentials.
Adding digital technologies enables three broad areas of benefits:
• It increases the efficiency of exchanging and evaluating credentials,
• It provides more reliable ways to protect and verify the credentials, thereby reducing the
opportunity for fraud,
• It expands learners’ control over their credentials, enabling a verifiable history of lifelong
learning.
The Digital Credentials Consortium proposes to modernize the concept of credentials, bringing
benefits to learners and to relying parties (such as employers) by improving how skills and
competencies are conveyed and recognized. Our hope is that this will strengthen trust and
enable additional value in how academic credentials are considered within nations and globally.
What is a Digital Credential? (Documents vs Envelopes)
A digital credential can be imagined as a combination of two components: a document and an
envelope into which that document is placed. The document is like the piece of paper a
university issues to a graduate, which might contain the name of the recipient as well as a
description of the credential they received. The envelope protects the content of the document
so it cannot be changed and it reliably communicates the authenticity of its contents.
Our efforts focus on the envelope and the system that provides safe delivery and storage of
multiple envelopes—similar to the postal service for mail. The envelope contains information
about who issued the credential and to whom it was issued. It creates robust links to the
identity of an issuer (e.g., a specific university) and the learner (e.g., a particular learner).
Also, both the identities and the integrity of its content can be verified to detect fraud or
tampering.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 7
Other efforts are underway that focus primarily on the document; examples include the
European Qualifications Framework and the IMS Global Comprehensive Learner Record. They
present different ways in which skills and competencies can be described. Given the global
nature of our effort, we will support different approaches as much as possible.
A University-led Effort - Digital Credentials Consortium
Our mission is to create a trusted, distributed, and shared infrastructure that becomes the
standard for issuing, storing, displaying, and verifying digital academic credentials.
The Digital Credentials Consortium (DCC) is primarily concerned with use-cases in higher
education, but we see our work as part of a broader effort to bridge post-secondary and lifelong
learning, connecting traditional institutions of higher education, non-formal education
providers, as well as the workplace, through interoperable standards.
Our goal is to contribute to an education landscape that increases learner agency and promotes
more equitable learning and career pathways.
What makes this different from other initiatives? Our effort is entirely driven by institutions of
higher education. We are committed to open source and open standards and are actively working with standards groups to complement existing efforts [see Relationship to Other Credential
Standards and Initiatives]. Finally, we expand on previous efforts in a number of important ways:
• More flexible ways to express the identities of issuers and learners that tie into existing
university services.Stronger privacy-by-design and privacy-by-default with attention to
regional legal frameworks such as the GDPR.
• More reliable revocation mechanisms and credential lifecycle management.
• More direct learner agency over one's lifelong learning record.
• Higher level of consistency between the machine-readable data of the credential, the
human-readable visual representation, and the necessary output formats—paper or digital.
The initial group of international universities leading this effort has deep expertise and
experience in designing digital credentials. Our focus is the design of the standard and
development of a transparent governance model that keeps the learner’s rights at the center.
We are not developing commercial products and services; instead, we are working with
technology companies, online learning platforms and IT vendors to create a vital ecosystem of
options to choose from. We will also work with employers to integrate verification services into
their hiring workflows. By working together, we intend to put into practice a new standard for
learner-controlled, privacy-preserving credentials, in a manner that ensures interoperability and
Learners retain primary control over their credentials. Learners’ consent is
required for issuance of digital credentials. Learners decide to whom they
grant access. Barriers to receiving and managing credentials are minimal to
enable broad participation.
Issuers control to whom they issue credentials, the particular achievement
that the credential represents, and which credential options are available to
the learner. Issuers can revoke credentials according to their institution’s
policies. Barriers to issuing credentials are minimal to enable broad and
diverse participation.
Trust in the integrity of the infrastructure is embedded in its design and
flows from transparency. Everyone is able to review how the infrastructure
and processes work. Trust in the integrity of the credentials is established
cryptographically. Credentials can be verified without consulting the
original issuer.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 8
avoids vendor lock-in. To this end, the consortium will incubate standards openly within the
framework of a W3C community group, with draft specifications and reference implementations
released under the W3C Software and Document License, and will consider collaborating with
other standards bodies as appropriate.
Guiding Principles
Learners
Issuers
Trust
Our work is informed foremost by learners’ welfare, rights, and agency.
More information about this effort can be found on the project website at
https://digitalcredentials.mit.edu.
About this white paper
This white paper sets out the design considerations of the system architecture. It serves as
the foundation for the development of reference implementations, software libraries, and
deployment prototypes by the participating universities. It describes technology choices we
are making, the tradeoffs they come with, and the state of our current thinking.
The paper is intended for a general audience, but contains sufficient technical detail to invite
review by technology system designers and digital credential developers.
The system we are designing can be used to issue and verify many different types of
academic credentials, ranging from university degrees and diplomas, to individual course
credits, to alternative credentials (including microcredentials) for online courses or face-toface workshops. Issuers decide the information they must include in the credential. Our
system will not change the way universities provide instruction, assess learning, or make
decisions about awarding credentials. It simply offers a more powerful and convenient way
to share, manage, and verify the credentials.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 9
We also intend for the white paper to act as a call-to-action that will help clarify to others (not
just partners mentioned in this paper, but other individuals, organizations and corporations) how
they can work with us.
I Scope, Requirements, Terminology
Scope
This section describes core requirements that the system is designed to fulfill.
Requirements
Require learner consent for issuing credentials: The learner is at the center of transactions
related to their credentials. Both learner and issuer consent is required to issue a credential.
Issue credentials that optimize for learner flexibility and privacy: Learners must be able to use
credentials flexibly, avoiding lock-in to a specific system. At the same time, the credentials
issued by the system will use privacy-enhancing measures to ensure that only the learner has
that freedom, while limiting other parties who may want to exploit data about the learner. This
includes longer term considerations as well, such as the learner’s desire for handling of their
data after they are deceased.
Enable seamless verification without involvement of the issuer: Learners can present their
credentials for frictionless verification without requiring the issuer to be involved. This is
particularly important during situations where the issuing institution may not be reachable,
which could happen if a university has closed, or if broader political or infrastructure problems
make contact infeasible.
The usability of the verification process is a primary consideration to avoid pitfalls such as social
Prioritize learner agency and privacy
Minimize the need for disclosure: Sharing credentials requires the minimum necessary amount
of disclosure, in particular for any personally identifying information (PII). For example, learners
need not send a transcript if all that’s requested is the equivalent of a diploma, even though the
transcript contains a superset of the data. Traditional credentials do not handle this well; to
prove you are over the age of 21, in most jurisdictions you must show a driver’s license or other
government-issued ID that reveals far more information, such as your exact date of birth and
address.
Prevent tracking: Minimize the ability of the issuer or other parties to track activities of the
learner or correlate information about them. For example, the learner may share credentials
without involving or even informing the issuer. In addition, this approach minimizes
opportunities for the scraping of credential information without consent of the learner, e.g.
to create a learner profile by correlating transactions that are recorded on a public blockchain.
Enable recovery: Replacements for lost credentials should be easily requested and securely
received from the issuer or a trusted third-party, such as standard-compliant vendors.
Offer multiple options for credential storage: The learner can choose where to store and
manage their credentials.
Provide trusted learner identity: The learner can cryptographically prove that a credential is
about themself. The system enables learners to use their credentials during digital interactions
with other systems that require authentication.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 10
engineering exploits that occur when relying parties do not understand verification status
messages or other poor visual cues. The verification process must be robust and trustworthy,
but implementable in a way that supports seamless integration into a variety of tools.
Prevent tampering and fraud: The system should minimize credential forgeability, making
credentials tamper-evident in content and presentation, and offering reliable means of
establishing authenticity.
Allow only necessary auditability: Issuers must be able to audit their own issuance and
revocation events to determine proper system behavior and detect fraudulent activity. However,
audit logs should minimize PII and only be accessible to users authorized by the issuer.
Provide display integrity: The visible credential and underlying data must be easily verifiable
as consistent. Humans rely on a range of cues (e.g., watermarks, signatures) to make a decision
about a credential’s integrity, but an under-emphasized aspect of digital credentials is the
Enable Trust
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 11
integrity of how credentials may be displayed on different screens or devices (“display
integrity”). Designing for easily verifiable human-readable displays is essential.
Support different issuers and types of credentials. The system must provide a standard way to
verify credentials from many different sources and support different types of credentials (and
credential data standards). Content of the credential can conform to a variety of schemas and
vocabularies chosen by the issuer. Some well-known examples used in academic credentialing
include PESC, EQF, CTDL, CASE, CLR, ELMO, Open Badges, and Schema.org.
Remain efficient, scalable, fault-tolerant, and highly available: High-certainty verification of
credentials is possible with minimum time and cost overhead and scales to the demands of the
global higher education system. All aspects that are relied on for learner usage are required to
be highly available with appropriate consideration of points of failure.
Ensure longevity: The system must ensure that credentials can be used by learners at a
minimum throughout their lifetime.
Design for sustainability: The system should avoid excessive resource needs and ensure that
the technical design and governance structures can evolve over time to support additional and
new use-cases.
Prevent lock-in: No part of the standards or implementing systems requires use of a proprietary
solution or specific vendor, though vendors are encouraged to build standards-compliant
solutions. It’s especially critical that learners have control over where their data resides and are
locked neither into a specific provider nor solution.
Enable integration with existing infrastructure: Issuing functionality is designed to be easy to
integrate into existing university student information systems, and offer the features demanded
by registrars and other university groups involved in issuing credentials, such as ease of
issuance, revocation, recordkeeping, etc.
Build on open standards: The open standards used in this approach may be used and adapted
for a variety of governance models. Initially, issuer identity verification support will roll out in a
trust-building, conservative manner that only takes responsibility for maintaining the identity of
members of the initiative.
Provide accessibility: In addition to adhering to accessibility guidelines and standards (such as
the W3C Web Content Accessibility Guidelines), we will seek partnerships to ensure that we are
promoting accessibility best practices. Credentials and systems based on this standard should
Support Diverse Use-Cases and Technology Best-Practices
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 12
be broadly accessible, including to those using assistive technologies.
Support international use: Our approach will ensure usability in different languages,
jurisdictions, and conventions.
We use the term learner to reflect that the individual in our use cases has lifelong learning
experiences in a variety of contexts, such as the traditional classroom, online learning,
formal/informal training, and other experiences. The learner is the central actor. Subsequently,
the pronouns “they/them” will be used as a singular for “learner” throughout. See additional
information related to the alignment of this term to other data models in the “Terminology
Alignment” appendix.
The issuer is an entity issuing credentials to the learner, in our use-case this tends to be an
academic institution. This term was chosen to convey that this is an open standard usable by
any credential issuer. While some components of the system are specific to the Digital
Credentials Consortium, all follow open standards.
A credential is a set of claims (attributes about a learner) made by an issuer. A verifiable
credential is a tamper-evident credential where the authorship can be cryptographically
verified.
Our use of the terms credential, verifiable credential, and verification (as well as related forms)
comes from the Verifiable Credentials Data Model. Appendix - Terminology Alignment provides
additional details about this terminology alignment, but an essential definition (and concept) for
this paper is verification, which is the evaluation of whether a verifiable credential is an
authentic and timely statement of the issuer.
The relying party is any organization or person the learner chooses to share a credential with.
This can be a potential employer, a bank, an educational institution, or any other party asking
for credentials that the learner consents to.
An identity registry is a specific type of verifiable data registry used to mediate the verification
of identifiers, public keys, and other relevant data. This includes issuer registries, used for the
verification of issuers, and potentially learner registries on an opt-in basis.
A revocation registry is a specific type of verifiable data registry used to store, and enable
retrieval of, revocation status of a credential.
A wallet is a term we use to refer to software installed on a learner’s mobile device, or accessible
Terminology
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 13
through a web browser, to manage their credentials and profiles. We realize that this term may
not be the best conceptual match for these functions, and is subject to change if a better
expression emerges in the credential ecosystem.
The credential system supports the following core features and interactions. The consortium
will develop an open source, standards-based reference implementation to support these
interactions, as described in Components.
II Features of the System
The “Issue Credential” task is initiated by the issuer sending an invitation to the learner to
receive a digital credential. If the learner chooses to receive the credential, they authenticate
with a site or service maintained by the issuer. The learner is presented with the credentials they
are eligible to receive (which is determined by the learner’s achievement record). The learner
makes their selections and provides the identifier(s) with which they want the credential to be
associated. The issuer generates the credential(s) and sends it/them to the learner.
As discussed in Flexible Identity Model, this process allows the learner to associate their
credentials with real-world identities, such as eID, university ID, bank ID, or even emerging
self-sovereign ID (an approach enabling learners to control when, to whom, and how they
share data about themselves). Some of these identity models further enable the learner to
cryptographically prove control over the identifier and associated documents.
Issue/Receive Credential
ISSUER
1 SEND INVITATION FOR A DIGITAL CREDENTIAL,
ALONG WITH TRADITIONAL CREDENTIALS
2 AUTHENTICATE
3 SELECT CREDENTIAL(S)
4 SEND SELECTION AND IDENTIFIER(S)
6 SEND CREDENTIAL
5 ISSUE CREDENTIAL(S)
LEARNER
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 14
At least during the prototyping phase we recommend that learners continue to receive
traditional credentials (the same way they are being issued today) and that the new digital
credentials be phased in as optional.
A specific focus will be made to develop and offer tutorials and training for issuing and
managing credentials, including how to inform students of the many benefits of accepting
and learning to manage their credentials.
Learners store and manage their credentials in a variety of different ways:
• A wallet that is installed on a device, such as a smartphone.
• A website with storage and management features that is either hosted by universities,
service providers, or technically proficient users themselves.
Credential portability across systems is a requirement that is enabled through standards
described in Credential Ecosystem Standards and Protocols.
Store/Retrieve/Manage Credential
Share Credential
The learner’s consent is central to credential exchange and verification. Since the learner
controls their credentials, the learner may choose to share them with any relying party.
The system allows learners to share credentials in different contexts, in which the learner wants
choice over which credentials to reveal (due to privacy or relevance concerns). Initially, this is
enabled at the time of issuance by providing multiple credentials of different granularity, as
described in Credential Data Model. We are also exploring emerging techniques to enable more
advanced, fine-grained options for additional data minimization and selective disclosure
(through zero knowledge proofs and redaction) for future iterations.
Different “Share Credential” contexts include:
• Share on social networking site (minimal sensitive personal data).
• Share with potential employer or educational institution.
The first context corresponds to credentials that the learner is prepared to share and make
available for verification, such as proof of graduation or certification. In this case, the social
networking site may expose instant verification through a widget (i.e., an embeddable code) in
the site. If a relying party does not wish to rely exclusively on the site’s verification widget, they
could independently verify the content of the credential through a verification tool of their
choice that conforms to our system’s verification standards (here, we envision a marketplace of
different products and services offering verification).
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 15
CREDENTIAL
LEARNER RELYING PARTY
CREDENTIAL
In the second case, which may apply to a credential with more sensitive details (such as a
transcript) the learner may not wish to share the credential broadly. Instead, they would choose
to share the credential with parties they approve, who would then use a standard-compliant
means of verification. They could share it in two ways:
1. Informal method of sharing of content (e.g. file upload, email).
2. Credential exchange protocols (based on emerging standards, described in Credential
Ecosystem Standards and Protocols).
The standards-based tools enabling these learner use cases are described in Components.
The verification process is initiated after a learner shares their credential(s) with a relying party
that then uses a standard-compliant means of verification. Establishing the identity of the issuer
is critical to establishing trust in the credential. A credential issued by the Digital Credentials
Consortium will contain pointers to sources of trust approved by the consortium to be used
during verification. This does not imply that the verification protocol outlined here is restricted
to consortium-issued credentials; this is an open standard and so a relying party may choose to
honor credentials complying with the standard anchored to different sources of trust.
The protocol cryptographically enforces that credentials may not falsely be attributed to a
source of trust that it is not a part of. Supposing that the source of trust is the Digital Credentials
Verify Credential
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 16
Consortium, a relying party will receive a credential and check the following:
1. The issuer's signing key was approved for use at the time of issuance, because the time
stamp on the issuance precedes any expiration or revocation of the key.
• The timestamp may be provided by a blockchain transaction, timestamp authority, or
other means.
• The signing key is approved by the issuer (according to the source of trust the issuer
designates in the credential).
2. The digital signature indicates the credential has not been tampered with and that the
issuer's signing key was in fact used to sign.
3. The credential has not expired, according to the expiration terms provided by the issuer in
the credential.
4. The issuer’s identifier can be found in the Digital Credentials Consortium Registry (see
“Trusted Issuer Registry” in Components for details).
5. The credential’s status has not changed to an unusable state (for example, it hasn’t been
revoked by the issuer—see “Credential Status Registry” in Components for details).
Verification returns a success/failure status along with reasons for failure; such as expired
status.
Not shown here is proof of control of a credential; i.e. that the learner is indeed the subject of
the credential. That is covered in “Prove Control of Credential”.
SHARE
DIGITAL
CREDENTIAL
VERIFY
4 ISSUER CONSORTIUM
MEMBERSHIP
1 ISSUER SIGNING KEY APPROVED
AT TIME OF ISSUANCE
2 DIGITAL SIGNATURE CHECK
3 EXPIRATION CHECK
5 CREDENTIAL STATUS
CHECK
RETURN
VERIFICATION
STATUS
LEARNER ....................................
....................................
RELYING PARTY
....................................
VERIFICATION SERVICE / LIBRARY
TRUSTED
ISSUER
REGISTRY
CREDENTIAL
STATUS
REGISTRY
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 17
Revoke Credential
The issuer is able to revoke the credential(s) they issued.
The learner does not need the ability to revoke a credential because only the learner can choose
to share a credential. The learner cannot be forced to disclose any credentials they disavow.
However, as discussed in Planning for Compliance, the system must provide ways to support
a learner’s “right to erasure”.
Reissue Credential
Credential reissuance may be required for a variety of reasons, such as a name change
associated with a life event, a typo in or loss of the original credential, or, in some cases, lost or
compromised cryptographic keys. The tasks associated with reissuance are similar to those for
the original issuance, except there is an additional step of revoking the original credential.
Onboard Issuer
The onboarding process establishes the issuer’s credential signing keys and synchronizes the
issuer’s identifier and key information to a registry for use during credential authenticity checks.
As discussed later in Open, Trust Promoting, the Digital Credentials Consortium will maintain a
registry of verified (member) issuers.
We plan to extend the onboarding process and allow various options for self-registration or use
of other registries in the future. In the meantime, other organizations can already use the system
and create credentials, but these will not be fully verified against the consortium registry (since
those issuers are not listed in the registry).
Prove Control of Credential
Digital credentials enable the learner to prove they are the intended recipient of the credential,
avoiding some forms of fraud that exist with paper credentials. The strength of proof can vary
according to the type of credential.
An example of a weaker proof that other systems have used for credentials that involve lower
stakes is by embedding the learner’s email address (or hash of it) into the credential itself.
A somewhat stronger approach could embed real-world identities (or again, a hash of the
associated identifier), such as eID, university ID, bank ID, and so on, at the discretion of the
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 18
Foundations
learner (as described in the Issue/Receive Credential section above). The learner could then
corroborate their identity with external documentation or proof (student card, etc.)
A cryptographic option, which may be combined with other approaches described here, would
be to rely on a public key that is embedded in the credential, for which the credential holder can
prove ownership. However, this approach suffers from other limitations, such as when the
learner loses control over the corresponding private key.
We are particularly interested in proof of control enabled via the Verifiable Credentials Data
Model, where a learner identifier can be expressed flexibly (as a URI), enabling stronger forms
of control and key lifecycle management via Decentralized Identifiers or Solid Profiles. This
approach enables integration into strong authentication ceremonies, such as those enabled
through the FIDO2 open standard.
This section describes the foundational components of a learner-centric credentialing
ecosystem. As we progress through our prototype phases, we will enable more component
options, thereby enabling more learner options for control, flexibility, and privacy.
III Components of the System
The Digital Credentials Consortium optimizes the infrastructure for openness whenever
possible. The relying party can choose their preferred verification service provider and/or
apply their own extended criteria, such as the set of issuers they deem trustworthy.
Activities on the decentralized infrastructure can be transparently observed and, in combination
with internal records of the centralized components, a complete audit trail can be created.
Administrators can therefore monitor credential issuance and revocation.
While audit trails and records of the issuance system itself are determined by issuer
requirements and not considered part of the standard, we will suggest best practices for
detecting fraud and avoiding misuse.
Trust remains the highest goal for the infrastructure and it is essential for establishing issuer
authenticity. To align the early stages of development with the high requirements for issuer
authenticity, we decided for the initial implementation to define a closed registry for issuers,
Open, Trust-Promoting
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 19
while aiming for an open, self-governed registry. As the protocol is open, any other party is
allowed to make its own decisions about sources of truth. Details of these implementation
choices and components follow.
The credential “envelope” format is the primary driver of interoperability. The emerging W3C
Verifiable Credentials (VC) Data Model defines a means of expressing digital credentials in a
tamper-evident way that puts the learner at the center. Its structure is lightweight, satisfying
the “envelope” properties, and allowing flexible definition of schemas and interoperability across
different kinds of credentials.
We have selected Verifiable Credentials for our design because this method fulfills the
requirements listed in Section I above and offers the following properties:
• Digital, tamper-evident, and machine-readable.
• Learner is at the center of exchanges of their data; their consent is required to exchange.
• Learner may cryptographically prove the credential is about them.
• Verification does not require consulting the issuer.
• Content of the credential can conform to a variety of schemas and vocabularies chosen by
the issuer. Some well-known examples used in academic credentialing include PESC, EQF,
CTDL, ELMO, Europass EDCI Data Model, Open Badges, and Schema.org.
• Robust consideration of privacy, security, accessibility, and internationalization
recommendations, making it suitable for high-stakes credentials such as transcripts.
The figure demonstrates the elements of a Verifiable Credential. The credential data (the
“document” or “payload”) can vary according to the issuer’s credentialing requirements, while
allowing a standard/consistent means of validating credentials.
Credential Data Model
{
VERIFIABLE CREDENTIAL (VC)
CREDENTIAL TYPE
CREDENTIAL DATA
SUBJECT (LEARNER) IDENTIFIER
ISSUER IDENTIFIER
ISSUANCE DATE
EXPIRATION DATE
CREDENTIAL STATUS
REVOCATION REGISTRY
PROOF
CREDENTIAL “TYPE” ENABLES FLEXIBLE
CHOICE OF VOCABULARIES/TAXONOMIES
USED IN ACADEMIC CREDENTIALS
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 20
While the issuer is responsible for the credential content (including schema and vocabularies),
it is recommended that issuers provide credentials at a level of granularity that is most useful to
learners and relying parties. One approach is for the issuer to supply multiple credentials with a
variety of granularity levels for the learner to share, for example issuing an entire transcript with
a list of courses as one credential, or issuing individual credentials for each course, which can
then be aggregated into a transcript by the relying party. We favor solutions that offer a higher
degree of flexibility, but maintain the issuer’s control over the granularity of their credentials (for
example, if the issuer chooses to disallow cherry-picking only high grade courses when
presenting an official transcript).
This results in a set of tamper-evident credentials that can be used by the learner in a variety of
contexts. For example, if a relying party only needs to see that the student has a 4-year diploma,
then the learner (or technically, the learner’s wallet or agent) would share their diploma as
opposed to a full transcript. At the same time, the learner isn’t able to tamper with the content
of a credential—attempting to do so will cause it to fail verification.
The Verifiable Credentials Data Model allows the learner to disclose any credentials they choose,
but as the learner is at the center of the exchange, they can also choose not to disclose some
credentials. The learner determines which irreducible credential they want to share, and the
relying party decides what level of detail they are willing to accept.
Enabling learner control over which credential information is shared can also be achieved with
data minimization / selective disclosure techniques, consistent with the Verifiable Credentials
Data Model (see section 5.8 Zero Knowledge Proofs for one such technique).
The W3C Verifiable Credentials (VC) Data Model is still a relatively new standard and we will
continue to assess and address any possible issues with our implementation by working with
the relevant standards bodies, including the W3C Verifiable Credentials Working Group, W3C
Credentials Community Group, W3C Decentralized Identifier Working Group, and Decentralized
Identity Foundation.
The Verifiable Credentials data model provides the basis for an interoperable credentialing
ecosystem. Emerging standards and protocols enabling flexible learner-focused credential
storage and exchange are also essential to learner control and interoperability. These standards
will be critical in the development of related tools over time.
Entities in the Credential Ecosystem
An example deployment of a credential ecosystem—including the entities that enable
management and exchange of credentials and associated identities—are shown below. In this
example, the learner interacts with a “wallet”, which is software installed on a learner’s device
Credential Ecosystem Standards and Protocols
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 21
enabling secure on-device storage of cryptographic keys or other identification material.
ISSUER WALLET RELYING PARTY
AGENT/HUB ..........
..........
..........
.......... ..........
Image adapted from “A Comprehensive Guide to Self Sovereign Identity”, by Heather Vescent and Kaliya Young
Alternatively, a learner could also interact with a web-based interface, while still using strong
authentication via FIDO2 specifications.
Credentials may reside on the same device, or may exist in learner-chosen secure encrypted
storage locations that are currently referred to “hubs” or “vaults.” Some reference architectures
include Identity Hubs and Encrypted Data Vaults.
An “agent” is the term used to describe software assisting the learner in the management,
storage, and exchange of their credentials. The agent understands the protocols, but asks the
learner for consent before sharing sensitive data.
Credential Exchange Protocols
Emerging protocols enable these operations and exchanges to happen interoperably. For
example, the emerging credential exchange protocols involve an interaction by which:
1. The relying party’s agent communicates what credential schemas (or even issuers)
they accept,
2. The learner’s agent parses this information and searches the learner’s data storage for
matching credentials, and
3. The learner’s agent packages and sends the credential to the relying party.
Such exchanges are enabled through the draft specifications and protocols Credential Exchange
Manifest and Credential Handler API.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 22
The process by which a credential is verified is another foundational piece of our approach, and
is described in Verify Credential earlier in the white paper.
Verification Procedure
Background: paper-based credentials
With paper-based credentials, the question of learner identity is resolved by comparison with
other identity documents. For example, the student’s full name, birthdate, and birthplace are
printed on the document, allowing the requesting party to first look at the certificate and then
at a provided official ID. If the identity on the official document matches with the identity on
the certificate, the credential is valid.
Establishing issuer identity in paper-based credentials relies on a combination of conventions
(watermarks, sealed envelopes) and existing trust mechanisms (direct send of the credential
from the university). This approach could be replicated digitally, but there are new, emerging
approaches that will provide the same level of assurance with regard to identity attributes.
Flexible Identity Model, supporting the growth of Self-Sovereign Methods
Our approach to identity is influenced by two primary factors:
1. Emerging self-sovereign identity and learner-controlled storage standards promise to pro
mote learner (and issuer) control of identity and data.
2. Legislation or other regional requirements may add the need to link a credential with a
specific form of identity, such as a national ID. Supporting such cases is necessary for the
credential to be usable by the learner.
Our solution to this rests on the identifier approach used by the Verifiable Credentials Data
Model. The VC Data Model provides a flexible framework for learner identification via URIs,
enabling the use of traditional identity schemes as well as new emerging decentralized or
self-sovereign identity schemes, such as those compliant with the Decentralized Identifier
Data Model.
We are evaluating which methods to include in consortium prototypes, and intend to explore
methods with a range of characteristics: (1) methods that bridge to existing identification methods
used by consortium issuers, (2) open-source, non-commercial methods, (3) interoperable methods
provided by implementation partners.
Flexible Identity Model
Building on the foundation of this standards-based approach, we partition the system
components as follows:
Components
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 23
• Open source reference implementations: These are developed by the consortium, and
include reusable libraries and learner-focused tools (such as wallets or e-portfolios) to
promote learner control of their credentials and avoid vendor lock-in.
• Commercial or other external implementations: We envision a thriving ecosystem of service
providers and technology companies who implement the standards and offer a variety of
solutions to issuers, learners, and relying parties. They are free to use the open source
reference libraries.
• Consortium-Maintained Registries: These registries must be maintained by the consortium.
They are also standards-based and may be adapted by other issuers. These are used during
the credential verification process to establish their integrity and authenticity.
• Identity Providers: As described in Flexible Identity Model, URIs or DIDs (as used in the
Verifiable Credentials Data Model) enable flexible identification methods that can be chosen
(independently) by the issuer and learner dependent on factors such as university
convention, regional/local requirements, learner convenience, or even self-sovereign
methods. The Identity Providers are external to the system, but the consortium may
contribute to open source development of relevant identity methods supporting our use
cases (e.g., bridge to eID or Shibboleth or even self-sovereign DID methods).
These components are described in the following sections.
COMMERCIAL OR
OTHER EXTERNAL
IMPLEMENTATIONS
OPEN SOURCE
REFERENCE
IMPLEMENTATIONS
CONSORTIUMMAINTAINED
REGISTERIES
IDENTITY PROVIDERS
............................................................
...................................................................................................
...................................................................................................
CREDENTIAL
ISSUING
SAAS PRODUCT
LEARNERFOCUSED TOOLS,
WALLETS
EXTERNAL
VERIFIER
SERVICES
CREDENTIAL
STATUS
REGISTRY
TRUSTED
ISSUER
REGISTRY
ISSUER
LIBRARIES
LEARNER
LIBRARIES
RELYING PARTY
LIBRARIES
ISSUING
SERVICE
ISSUER ISSUES CREDENTIAL
TO LEARNER URI/DID
URIs OR DIDs
URIs OR DIDs
LEARNER
E-PORTFOLIO
REDENTIAL WALLET,
IDENTIFIER WALLET
VERIFICATION
SERVICE
}
SSL-PKI
eID
SHIBBOLETH
ATHENS
LEARNERSELECTED
DID METHOD
A number of libraries will be provided as reference implementations by the Digital Credentials
Open Source Reference Implementations
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 24
Consortium to enable the use of our new system as either issuer, learner, or relying party. Due
to the open-source nature of the system, other implementations adhering to the standard are
permitted.
Issuer Libraries
Issuer libraries provide utilities supporting standard-compliant credential issuers. This includes
tools for onboarding new issuers as well as for issuing and revoking credentials. Issuer libraries
also define APIs supporting integrations with student information systems (SIS).
Learner Libraries
Learner libraries provide reusable functionality to support learner-focused tools and applications
such as credential management applications or websites. These libraries support receiving,
viewing, and sharing credentials as well as, and further management functions.
Relying Party Libraries
Relying parties or service providers wishing to verify any shared credentials can use this library
to integrate into their systems or build custom verification workflows.
The consortium will develop and provide services and tools based on the above libraries as
reference implementations. The consortium will not offer commercial services or compete with
service providers. We encourage and support other organizations to develop products/services
based on these standards and libraries. Users may choose to use a standard-compliant
alternative.
Issuing Services and Integration into Student Information Systems
The consortium will develop open source issuing tools and services (based on the issuer
libraries) to be used by consortium issuers in early stages of the project. These may be adapted
and deployed for use by other (non-consortium) issuers.
Central to this effort is ensuring that issuers can easily integrate the issuing tools and services
into their existing Student Information Systems and workflows, thereby avoiding burdensome
installation of new systems or data processing steps. To that end, the services will expose APIs
enabling flexible integration with external data sources. These interfaces will be generic — not
tied to any specific provider — so they can be adapted to a range of systems and workflows.
Bearing in mind that our consortium members require specific SIS adapters, we will develop and
deploy those SIS adapters for our own use and as reference implementations for others to use.
Expected prototypes include CAMPUSonline, PeopleSoft, and UGOV adapters.
Services and Tools
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 25
Verification Service
Verification services will be integrated into sites and registrar systems of consortium members.
We will deploy and host verification services for the initial project partners for testing as the
standard develops.
Learner-Focused Tools
The biggest gaps in current credentialing ecosystems are around learner scenarios. The
consortium will encourage the creation of services and tools for learners in support of secure
credential receipt, storage, and exchange.
These are expected to include:
• Standards-based Credential Wallet enabling mobile credential management.
• A web-based credential management interface, like an e-portfolio system, that is either
hosted by universities, service providers, or technically proficient users themselves.
• Identity management tools, based on Flexible Identity Approach.
The foundations of these tools are described in Credential Ecosystem Standards and Protocols.
ISSUING SERVICE SIS ADAPTERS
STUDENT INFORMATION SYSTEMS
ISSUER
LIBRARIES
CAMPUS PEOPLESOFT ... online
Some of the functions needed to verify a credential and its issuer are provided by decentralized
infrastructure. The main characteristic of these components is that they are publicly accessible
and any stakeholder can use them. The write permissions for these components vary depending
on the governance model. This allows any stakeholder such as a relying party to hold their own
version of the components needed to verify a credential, thus reducing dependency on the
infrastructure of third-parties. See Infrastructure for more detailed considerations.
Consortium-Maintained Registries
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 26
Trusted Issuer Registry
A fundamental challenge with issuing digitally signed credentials is confirming that the public
key used to sign a credential does in fact belong to the claimed institution.
To that end, the consortium will maintain a registry of the issuing identifiers for consortium
members. The identifiers will be resolvable per the Flexible Identity Model. Our initial
implementation of the registry will record DNS names and the associated members' SSL
(Secure Socket Layer) certificates (referred to as SSL-PKI, Public Key Infrastructure, going
forward), an approach that provides governance levers while also making it easier to later
onboard new issuers.
Although the consortium will use SSL-PKI together with the consortium's registry, other
organizations may use SSL-PKI with their own registry, or even SSL-PKI alone. Without a
registry, however, the responsibility for verifying the authenticity of the signing key is pushed
to the relying party—the relying party has to know which issuer identity to trust.
The registry additionally provides a mechanism for the consortium to maintain consistent and
thoughtful development of the standard as we work through the early phases of deployment.
It is critical to ensure the credentials produced by this effort have the same weight as the
traditional (paper-based) credentials. As the system matures, we will work to further
decentralize issuer verification.
Credential Status Registry
The issuer may need to revoke a credential after issuance. For cases like this, credential status
registries are part of our decentralized infrastructure. Issuers have control over their respective
credential status registry where they can update the status of the validity of credentials. During
the verification process this registry is consulted. To ensure this registry is privacy preserving,
different data structures supporting data minimisation (such as Cryptographic Accumulators,
Bloom Filters etc.) will be explored.
We recognize there is a need for trust anchors for issuer and learner identities that can’t be
unilaterally dictated by our consortium. Further, learner-centric credentialing necessitates
learner choice over credential data storage. Our design must therefore accommodate external
infrastructures for the following components.
External Infrastructure
Credential Storage
The learner may choose their desired credential storage location. This may be a cloud storage
account controlled by the learner or a trusted third party committed to storing learner
credentials securely (for example, the university or third-party vendor may perform this service).
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 27
Learner Identity Providers
As described in “Flexible Identity Model,” different digital credential projects will have different
requirements for identification of the learner in the credential. In some cases, the learner may
want to link their credentials to an official identity. This may include student identity systems
(Shibboleth, Athens), national eID schemes (eIDAS), or other verified identity providers such as
banks (BankID).
It is up to the individual credential project to decide what level of verification is needed to
be accepted as an identity endpoint. While identity service providers are external to our system,
the interfaces must be standards-based and interoperable. We are using Decentralized
Identifiers (DID) to provide a standard interface to these different identity providers and
services. DID service endpoints provide trust anchors through different external identity
providers.
We will support the development of interfaces to a variety of identity services, as well as
interfaces to self-sovereign alternatives where desired by the learner.
Decentralized Infrastructure and Blockchains
IV Other Considerations
As described in Components, a decentralized credentialing ecosystem is more robust, scalable,
and flexible than a centralized system. Blockchain, a type of distributed ledger, has garnered
excitement and hype—and often subsequent disillusionment—as a one-size-fits-all solution for
decentralization. It has become clear over the last few years that a blockchain by itself does not
solve all business use cases. However, when used strategically, blockchains, or some aspects of
them, can benefit credentialing ecosystems by improving efficiency and trust around issuance
and exchange of credentials.
Blockchain can provide three main benefits for credentialing:
Redundancy
Decentralized networks (like a blockchain) provide redundancy, thereby reducing single points
of failure common with centralized systems. Even though redundantly duplicated across a
decentralized network, the data is nevertheless logically centralized. This effectively provides
the best of both worlds—a central point of truth for inspecting credential status (such as whether
it’s revoked) but backed by the entire decentralized network, removing single points of failure
present in centralized networks.
Benefits
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 28
In contrast, consider two categories of centralization in existing digital credentialing solutions
and their related risks:
• Solutions in which credentials must be retrieved and verified through an issuer (or a third
party) website every time the learner shares a credential are vulnerable to service outages,
or worse, disappearance (if, for example, the issuer decides not to host these files anymore,
or if the issuer goes out of business).
• Some blockchain-based digital credential solutions attempt to remedy the above issue by
anchoring a hash of the credential to a blockchain, but it still relies on the issuer (or third
party) to host the issuer’s public keys and credential revocation list. Verification of these
credentials therefore is similarly vulnerable to service outages or failures due to missing
file dependencies.
Immutability
Transactions in a blockchain are cryptographically chained to prior transactions, making them
difficult to modify or remove after the fact. Any update to the blockchain state requires a
new transaction that is visible to all parties in the public network. Independent parties can
consequently collaborate and trust that all transactions posed to the ledger are legitimate.
Learners can reliably share their academic credentials and a relying party can verify the integrity
of the credentials via the blockchain—without having to consult the issuing institution.
Issuers can reliably manage the status of credentials—say, revoking a credential if it was issued in
error—through an immutable and trustworthy source of truth without introducing single points
of failure.
Timestamping
To check credential validity, trusted timestamping is a conditio sine qua non. Anchoring
information to a blockchain is a simple and reliable means to ensure timestamped credential
integrity.
The Gartner report “How to Position Blockchain Platforms to Increase Adoption” (summarized
in this article) describes common pitfalls related to enterprise blockchain hype (enterprise
blockchains are typically private/permissioned; see Appendix - Blockchain Archetypes for
details). The gap between business requirements on the one hand, and the actual features
provided by a blockchain solution on the other, can compromise the success of a project and
can even lead to blockchain overuse—storing everything on a blockchain—when other solutions
would be more scalable and less expensive. This problem is worsened by the absence or infancy
of interoperable standards around data stored on a blockchain, risking vendor lock-in.
Cautions and Risks
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Worse still, in our use case, overuse of blockchain might compromise the learner’s privacy. As
discussed in Privacy by Design and Compliance with Frameworks, immutability of blockchains
can interfere with the right to be forgotten, as provided by the European Union (EU) General
Data Protection Regulation (GDPR).
Finally, the energy consumption and consequent carbon emissions due to current
implementations of public permissionless blockchains (e.g., see recent study The Carbon
Footprint of Bitcoin) lead to grave concerns about the environmental impact of such
blockchain-based solutions.
To be clear, the cost of any individual transaction is not the concern. In fact, some of the authors
of this paper have designed public blockchain-based systems that batch credential issuing such
that only a single transaction per hundreds of thousands of credentials is needed. Our concern,
rather, is holistic — we do not want to design a large-scale system based on an environmentally
damaging foundation.
As a loose analogy, it is not the per gallon mileage of our hybrid vehicle we are concerned
about, but the environmental cost of the highway (building it, maintaining it, etc). As a group,
we have decided that we will not contribute to this problem. We do, however, believe strongly
in open systems and protocols, and so would advocate for other consensus mechanisms, such
as Proof of Stake, that still allow a public, permissionless foundation without associated adverse
environmental effects. Systems incorporating such blockchains do not necessarily affect the
underlying energy consumption: among other factors, the price of the underlying cryptoasset
increases (or decreases) the incentive for participating as a miner, resulting in an altered energy
consumption. Our approach will leverage the benefits of blockchains while avoiding pitfalls and
risks described here.
Due to the environmental impact of Proof-of-Work consensus mechanisms, we will not deploy
the initial system on a public permissionless blockchain.
We plan to take a phased approach:
• Develop and deploy the registries on a public permissioned blockchain.
• Monitor the evolution of consensus mechanisms in public permissionless blockchains and
migrate when/if appropriate. We will manage the transition/migration in a way that creates
minimal additional effort for issuers or learners. Existing credentials will remain valid and
verifiable.
Our preference is to build on open standards and public access (see Appendix: Blockchain
Archetypes).
Implementation Plans
29
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
The data stored on the blockchain must be reduced to only what’s required for verification, and
further adhere to best practices for ensuring learner privacy. This ongoing effort is described in
Privacy by Design and Compliance with Frameworks.
30
Relationship to Other Credential Standards and Initiatives
As pointed out, our goal is to create a trusted, distributed, and shared infrastructure that
becomes the standard for issuing, storing, displaying, and verifying digital academic credentials.
Our group has deep expertise and experience in the design of digital credentials and is
committed to open source, open standards, and interoperability. We do not want to reinvent
the wheel, but to use existing standards, combine them wisely and, if valuable, advance them.
Another task is to develop a transparent learner-centric governance model. Members of our
group are actively working with standardisation groups to complement existing efforts.
Credentials
• Groningen Declaration
• W3C Verifiable Credentials Data Model 1.0
• OpenBadges
• OpenCerts
• ELMO and EMREX
• Europass EDCI
• IMS Global Comprehensive Learner Record, developed with guidance from the American
Association of Collegiate Registrars and Admissions Officers (AACRAO)
Blockchain
• Ethereum & Hyperledger
• European Blockchain Partnership (EBP) - European Blockchain Service Infrastructure (EBSI)
Identity management & Self-Sovereign Identity
• W3C Credentials Community Group
• W3C Decentralized Identifiers
• Decentralized Identity Foundation
• Eduroam & eduGain
• European Self-Sovereign Identity Framework (ESSIF) - European Blockchain Service
Infrastructure (EBSI)
Privacy by Design and Compliance with Frameworks
The GDPR as an Applicable Framework
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
For academic credentials to be useful they must be linkable to real-world identification data,
which raises significant issues of data protection and privacy. Placing learner privacy at the core
of our design is not just for compliance with legal frameworks, but also an ethical position we
choose to take.
Protection of privacy is considered a human right (Universal Declaration of Human Rights,
UN, art. 12). However, around the world there are various and inconsistent definitions of and
protections for personal data. As a starting point, we follow the definition of personal data
adopted for the General Data Protection Regulation (GDPR) by the European Commission,
which states that “Personal data is any information that relates to an identified or identifiable
living individual. Different pieces of information, which collected together can lead to the
identification of a particular person, also constitute personal data.”
Since we are developing a global solution, we chose to align most closely with the European
Union (EU) GDPR, at least initially. At this point, the GDPR appears to prioritize individual rights
and establish globally respected, broadly applicable, and widely used standards. For example,
the GDPR regulates the protection and control over personal data in the European Union in part
by regulating all parties that receive personal data from the EU, even if those parties are located
outside the EU. Further restrictions apply for sharing personal data with parties outside the EU
and in countries where data protection laws are not considered (by the EU) to be adequate. In
any case, it means that the way in which credentialing data is protected outside the EU still can
be affected by the GDPR.
This means that compliance with the GDPR should maximize our ability to design a system that
is (a) legally relevant for many (if not all) potential users; (b) based on a useful point of reference
for compliance with legal frameworks being developed in other parts of the world; and (c) that is
broadly aligned with our core ethical principles.
In addition, we use a design process that can respond to the fact that laws and insights into
their interpretation with respect to new technologies continue to be in development. We plan
to incorporate various experts in reviewing our approach, collaborating with both legal and
technology experts, to find solutions. We encourage others to review our approach with their
legal counsel, and we welcome comments and feedback to improve compliance with emerging
legal standards over time.
31
To plan for GDPR-compliance, it benefits system designers to use a privacy-by-design
approach — that is, consider the privacy implications of every decision in the design process.
This combines technology design decisions, decisions about the organizational context (how
individuals and organizations interface with the technology), and ways to document levels of
compliance with the guidelines.
Design for Privacy
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Our privacy-by-design approach follows these three dimensions:
• Technology Design - Ensure learner privacy is core to the standards and systems we
develop. Give as much prior notice about and control over the use of their data to the
learners themselves through the design of the software and processes. For example, we
require learner consent when digital credentials are issued.
• Guidelines and Requirements - Publish a set of requirements and guidelines for
organizations (technology companies, universities, governments) interested in
implementing the standard or interfacing with it.
• Compliance - Monitor the evolution of laws and regulations related to private data and
public ledger technology to keep track of significant developments. Update our solution as
needed to reasonably enable compliance with the GDPR and, to the extent reasonably
feasible, other legal frameworks.
32
From a technical point of view, there are many technology design choices that relate to
protection of personal data and compliance with the GDPR and other legal frameworks.
Minimally, this includes long-established secure data handling practices, such as encrypting
data in transit and at rest, access control mechanisms, and time limits after which data is
deleted automatically. We believe the the GDPR encourages an even more comprehensive
consideration of privacy implications, and therefore will use a privacy-by-design approach
throughout the system design. Some examples include minimizing the footprint of personal
data—even pseudonymous data (such as IP addresses and salted hashes of data)—that could be
re-identifiable. Technical solutions such as zero-knowledge proofs can offer even more
protections, reducing the amount of data the learner has to disclose during the validation
process of a credential.
Technology Design
Other personal data protection measures are more organizational and require clear guidelines
describing implementation and use of the system. One example is to require, systematically,
obtainment of consent from the data subject (i.e., the person that can be identified by the data)
before data can be processed or stored for certain purposes (where consent is legally required),
and also a commitment from the issuer and/or relying party of the personal data to only store or
process the data for specific purposes.
The guidelines will clarify the baseline rules and regulations that our system and solution are
aiming to satisfy. We intend that this transparency should simplify a user’s ability to assess the
legal sufficiency of the system for that user’s own needs. Secondly, the guidelines will explain
our perspective on which party, in various cases, we believe or expect would be responsible for
protecting data and implementing the guidelines. Finally, the guidelines will discuss what
measures may be taken to protect data in various specific cases.
Guidelines and Requirements
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 33
In order to document compliance, we attempt to be as clear as possible regarding (1) who is
responsible for implementing the guidelines, and (2) what is their legal basis for processing the
data. If this is vague, there is the risk that privacy is not protected adequately. Who is responsible will depend on a variety of factors, such as which party is the source of the data, what laws
are applicable, and who is in control of the system where the data is stored. With respect to
processing, the GDPR recognizes six possible reasons for processing personal data, including not
only consent but also “legitimate interests” and when the data is necessary to perform a contract for the data subject. Several rights and obligations of the data subject, controllers, and
processors depend on which of the foregoing reasons is the legal basis for processing.
Our work builds on cutting-edge technology, and the laws that should be complied with are
often quite new as well. For example, the GDPR only became enforceable in May 2018. This
means that in some cases, it may not be fully clear yet how this regulation should be complied
with or how it may be enforced in a multilateral and multinational setting. Furthermore, there is
sometimes a lack of clarity how the GDPR relates to other laws and requirements, for example
the duty of the state to archive citizens’ data. In France, education achievements and learning
outcomes have to be registered for fifty years. In the Netherlands, “holding terms” apply to
transcripts, grades, degrees, etc. There is an obligation to hold transcripts for 2 years, but after
that, they should be “burnt.”
A specific issue we are considering is how to comply with the ‘right to erasure” that is provided
to data subjects in the GDPR. According to the GDPR, a data subject can request that an entity
controlling their personal data (under the GDPR, a “data controller”) erase such data. To minimize
the chance of a request for erasure not being honored (even if that outcome may be legal) and
personal data being available on a blockchain forever, our approach minimizes the personal
footprint on a blockchain from the outset. That said, there remain open questions around the
implications of the right to erasure. The right of erasure is not absolute, and how a controller
responds to a request will depend in part on why the controller obtained and used the data in
the first place, i.e., the underlying legal basis for processing.
We are closely monitoring developments of the European Commission, which is concerned with
implementing and enforcing the GDPR, and believe this consortium can help advance the
discussion in areas of ambiguity and help evolve our understanding on how to implement the
legal requirements of the GDPR and other similar frameworks.
While digital credentialing approaches address some forms of fraud in existing systems, they
may introduce others. Our design decisions have the goal of maximizing security and trust in the
Compliance
Audit Records
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 34
approach. When deploying a credentialing system, a different category of threats emerges
(outside of the scope of the standard and reference libraries). Our reference implementations
and best practices guidance will support the ability to perform audits such as subsequently
comparing an unexpected batch (reported by a different system). This will be done in a way that
doesn’t expose additional recipient info—an issuer only needs to know that the issued set is
larger than the expected set in order to initiate a batch revocation and reissuance.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 35
Appendix - Blockchain archetypes
A blockchain is a specific type of distributed ledger technology. A blockchain is made up of a
decentralized network of individual parties. These parties, called nodes, agree about data stored
in the network and the rules under which this data can be changed. Each block in such a chain
represents a single state; the newest block represents the current state. The state changes are
represented by transactions issued by participants which are stored alongside a block. To fit
different needs, a wide variety of blockchain implementations, consensus mechanisms, and
architecture models is available.
In a nutshell, the main characteristics of blockchains are:
• Consensus: All transactions are validated by participating nodes; a consensus mechanism
ensures the integrity of the ledger.
• Decentralized: Peer-to-Peer (P2P) network, no intermediary required.
• Cryptography: Hashes and digital signatures ensure data integrity and ownership.
• Immutability: Data once written cannot be altered or removed from the network.
BLOCKCHAIN TYPE
PUBLIC
PERMISSIONLESS
BLOCKCHAINS
PUBLIC
PERMISSIONED
BLOCKCHAINS
PRIVATE
PERMISSIONED
BLOCKCHAINS
PRIVATE
PERMISSIONLESS
BLOCKCHAINS
EXPLANATION EXAMPLE VISUALIZATION
In these blockchain systems, everybody can
participate in the consensus mechanism of the
blockchain. Also, everyone in the world with a
connection to the internet is able to transact
and see the full transaction log.
Bitcoin, LiteCoin,
Ethereum
Ripple, private
versions of Ethereum
Rubix, Hyperledger
(Partially) Exonum
These blockchain systems allow everyone with
a connection to the internet to transact and see
the transaction log of the blockchain, but only a
restricted amount of nodes can participate in
the consensus mechanism.
These blockchain systems restrict both the
ability to transact and view the transaction log
to only the participating nodes in the system,
and the architect or owner of the blockchain
system is able to determine who can participate
in the blockchain system and which node can
participate in the consensus mechanism.
These blockchain systems are restricted in who
can transact and see the transaction log, but the
consensus mechanism is open to anyone.
Modified from: Table 2, p. 16: ALLESSIE D, SOBOLEWSKI M, VACCARI L, PIGNATELLI F (Editor), Blockchain for digital government, EUR
29677 EN, Publications Office of the European Union, Luxembourg, 2019, ISBN 978-92-76- 00581-0, doi:10.2760/942739, JRC115049
https://publications.jrc.ec.europa.eu/repository/bitstream/JRC115049/blockchain_for_digital_government_online.pdf
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 36
Appendix - Terminology Alignment
In this paper, the term learner is used interchangeably with a Verifiable Credential subject.
Further, the subject is the same as the holder in the use cases described in this paper.
The following terms are equivalent to Verifiable Credentials Data Model terminology: credential,
verifiable credential, issuer, relying party.
In this paper, we haven’t called out the separate role of verifier; instead we chose to emphasize
the verification process to avoid additional complexity by calling out this separate role. However,
as with the Verifiable Credentials Data Model, the standard allows the roles of verifier and
relying party to be separate.
The tasks described in section II are based on Verifiable Credentials Use Cases User Sequences.
Verifiable Credentials Data Model
Verifiable Credentials Use Cases
Our terminology and architecture aligns with NIST’s whitepaper (draft) “A Taxonomic Approach
to Understanding Emerging Blockchain Identity Management Systems” (https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.07092019-draft.pdf), as follows.
Our architecture is most closely described as “Off-chain Objects coupled with Global Identifiers
Registry for Issuers”; “Off-chain Objects coupled with Global Credentials Registry”.
The Trusted Issuer Registry corresponds to the “Global Identifiers Registry” for issuers.
Credentials are stored as off-chain objects. The Credential Status Registry is used as in the
Off-Chain Objects coupled with Global Credentials Registry. The Issuance Registry is an
Anchors Registry.
NIST Draft Whitepaper: Emerging Blockchain Identity
Management Systems
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License 37
• W3C Verifiable Credentials Data Model 1.0: https://w3c.github.io/vc-data-model
• W3C Verifiable Credentials Use Cases: https://w3c.github.io/vc-use-cases/
• W3C Decentralized Identifiers: https://w3c-ccg.github.io/did-spec/
• W3C Decentralized Identifier Method Registry:
https://w3c-ccg.github.io/did-method-registry/
• NIST A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems:
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.07092019-draft.pdf
• How to Position Blockchain Platforms to Increase Adoption:
https://www.gartner.com/document/3909078?ref=so
rAll&refval=221177808&qid=b96eab586d1bd06d8898f
• Gartner reveals seven mistakes to avoid in blockchain:
https://www.gartner.com/en/newsroom/
press-releases/2019-06-12-gartner-reveals-seven-mistakes-to-avoid-in-blockchain
• “A Comprehensive Guide to Self Sovereign Identity”:
https://www.amazon.com/Comprehensive-Guide-Self-Sovereign-Identity-ebook/dp/B07Q3TXLDP?Sub
scriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-brave-20&link
Code=xm2&camp=2025&creative=165953&creativeASIN=B07Q3TXLDP
• European Qualifications Framework:
https://www.cedefop.europa.eu/en/events-and-projects/proj
ects/european-qualifications-framework-eqf
• IMS Global Comprehensive Learner Record:
https://www.imsglobal.org/activity/comprehensive-learner-record
• W3C Software and Document License:
https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document
• Decentralized Identity Foundation Identity Hubs:
https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md
• Encrypted Data Vaults:
https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/fi
nal-documents/encrypted-data-vaults.pdf
• FIDO/FIDO2 specifications: https://fidoalliance.org/fido2/
• W3C Web Content Accessibility Guidelines: https://www.w3.org/TR/WCAG21/
References |