Certified For Life — Decentralized Diploma Management System

A proposal prepared by BigchainDB for Information Vlaanderen (Flemish Government, Belgium)

Prepared By: Gautam Dhameja, BigchainDB

Reviewed By: Dimitri De Jonghe, BigchainDB

Prepared For: Informatie Vlaanderen and Partners

Dated: July 10, 2018

Introduction

In the education sector, availability and accessibility of diploma/certificate data is crucial for faster growth and better utilization of higher education and job opportunities. Today, the process of sharing and managing diploma data is mostly centralized with control being held by the authorities. To make the process simplified and to give more control to the students and graduates over their diploma data, Information Vlaanderen, along with their partners, are exploring blockchain based solutions. As a first step, Information Vlaanderen and Federation Wallonie-Bruxelles did a proof of concept about international exchange of diploma data — Certified For Life. There were some options analyzed and a simple prototype was developed to showcase the exchange and sharing of diploma data using a blockchain based system. During the prototyping, some issues were encountered mainly around GDPR compliance, data ownership and authenticity of data sources. To address these issues, Information Vlaanderen asked the BigchainDB Consulting team to come with an alternative approach.

This report proposes a decentralized diploma data management solution and addresses the issues encountered during the initial prototyping. The report also proposes possible extensions and enhancements on top of the proposed solution.

Abstract

Currently, the diploma data is stored in centralized servers at universities of different countries, affiliated with different governments. In scenarios when the graduates need to share their diploma data with other schools in different countries for higher education or with third-parties for recruitment purposes, it becomes difficult for the graduates to control access and share their diploma data with the interested parties. This report proposes a decentralized solution for management and sharing of diploma data between students, universities, governments, and other third-parties interested in that data.

The solution aims at giving more control and ownership to the graduates who have earned the diploma so that they can decide on whether to share the information or not. The solution also aims at making the diploma data more accessible and easier to share while also enhancing security and tamper resistance.

The solution we propose gives full control and ownership of the diploma data to the graduates. From a high level, the solution consists of the following flow — the schools create and digitally sign the diploma and provide this digital and signed copy of the diploma to the respective graduate. The graduate holds and can share the diploma data in full or in parts with any interested third parties — other schools and recruiters when needed. All requests, responses and sharing of data is recorded on a blockchain to provide an immutable trail of the entire history of a diploma and its access control. The schools and governments are collective caretakers of the blockchain network.

The solution is also GDPR compliant as no personally identifiable information is being stored on the blockchain which cannot be deleted.

Design Goals

For the Certified For Life decentralized system, we have the following design goals.

Owner Controlled Data — The diploma data should be in direct control of the graduate who has earned the diploma. This control should provide the graduates the ability to share and manage this data without going through any permissions or access control layer of the schools and governments. This ability will make the system faster and robust as the need for multiple authorization and authentication will be eliminated.

Tamper Proof — The diploma data managed and shared on the system should be fully tamper resistant. Only the schools should have the access to create or update the diploma data. This will ultimately add more trust to the system as the readers and verifiers of the diploma data (other schools and recruiters) will be able to trust this data.

GDPR Compliant — The system should be fully GDPR compliant. The system should provide a way to exercise the right to forget in case any of the users intend to do so. For this, the system should not store any personally identifiable information on such data stores where it cannot be deleted (blockchain, append only stores).

Ease of Access — The diploma data should be easily accessible by the graduates so that it can be shared when needed. Once the data is shared by the graduates, it should be easy for the audience (other schools and graduates) to read and verify the data.

Immutable Audit Trail — The system should provide the entire history of access and sharing of diploma data so that it can be easily verified. This history should be immutable.

Key Concepts

This section covers the key concepts and technologies, in brief, which are part of the proposed solution.

1. Blockchain — At it’s very core, a blockchain is an append only store of data which is cryptographically secured using public-key cryptography. In the beginning, any particular blockchain network has default/genesis state which is the starting point for all nodes participating in the network. To append data to the state of the blockchain, transactions are submitted to any of the participating nodes. These transactions are then verified by all other nodes in batches called blocks. Once all nodes agree on the validity of a block, it is committed to the state of the blockchain. This way the state of the blockchain gets updated with new data.

