Shaping a New Paradigm for Digital Trust with Decentralised Identity Management and Digital Credentials: Your Step-by-Step Guide

As we navigate through an increasingly digital world, the need for robust digital trust frameworks becomes paramount. 'Shaping the New Paradigm for Digital Trust with Decentralised Identity Management and Digital Credentials' offers a detailed, step-by-step guide on transitioning to a system where users have complete control over their digital identities. We delve into the intricacies of decentralised identity management, an innovative approach that provides users with unparalleled security and autonomy by decentralising the storage and management of identity credentials. Through this transformative method, users acquire the knowledge necessary to enhance their online interactions, ensuring that they are secure, private, and entirely under their control, thereby reducing the risk of data breaches and unauthorised access.

Previously, we explored the foundational aspects of authentication to establish trust between a client and a server. The client authenticates the server's identity cryptographically through a public-key infrastructure. The server authenticates the client through login accounts, passwords, OTPs, magic links and such. 

Decentralised Identity Model becomes a reality when a digital user can own - hold - present their digital identity credentials. Here:

• Data ownership is fundamentally changed for good.
• User authentication is a function of identity, not passwords.

In this blog, we will navigate the complexities and opportunities of decentralised identity management and digital credentials, paving the way for a safer and more resilient online future. Throughout this exploration, we will examine the pivotal role of digital credentials in this transformative process, highlighting their significance in fostering trust, security, and user empowerment in the digital realm.

Let’s begin by diving deeper to implement “own – hold – present” digital identity credentials for end users, to make our assumption a tangible reality.

Drawing our learnings from server authentication during TLS handshake, the primary requirements to establish trust between a verifier (relying party) and a holder (subject), using credentials are:

• Credential Format: We would need a standard format to represent the structure and enclose data attributes of the credential.
• e.g. X.509 is a common format to represent SSL certificates installed on HTTPS-enabled servers.
• Credential - Identity Binding: This would be required to bind the holder’s identity to the credential. It would deterministically prove that the holder is the rightful owner of the presented credential. 
• e.g. X.509 certificates bind the public key to the identity of the server through digital signatures of a trusted certificate authority or self.
• Credential Exchange: A set of rules and standards for verifier to “ask” for the credentials and the holder to “present” the credentials. This will establish a common language between verifier and holder. 
• e.g. The TLS handshake sets the rules and protocol of credential exchange between client and server.
• Credential Verification: The verifier must then be enabled with the right tools, services and technology to cryptographically verify the identity claims and authenticity of the certificate; in order to close the loop of establishing trust.
• e.g. Most browsers and operating systems come bundled with cryptographic implementation required and public keys from trusted CAs.

Once we have implemented each of these for a digital user, we can make the switch from traditional password-based systems to digital identity credentials for user authentication.

Owing to the unwavering efforts of the open-source ecosystem powered by entities like W3C, DIF, OpenId Foundation and more, we have access to technologies, standards and protocols which are paving the way for democratizing Decentralised Identity for the end user. 

We will talk about a few of these standards next.  

1. Decentralised Identifiers

The foremost requirement of an identity management system is to enable the creation of user identifiers for unique representation. In the digital world, trust is generally linked to these identifiers.

An identifier has an identity record associated with it, which consists of certain attributes about you. 

For instance, your Google profile is one such identity record and your email address is the identifier for that record. In order to use this profile (i.e. identity record), you need to prove that the identifier (i.e. email id), is rightfully yours, through a chosen authentication factor. *Traditionally you prove this using the ‘password’ you choose when you create your profile.

In the digital space, we already own plenty of identifiers, which come in all shapes and forms.

• Centralised Identifiers: Identifiers controlled by the organisation that created them

• You have email identifiers (email id) from various providers. 
• You may also have a handle like @someone for online platforms, which identifies you uniquely on that specific platform. 

• Federated Identifiers: Identifiers controlled by an organisation, which are used on another platform

• You may have used Login with Google/Facebook or any other social login to sign-in to say your Spotify account, implying that you made use of an identifier issued by a 3^rd party to identify yourself to Spotify. 

With this understanding in place, why do we even need another type of identifier which is decentralised? 

Imagine you have an Instagram handle which serves as the identifier for your profile, and you used “Login with Instagram” powered by OpenID Connect[1] to sign-up to Coursera and bought a few courses. Next, a change in Instagram policy triggered your account revocation, along with the centralised identifier and associated Instagram profile. 

But what is happening to your Coursera subscription now? 

Since you used this identifier on another platform without ever having complete ownership of the identifier, the blast radius of the issue is much bigger now.

Hence, Decentralised Identifiers (DID). These are cryptographic identifiers designed to function without a centralised authority.  Any individual, organisation or an entity can be assigned these identifiers, which are

• Persistent: Unlike an email id or a phone number, which can be re-assigned, a DID always identifies the same entity, making them private and secure.
• Verifiable: DIDs are powered by cryptographic keys, hence the controlling entity can always prove the ownership of these identifiers without relying on passwords.

To better understand the DID infrastructure, we explain the composition of an ideal identifier, according to the W3C URI spec [2].

A Uniform Resource Identifier (URI) is a simple way to identify internet resources e.g. a webpage, a document, an image or any resource. One type of URI is Uniform Resource Locator (URL), which is used to locate and access webpages. DID is a new type of cryptographic identifier that conforms to URI spec.

Taking a step back, the reason to look for a new identifier type was to ensure that the owner of the identifier can prove their ownership without relying on any centralised authority. 

When you create a DID, you decide on the ‘system’ that you trust to manage these identifiers. This system helps the world to make sense of your identifier. 

To simplify, this is how a DID looks like:

