Learn-by-doing: DID protocol and Verifiable Credential

A technical view of the “zCloak Membership” event

0. Key takeaways

• DID(Decentralized Identifier) is a unique identifier for an entity.
• Each DID is matched with a DID document in a data store(e.g. in a blockchain). The DID document contains several DID-Keys, each key (AuthenticationKey, AgreementKey, AssertionKey,… ) has different functions.
• Verifiable Credential(VC) contains the user’s detailed information. The identity of one entity is its DID and VCs combined.
• Three major parties in the DID/VC context are: claimer, attester and verifier.
• The DID-Keys and VC files should be stored and backed up properly. Losing the DID/Credentials file will result in loss of one’s identity data permanently.

1. What are DID and VC

DID(Decentralized Identifier):

A DID may represent an entity — for example a person, an organization, or even a machine. A Decentralized Identifier (DID) is a string uniquely identifying each user. The DID can contain multiple different keys for purposes such as encryption, signature, authentication, etc.

A DID can be resolved to a DID document stored in a Decentralized Data Registry (e.g. a blockchain). This document contains several keys: a signing key(Authentication Key), an encryption key(Agreement Key), and optionally a link to a DID service endpoint.

DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document contains information regarding cryptographic material, verification methods, or service endpoints, which the document provides a set of mechanisms enabling a DID subject to prove ownership of control of the DID.

The DID ecosystem is based on public key infrastructures where only the owner of the private key has full authorization of the DID. This is similar to blockchain-based systems, in which the users control their assets. This leads to the following issues regarding the system when in use:

• Recovering a lost private key is extremely difficult;
• Once your private keys are stolen, malicious acts like impersonation may cause “you” to misbehave.

Overall, all users are fully responsible for creating and managing a secure backup of their private keys/mnemonics.

VC(Verifiable Credential):

In the physical world, a credential consists of:

• Owner: Information related to identifying the owner of the credential
• Attester: Information related to the issuing authority (for example, a city government, national agency, or certification company)
• Credential Type: Information related to the data structure of a claim
• Credential Content: The data in a credential, which contains the personal information of the owner.

A verifiable credential(VC) can represent the same information as a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials tamper-proof and more trustworthy than their physical counterparts.

Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics.

Three key roles of Verifiable Credential specification are listed below:

• Claimer: A claimer is an entity that states to have certain properties (i.e. a Claim) and can request an attestation. In common scenarios, the role of Claimer is played by end-users.
• Attester: An attester responds to a request for attestation in an affirmative way, which is called attesting the claim(i.e. Issuing a Verifiable Credential). Usually, the role of Attester is played by a Trusted Organization.
• Verifier: A verifier is an entity that requests the claimer to present a credential with certain attributes. The role of Verifier is usually played by a 3rd party who provides service based on the identity of the claimer.

2. Blockchain-based DID and VC

Authentication and verification have become one of the major challenges worldwide. With the advent of blockchain technology and distributed ledger, a novel, fully decentralized and permission-less approach has been established, which is promising for self-governance and self-sovereignty.

Now, let’s dive deeply into learning more details about DID based on a blockchain.

2.1 Dive into DID

DID is the identifier of an entity. An entity can only have one DID, and each DID matches a DID document stored on the blockchain. In a blockchain, the owner of an asset is a blockchain address; in the identity world, the owner of a Verifiable Credential is a DID.

A DID is a simple text string consisting of three parts: 1) the did URI scheme identifier, 2) the identifier for the DID method, and 3) the DID method-specific identifier.

Figure 1: A simple example of a decentralized identifier (DID)

Each DID can be resolved to a DID document. A DID document contains information associated with the DID, such as ways to cryptographically authenticate a DID controller.

For now, the DID protocol (KILT protocol) used in the zCloak Credential Platform contains two kinds of DID-Keys — Authentication Key and Agreement Key:

Figure 2: Keys(AuthenticationKey & AgreementKey) contained in each DID Profile

Authentication Key:

DID Authentication is the mechanism by which an entity can cryptographically prove that they are associated with a DID. Authentication Key is used for all DID management operations, adding digital signature during the creation of a claim, etc..

Agreement Key:

The AgreementKey is an encryption key, used when an entity wants to generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing an end-to-end encrypted communication channel with the recipient.

2.2 More about VC

Verifiable credentials MUST have a type property.

A credential type (CTYPE for short) defines the structure of a claim. You can think of it as the data model for your claim.

For example, the ‘zCloak Membership’ in the Credential Platform is a unique Credential Type that contains two data fields that need to be filled in -- discord_user_id and zkid_verification_code.

Figure 3: zCloak Membership(Credential Type) Credential details

The Attester — ‘did:kilt:4obf6LAUCg9NsFmxarhQ2zVMipYJFC1SmvbK1LEWYffEMR6z’ shown here is the entity that receives the claim and does the attestation work for the claimer. Once the attester approves the claim, the user will get an attested credential immediately.

3. Start your Credential Platform Journey

