Decentralized Identifiers - Your Digital Identity

The technical approch

Building on SSI skills, today’s focus is on the technical aspect to realize Self-Sovereign Identity. The first in the line is the Decentralized Identifier (DID), the component of larger systems, such as the Verifiable Credential ecosystem. We’ll get a bit technical to get the knack of this.

W3C Decentralized Identifier 1.0 specification defines:

Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority.

Most expert in the industry prefers to call d-ee-d instead of Decentralized ID.

DID

DIDs have four properties - persistence, global resolvability, cryptographic verifiability and decentralization that provides independence from any centralized registry.

Any entity individual, organization or things are DID subjects in W3C parlance, and they can be issued Decentralized Identifiers that are URLs. They can be derived using a basic pattern of URN RFC 3986. This URL points to a DID document describing how to interact with the DID representing its subject.

A simple example of DID is given below with its DID document,

The scheme shows the context, the DID method points to the implementation of a specific distributed ledger network and DID string is the unique number issued for a given entity.

DID Document

The DID document is a JSON object conforming to RFC 8259.

{

"@context": "https://www.w3.org/ns/did/v1",

"id": "did:example:123456789abcdefghijk",

"authentication": [{

"id": "did:example:123456789abcdefghijk#keys-1",

"type": "RsaVerificationKey2018",

"controller": "did:example:123456789abcdefghijk",

"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"

}],

"service": [{

"id":"did:example:123456789abcdefghijk#vcs",

"type": "VerifiableCredentialService",

"serviceEndpoint": "https://example.com/vc/"

}]

}

Zooming on specific elements, the above DID document contains information associated with the DID, such as ways to cryptographically authenticate the entity in control of the DID, and services that can be used to interact with the entity.

Public Keys

Public keys can be included in a DID document using publicKey or authentication properties. They must have a single type (i.e., RSA, ed25519, secp256r1, secp256k1-koblitz) and a controller who has the corresponding private key. The controller value is made of DID that points to another DID document having its verification method if the mentioned DID is not the controller.

In the above example, authentication has type “RsaverificationKey2018,” and the controller value is “did:example:123456789abcdefghijk”.

More details about public keys can be found here.

Service Endpoints

The primary purpose of service endpoints in DID documents is to enable the interested parties to communicate with the DID subject or associated entities. There can be multiple service endpoints in the document.

The service endpoint in the above DID document points to “https://example.com/vc” that provides the service of verifiable credential check and type is “VerifiableCredentialService.”

JSON-LD

To make computers capable of analyzing all the data on the web, they need the context of the data. These contexts can be created using Linked Data that is used by search engines now for Semantic Web crawling.

The DID document is of type JSON, and they can be serialized using Linked Data to give them the power of context for the SSI ecosystem.

DID Creation

DID method implementors provide an interface to register a DID or a software library for integration to generate a DID programmatically. For example, the Veres ecosystem provides a CLI to create DID.

> mkdir did-cli

> cd did-cli

> npm install did-cli

> ./node_modules/did-cli/did generate --register

When you generate a DID, it registers a DID document on the Veres ledger, which can be retrieved using Universal Resolver mentioned later in this post.

DID Actions

The Credentials Community Group in W3C has identified thirteen actions and supported by DID.

The controller of the DID is allowed to perform create, update and delete operations, whereas the relying party can perform a read operation on DID, precisely DID document.

Some of the actions are self-explanatory; however, the interesting ones are,

Rotate: The controller may rotate the cryptographic material for a DID by updating the DID document.

Forward/Migrate: a DID redirects to another DID to support portability in case of users moving to a different network.

Recover: Some DID method may provide a means for recovering a DID if its existing cryptographic material is lost. Social recovery, multi-signature, Shamir sharing are some of the ways to initiate this operation and ending up with key rotation.

DID Method Registry

Known and recorded implementations of the DID method are found here. If none of these methods are suitable for a given use case, one can create and register a new.

Universal DID Resolver

W3C works on open standards that can be adopted by various organizations, which has brought us to a proliferation of DID methods, as we can see above. Such a DID ledger network has its cryptographic implementation and mechanism and any applications that want to consume them need to implement software drivers to resolve a DID.

The interoperability principle provides the mobility of DID within the self-sovereign identity ecosystem. The Decentralized Identity Foundation (DIF) has implemented Universal Resolver to resolve DIDs, the source code is found here. An application can achieve this global resolvability by such a library.

You can test your DID with Universal Resolver for the supported methods.

Summary

We are able to decode DIDs in this post with

• DIDs are URLs with a method and a unique number,

• DID points to a DID document which is of JSON-LD format,

• DID document contains information to interact with DID,

• DID document has public keys and the cryptographic algorithms used to generate them,

• DID document has service endpoints - created for verification, identification, functional interactions,

• We learned to create DID and resolve it using Universal Resolver.

---

All content free now. Subscribe by email so that you do not miss any article.

---

This post and the information contained herein is provided for informational and discussion purposes only.