The proposed solution uses a blockchain network for storage of logs for access control of diploma data.

2. Self-sovereign Data — Self-sovereign data is a paradigm used to describe data which is fully in control of the user it is associated with. The primary use cases of self-sovereign data come from digital identity use cases where the identity information of a user is owned and controlled by the user himself instead of being stored and controlled by a centralized organization. This way the possibility of hacking identity data of thousands of people from a centralized system is significantly decreased as the identity data is with every individual and not with any server.

The proposed solution uses the generic concept of self-sovereign data for diploma data to be owned and controlled by the diploma holder.

3. Verifiable Claims — Verifiable claims contain basic information about entities and data representing their background. The information contained in these claims help proves the uniqueness and authenticity of the data associated with the entity. These claims are issued by the issuer of the data itself and can be verified by any interested third party. For example, in an identity data scenario, the issues can be the authorities issuing passports and other identity information. These issues will also be issuing digitally signed verifiable claims to the user so that they can prove the validity and authenticity of their identity data.

The proposed system uses the concepts of verifiable claims to prove the authenticity of diploma data.

4. Decentralized Identifiers (DIDs) — Decentralized Identifiers is a standard to represent identities on decentralized systems. The specification describes a standard for an object encapsulating identity related data and also the functions which can be performed on the object.

The proposed system uses DIDs to represent the identities of the schools so that they can be easily looked up on the underlying blockchain network.

Proposed Solution

In this section, the proposed decentralized solution is described. This section is organized into several sub-sections. We start with giving the high-level overview of the system and then we detail out the various components, architecture and process flows of the system.

Actors

Following are the primary actors in the system, participating in the information flow.

1. School — Schools or universities create the diploma for a student/graduate.
2. Government — Governments store and manage the diploma data at a regional and country level.
3. Graduate — The diploma holder.
4. Requestor — Any third party requesting diploma data from the graduate.

Components

The solution will have the following primary components from a high level. Some other additional components might also be needed for improving performance and security of the system, but they will be identified as part of a detailed low-level design at a later stage.

School/Government Data Store — This is the existing data store for the schools and governments where the diploma data is stored in a standardized format. The diploma data will continue to be stored in these databases. The idea is that the primary source of data should not be broken or replaced completely. This is to ensure backward compatibility of the new system.

In general, the schools will also be populating the government databases with the diploma data. Every school will sign and publish diploma data on these government databases. This way the government databases become an authentic “single source of truth” for a region or country and the students, data requestors and other schools can fully trust them.

Client Application — This is a client application which supports a digital wallet functionality. This application can be a mobile or desktop application or both. It will be connected to the school/government backend systems. The diploma data associated with a graduate can be downloaded and stored in the digital wallet using this application from the school databases.

Web Portal — The web portal is for the requesting parties to request and view the diploma data from the graduates. When a school or recruiter wants to see diploma data of a graduate, they will request it through this portal and the diploma holder will get a notification on their client application. If the data is shared by the graduate, the requester will be able to see the data using this portal. The basic purpose of the portal is to connect the graduates with the data requestors. The portal will not store any data shared through it.

Blockchain Network — This is the underlying blockchain network recording all transactions and logs related to issuing and sharing of diploma data. This network will be hosted by schools and governments collectively as part of a consortium. In phase 1 of the system, the blockchain will act as an immutable log and this is important to keep track of all the access rights and activity in the system. Further, in phase 2, with verifiable claims for diploma data, the blockchain network will have more integration.

Schools Registry — The school registry will be a collection of identity objects stored on the blockchain network in the DID standard format. The school DIDs will have the verification keys from the schools so that the diploma data can be easily verified.

Identity and Key Management System — To make the system fully GDPR compliant, we need to make sure that the identity data is not stored on a distributed immutable store. Identity systems already exist at schools because they record student information during the enrollment period. The proposed system utilizes these identity management systems from the schools to link the diploma data with the client-side wallet. The existing identity management systems will be extended to support key management as well.

Response Middleware — The response middleware is a publish-subscribe system for publishing responses from the users for the requests coming from the requestors. These responses can be pre-published in case of data being offered by the student or they can be reactive when the user shares data based on a request.

Authorization and Authentication Module — The client app, school backends, and blockchain nodes will be secured with industry standard authorization and authentication systems to secure the system from unauthorized access.