3.1 Become a Member and obtain a Verification Code

First of all, you should become a member of zCloak Discord and get a verification code in the zkid-verify channel. Click here to join zCloak Discord.

Type /zkid-verify into the command line, click the COMMAND that pops up, and get your own verification code via zkID_bot.

Figure 4: Join zCloak zkid-verify channel, and send a command

Figure 5: Become a member and obtain a verification code

Now, we have obtained a verification code VOSzbHJvpd, we can start our Credential Platform Journey.

3.2 Create a Claimer Account

In the Credential Platform, there are three roles — Claimer, Attester, and Verifier. Before creating accounts, let's find out what role they play respectively.

• Claimer: the entity that wants to create a claim and get an attested credential via the Credential Platform. In this journey, the claimer is the user who wants to get a zCloak Membership Credential.
• Attester: the entity which verifies the information in the claim and does the attestation job(approve or reject). Once the attestation is passed, the claimer will receive an attested credential.
• Verifier: the entity that is being shared with certain credential. In terms of usage scenarios, when a Claimer obtains a credential from an Attester, the Claimer can share the credential with any verifier they trust.

Now, let’s become a claimer on zCloak Credential Platform. Click Here to create a claimer account.

A user who enters the platform for the first time needs to generate an account by mnemonic phrases and a specific password. It is necessary to keep in mind that the mnemonic phrases and the password must be kept properly.

Figure 6: Get into zCloak Platform(claimer-end)

Figure 7: Create a Claimer Account via password and mnemonic phrases

Figure 8: Account created successfully, DID file download automatically

Once the account is created successfully, a DID file will be downloaded automatically. You should store the file, mnemonic phrases and password properly, for the reason that if they are leaked, the account may be at risk.

3.3 Create a zCloak Membership Claim

Creating a claim is one of the most essential steps of our journey. Click the ‘Create Claim’ button, and fill in your personal information(discord_id and verification_code).

After you have filled in your info, click the ‘submit’ button. The attester will receive your request and do an attestation work on it. If your information(discord_id and verification_code) is correct, you will receive a 'valid credential' in a few minutes.

Figure 9: Click the button to create a ‘zCloak Membership’ Claim

Figure 10: Fill in your personal information and submit the claim

Figure 11: Get your attested ‘zCloak Membership Credential’

3.4 Share your attested Credential with trusted Verifiers

Now, after obtaining your attested credential, you can share it with any verifier you trust. Then, the verifier can check the information you shared in their own account.

Figure 12: Claimer shares information with the desired verifier

Figure 13: Verifier receives the information shared by the claimer

4. How to store your DID and VC

4.1 Store DID

Your account can only be restored via DID-Key file or original mnemonic phrases. So both of them should be kept safely. zCloak Credential Platform will automatically download your DID file at the Account Creation Phase.

When you want to check your DID Information, you can go to the DID Profile Page. And download your DID file via Export DID-Key at any time.

Figure 14: Check and Export your DID keys

Once you log out, you should restore your account with DID-Key file or Mnemonic phrase in the ‘Restore account’ Page.

Figure 15: Restore account

Figure 16: Restore account via DID-Key file or Mnemonic Phrase

4.2 Store your VC

Once your credential is attested, you can download it at any time. The Verifiable Credential is a JSON file, which contains your personal details in plaintext. So, we MUST store it safely to avoid information leakage.

Figure 17: Download and store you Verifiable Credential(VC)

4.3 Import your VC into zCloak ID Wallet

Download zCloak ID Wallet. Initialize it with a password that is safe and that you can remember. This password is used to encrypt your data and give permission to all operations(i.g. Generate zero-knowledge proof ) in zCloak ID Wallet.

Then we can import our obtained Verifiable Credential and check the credential details.

Figure 18: Import Verifiable Credential into zCloak ID Wallet

Figure 19: Check details of the Verifiable Credential with zCloak ID Wallet

5. How to use VC

5.1 Share/Present in plain text

The ‘share’ function in the zCloak Credential Platform between Claimer and Verifier is in the form of plain text. The Verifier has access to all pieces of the credential information if the Claimer chooses to share them all.

5.2 Selective Disclosure

Unlike the first case, Claimer can select one or more pieces of information to share with the trusted verifier. This feature of digitized credentials makes the platform more targeted to privacy protection by providing individuals with granular control over the information shared with various institutions and entities.

5.3 Anonymous Presentation(Zero-Knowledge Proof)

ZKP is a type of cryptographic math that enables someone to prove things are true without actually revealing the information. zCloak uses ZK-STARKs virtual machine to generate and verify zero-knowledge proofs for general-purpose computation, based on the concept of Self-Sovereign Data and Self-Proving Computation. It helps users to perform computation and analysis on their data without sending the data to 3rd parties.

Using zCloak ID Wallet, users can prove their identity information satisfies some restrictions via zero-knowledge. In this manner, the verifier won’t have access to the claimer’s personal information but can also check whether the content in the credential meets his/her requirement.