did:example:123456789abcdefghijklmnop

Here, “example” is the system/method that you chose to create, update and resolve the DID. Creating and updating are self-explanatory, but what does resolving an identifier mean? 

DID resolution is a way to discover what an identifier means. On resolution, a DID leads you to a DID document that contains the necessary information about the identifier.  When you create a DID, you obtain a mathematical key pair, of which you keep the private key securely with you and public key can be derived from the DID document by anyone.

To better understand this, I picked “key” method to create below DID for myself. 

did:key:zQ3shttpHcGzpUTAaPKCXx5iLWBw2dy6FkH9LKmCZ8FxqAh5i

Through the rules of resolution set by “key” method, anyone can resolve this identifier to a DID document which looks as follows: 

When a verifier uses this DID document to extract my public key, I can use my private keys to authoritatively prove my ownership on the DID. 

Hence, DID binds my identity to the identifier using a DID document and basis for trusting the identifiers lies in cryptography and not in an external centralised system. 

This gives us an answer to one of the requirements we listed above to implement digital credentials: Credential – Identity Binding.

     B. Verifiable Credential (VC)

Now that we have an identifier, we can look ahead to find a format that can represent an identity credential for an end user.   

• Credential is just a structured document, containing one or more claims about a subject. Claims such as: I belong to a certain nationality, or I am above 18 years of age. 

One of the most used identity credentials in physical world is a driver’s license, which can be used to understand the inherent requirements from a credential.

We can derive the following information from this sample driver’s license

• Credential identifier
• Issuer: State of Michigan 
• Subject/Holder: Janice
• Claims about Janice: DOB, Sex, Height, Eye colour, etc.
• Picture as a biometric proof that Janice is the rightful holder
• Digitally signed by Janice
• Machine readable and verifiable for issuer’s authenticity
• Issue and expiration date
• Janice can present this licence to any interested verifier

Back to the Digital World

In order to make own-hold-present identity credential a reality, we need a similar capability to represent a credential digitally - i.e. A standard data format which defines how a credential is represented and understood. 

This is addressed by the W3C Verifiable Credentials (VC) specification [3], which defines standards for expressing digital credentials. This format is called Verifiable Credential, and it looks like this.

These claims can be financial, educational, health-related or any other personal information, which is then machine-readable and verifiable when presented on the web. 

Let’s break down this credential to understand its components:

Metadata: 

• Type: Defines the type of credential, for instance an email credential to assert email address ownership of subject.
• Holder: DID of the entity who is in possession of the credential. 
• Issuer: Identifier of the entity who issued the credential, thereby ascertaining certain claims about the subject.

Credential Subject: Claims about the subject. For instance, the holder of this credential owns the email identifier.

Proof: Digital signature of issuer which attests to the authenticity of these credentials.

How does this Proof work?

1. The issuer uses a cryptographic signature algorithm (e.g. EdDSA), to create a digital fingerprint of the document during issuance.
2. Any change in the document alters this fingerprint, and the verifier would be able to detect tampering of the credential.
3. This fingerprint is then encrypted with the private key of the issuer, asserting that it was only the issuer who issued the credential. 
4. A verifier can “resolve” the issuer’s DID to retrieve the public key and cross-verify the issuer’s identity in a decentralised way.

This specification brings us very close to the notion of a physical credential. But imagine a situation where a holder holds multiple VCs, and a verifier is looking to verify multiple attributes scattered across these credentials. For instance, in the real world along with your age, DOB and nationality, a verifier also requires validating your educational qualifications.

     C. Verifiable Presentation (VP)

In such cases, we can make use of Verifiable Presentation, which is a collection of verifiable credentials and is created and digitally signed by the holder.

In the example below, when a verifiable presentation is shared by the holder, the verifier validates the issuer’s identity of each credential, along with the holder’s identity embedded through holder’s proof.

Learnings So Far

Decentralised Identifiers enable any entity to bind their public keys with their identity, offering a layer of security where ownership of a private key serves as sufficient proof without relying on any centralised authority.

Verifiable Credentials revolutionise the way we digitally represent identity credentials, providing verifiers the ability to independently ascertain their authenticity.

Reflecting on the requirements of implementing “own-hold-present” identity credential for a user, we now identified these key components:

• Credential Format: Verifiable Credential
• Credential - Identity Binding: Decentralised Identifier
• Credential Exchange and Verification: ?

Easier Said Than Done

While we have made progress in conceptualising a robust identity framework, a few challenges remain:

• How would a user create and manage these decentralised identifiers?
• How would a user “own, hold and manage” the verifiable credentials issued to them?
• And then digitally sign these credentials into a verifiable presentation during a transaction, as proof of ownership?
• What about the technology stack for secure key management, which forms the entire foundation of this trust ecosystem?

The complexity of securely managing and leveraging these digital assets underscores the need for an innovative solution. Affinidi Vault is that missing piece of the puzzle for the digital user. It is a one-stop identity solution that allows end users to do more than own-hold-present. It enables users to discover, collect, store, share and monetise their data and identity by leveraging the decentralised technologies. 

Apart from being a holistic identity store, Affinidi Vault is powered by a suite of products and services called Affinidi Trust Network, which enables it as a consent manager, a service provider and a credential manager for the digital user.

In the next chapter, we answer our final requirement of ‘Credential Exchange and Verification’ through a set of open standards and protocols which can close the loop of trust by enabling a verifier to “ask” and a holder to “present” these identity credentials.  

[1] https://openid.net/specs/openid-connect-core-1_0.html

[2] https://datatracker.ietf.org/doc/html/rfc3986

[3] W3C Verifiable Credentials (VC) specification