Functional Overview

The following sequence diagram shows how the different components and actors interact with each other and it also depicts the functional flow of the system.

Certified For Life: Functional Overview — Sequence Diagram

The following steps provide a functional overview of the system,

1. Schools publish their identities and verification (public) keys encapsulated in DIDs on the blockchain network. The school DID also has information about its affiliation with a government, backend endpoint addresses and other information which can help identify the school and its affiliation. The DIDs will be signed by the respective schools and the public keys will be published at the authentic data sources for verification. This can be as simple as publishing it along with the list of affiliated schools by the governments.
2. Graduate/citizen registers and creates his diploma wallet using a client-side application. The client-side application connects to the respective government database backend based on region and school selected by school by the user.
3. School creates and digitally signs the diploma and stores it in the government and school database.
4. Graduate downloads the digitally signed diploma in his diploma wallet on the client application.
5. Third-parties including other schools, recruiters, governments can request access to the diploma using a web portal.
6. The student can approve/decline the request from the client application.
7. If the student approves the request, the diploma data is shared with the respective audience.
8. All these steps are recorded on the blockchain network to verify the access control history of the diploma data.

Architecture

The following diagram depicts a high-level architecture of the system showing how the components described above connect with each other.

Certified For Life: Architecture Components

Solution Maturity Stages

The solution has two stages of maturity and both stages are described in separate subsections below.

Stage 1 — Full data sharing

The stage 1 of the solution is when full diploma data will be shared by the graduates when the data is requested by a requestor.

Process Flow

This subsection describes the process and information flow for stage 1 of the system.

Registration — The user downloads the client application on his device and registers in the system. The registration process includes the following steps,

1. Create a digital wallet on the user’s device.
2. Encrypt the wallet with user’s passphrase.
3. Create a unique ID for user’s wallet.
4. Register user wallet ID with the identity system of the school through the school backend.
5. Synchronize/download diploma data from the government database using information in the school DID.
6. This also adds an entry to the web-portal backend for the user to participate in the data sharing process, if the user chooses to opt-in.
7. The registration process also initiates the user-diploma timeline on the blockchain. The blockchain data will be fully anonymized.

Diploma Creation and Assignment — The diploma creation will be done by the schools. This can be done using the existing systems by extending them to support integration with digital signatures. Once the diploma is created it is assigned to the graduate by updating the database record with the diploma and user mapping from the identity system of the school. The diploma and user mapping will also be added to the user timeline on the blockchain. All the diploma information is also stored on the government databases so that the client application can synchronize with them.

Data Offer — As the primary actor in the system, the graduate can set permissions on data using the client-side application. The graduate can choose to offer his diploma data so that the requestors can directly access it when needed. This functionality will be supported using the middleware. If the graduate chooses to put his data on offer, then a response is pre-stored on the middleware which can be directly accessed by the requestors.

Request for data — The requestors can request the diploma data using the web-portal. The web-portal provides a functionality to search for users and the requestors can reach out to the user. If a requestor reaches out to a user for diploma information, the user gets an alert/notification on his client application. The interface for requesting will be through the blockchain network.

Response — The response for a data request can be based on the following two scenarios:

1. User has already shared his data as an offer — In this scenario, when the requestor requests the user’s data then it is directly returned by the middleware.
2. User has not already shared his data — In this scenario, the user receives a notification for request of data from a requestor. He can then decide to approve/reject the request. If he chooses to approve the request, then the diploma information will be shared with the requestor on the web portal from the user’s wallet through the middleware. The interface for response is not through the blockchain because we do not want to publish diploma information on it.

The sharing of data happens directly from the user’s wallet in the client-side application through the middleware. This way the student/graduate does not have to depend on permissions and access from the school for sharing his own data.

The middleware allows the request and response to be processed at different times. The user does not have to be online all the time. They can respond to data requests when they go online the next time as the requests will be available through the middleware.

Verification — In case the requestor wants to validate the information shared by the user, they can verify it using the digital signature of the issuer school as all the diploma data will be digitally signed. The verification process will use the DID of the issuing school to get the verification (public) keys.

The functionality of signature validation will also be part of the web portal.

Stage 2 — Controlled Data Sharing — Verifiable Claims

