Author: Matt McKinney - ArcBlock VP of Marketing

This article is a soft introduction into Verifiable Credentials and the potential use cases for organizations, businesses and government institutions and creating new levels of trust for individuals and the services/institutions they use.

Verifiable Credentials

At the simplest level, Verifiable Credentials are nothing more than the electronic equivalent of physical credentials that we already use today - credit cards, passports, driver licenses and things like qualifications and awards. In these examples, the traditional way many of us are used to is for a user to share information to the bank (entity) including highly sensitive personal data and then the bank/entity will store that information on their centralized servers and use that information to make a decision as to whether they will issue the user some type of credential.

Unlike a traditional physical credential, we are seeing a greater push towards the use of Verifiable Credentials. Verifiable Credentials can be used to establish trust between parties by using a set of tamper-evident claims and metadata that cryptographically proves the identity of the holder and who issued it. More importantly, by using this approach users can keep their data and simply share a verified credential to another party whenever they receive a request.

In order for Verifiable Credentials to work, they need to support 4 different roles - issuer, verifier, subject and holder.

• Issuer: the person that creates the claim and associates it with the subject.
• Verifier: the entity or person verifying the claim about a given subject.
• Subject: the entity or thing about whom a claim is issued.
• Holder: a holder is usually, but not always, the subject of the verifiable credentials that they are holding.

Whenever someone wants to know something about us, we use the verifiable claim as a way to share a qualification, achievement, quality, or piece of information about an entity or persons such as a name, government ID, payment provider, home address, or university degree. More to the point, Verifiable Claims describe a quality or qualities, property or properties of an entity or person that establishes its existence and uniqueness.

Verifiable Credential Use Cases

Verifiable Credentials are designed to address user needs across a wide range of industries and domains and could be used for things like employee ID cards, digital birth certificates, and digital educational certificates. The following image shows a more complete view of verifiable credentials and how they relate to specific user needs. In the next few articles, we will look further at some of the specific use cases and demonstrate the role of user types and how those interactions lead to the successful creation of a verifiable credential.

Source: W3C's Verifiable Credentials Use Cases

User Tasks

A critical element of Verifiable Credentials are user tasks and are often a driver for the requirements of the credential. The below diagram demonstrates User Tasks and is needed in order for the Verifiable Credential to be useful.

Source: W3C's Verifiable Credentials Use Cases

While this list is by no means complete, it does show the potential to rethink user experiences and creates a roadmap for future types of verifiable credentials.

Verifiable Credential Design

Now, that we have an understanding of Verifiable Credentials, use cases and user tasks let's apply that to a working design. One of the most common early designs of verifiable credentials related to universities. In this example, it is very easy to identify the holder (the student), the issuer (president of the university) and the verifier (the university). Let's look at a diagram of how a verifiable credential will work. The first graph in the W3C created image shows the credential itself that includes credential metadata (in pink) and claims (in yellow). The second graph shows the digital proof (in green), which is usually a digital signature.

Source: W3C's Verifiable Credentials Data Model 1.0

ArcBlock's identity services are built using the industry-leading W3C DID standard and follows the W3C reference designs wherever possible.