The stage 2 of the proposed system will allow the diploma data to be shared in a controlled way using the concept of verifiable claims.

In this case, along with issuing the diploma to the graduates, the schools will also issue verifiable claims to the graduates based on the diploma data. For example, the following can be claims issued to a graduate,

1. The diploma was completed in the expected duration.
2. The total marks scored by the graduate are greater than a predefined threshold.
3. The graduate actually holds the diploma.

All these verifiable claims will be digitally signed by the issuing schools so that they can be easily verified using DIDs of the schools.

Process flow

This subsection describes the process and information flow for stage 2 of the system.

Registration

1. All steps of stage 1.
2. A DID is also created for the student and it is populated by the information in the school’s identity management system. This step also connects the student ID with the student DID.
3. Diploma creation — Same as stage 1.
4. Claims assignment — After creation of the diploma, the school also creates and signs verifiable claims based on the diploma data and stores them in the school and government databases. These claims are assigned to the DID of the student.
5. Request for data — Same as stage 1.
6. Response — Based on the request for diploma data, the graduate can choose to share the entire information or just a claim. For example, in case of sharing the data with another school for higher education purposes, the graduate can choose to share the entire data, however, in case of sharing the data with a recruiter the graduate can only share a claim to prove the existence of diploma. This way the trust on the requestor can be reduced.
7. Claims verification — The verification of claims can be done in the same way by verifying the digital signature of the issuing school after looking up the verification key from the school’s DID.

Data Recovery

In case the user loses access to his client-side application and data — this can be because of loss of device or device being unusable — then he can re-sync the data in a new device by following a sub-set of the registration process on the new device.

The diploma data will be always stored in the school and government databases, so it will be available to the graduates to download anytime and on any number of devices.

Blockchain Network Governance

The blockchain network hosted as part of the Certified For Life decentralized system will be a private-permissioned blockchain network. The governance of the blockchain will be defined collectively by the schools and governments participating and maintaining the system.

Stakeholders

The stakeholders or node hosts of the private blockchain network will be the regional and national governments. The schools will publish their identity information (DID) on the blockchain network to identify themselves for the client applications and for diploma verification on the web-portal.

Along with the governments, the schools can also host nodes of the blockchain network in order to provide more decentralization and availability to the system.

Benefits of the Decentralized System

The proposed system has the following benefits as compared to the existing centralized system,

1. The diploma data is fully in control of the graduate who owns it.
2. The sharing and verification of diploma data is easier. The users don’t have to depend on permission and availability from the issuing schools.
3. The system is GDPR compliant.
4. The entire process flow can be easily verified using the immutable audit trails available on the blockchain.
5. The system motivates collaboration between the schools and governments of different countries hence improving education and employment opportunities for potential candidates.
6. The decentralized system helps get a country and region wide overview of the education system.

Possible Extensions

Following can be possible extensions of the system in the next phases.

Zero Knowledge Proofs — The trust on the requestor should be minimized so that the diploma data cannot be misused. One way of achieving that is implementing zero-knowledge proofs for verification of diploma data. In this solution, the graduate will be able to prove that he has the diploma without sharing any details about it. An interesting application of zero knowledge proofs in this scenario can be range proofs, where the commitments can be made by respective schools and the GPA of a candidate can be validated to be in a range.

Proxy Re-encryption — Proxy re-encryption allows a cipher text to be shared between two parties without revealing the keys by either of them. This is achieved by using a semi-trusted third-party for re-encryption of the data. In the Certified For Life system, the issuing school can be the semi-trusted third party between the graduate and the requestor hence enabling sharing of encrypted diploma data between the two parties.

Conclusion

In this report, we proposed a decentralized solution for sharing and management of diplomas. The solution is aimed at solving issues like GDPR compliance and data ownership. While enough details are provided to support feasibility of the solution, a more detailed and practical solution can be defined by doing further analysis of existing systems and processes and by doing a detailed design exercise for the new system.

Follow us on Twitter and LinkedIn to get the latest announcements. Visit our website to learn more about us and to Get Started using BigchainDB software today. Ask any technical questions you may have to our developers on Gitter. If you’re a developer using BigchainDB, we want to hear from you. Send us an email at contact@bigchaindb.com and tell us your story.