The World Wide Web Consortium (W3C) has approved the Vivid decentralized identifier (DID) method specification by Moonlight. The specification released by Moonlight conforms to the requirements laid down by the W3C DID Working Group, and provides a framework for developers to create and manage identity documents on the Neo2, Neo3, and Zilliqa networks.

W3C is an international community dedicated to the development of open standards for the Web. More information about the DID Working Group can be found in its charter.

Unique identifiers

Many use cases exist for globally unique identifiers. Most people are used to seeing barcodes on products for example, called Universal Product Codes. Each barcode is unique, representing only a specific item no matter where you are in the world. Other examples of globally unique identifiers could include web URLs or the IBANs used for international banking in Europe. They may differ in form, but the essential use case is the same—they provide a way to distinguish between different entities or objects.

Something all these examples have in common is their dependence on a central authority. In some cases, a single identifier depends on a chain of these authorities. Take a web URL for example; a domain name (e.g. google) is licensed from a registrar, and the top-level domain (e.g. .com) is controlled by another organization, the IANA, itself falling under US jurisdiction.

This dependency on trust creates a number of downsides. If an organization disappears, so does the identifier or its resolvability. Even if the organization remains, there is always the possibility that the data could be tampered with or censored.

DID specification

Though these systems are adequate for a variety of scenarios, new use cases and growing concerns over data sovereignty has encouraged the pursuit and adoption of alternatives. DIDs emerged as one such solution, proposed by W3C as a new type of globally unique identifier that could satisfy the following requirements:

  • Decentralized – No dependence on a central issuing agency
  • Persistent – No dependence on the continued operation of an underlying organization
  • Verifiable – Able to cryptographically prove control over a given identifier
  • Resolvable – Able to discover metadata about a given identifier

Blockchain is a complementary technology for DIDs, solving the difficulties regarding issuance and persistence. The permissionless nature of blockchain gives equal, open-ended access to DID creation and usage, and once finalized on a public blockchain a DID will always persist.

This seems like a practical improvement already, but the real power of a DID lies in verifiability and resolvability. Verifiable means that the controller of a DID can prove their ownership of it using cryptography, completely replacing the need for a registry authority.

It’s already possible to create a “universally unique identifier”, or UUID, but these aren’t globally resolvable. This means that not everyone can look it up and view metadata about what it actually identifies. If you want to create a resolvable unique identifier, you usually end up needing a centralized administrator such as a registry.

DID format

To understand DID resolvability, we should look at an example of a DID. They adopt a similar format to the URN specification, consisting of three parts: the URI scheme, the method, and a method-specific identifier.

did:vivid:znWRVY1GSUSjJEFqD8hRBc6s68qkQ9MGsaSRNZc8ZaMX

This is an example DID taken from Moonlight’s Vivid DID spec. The first part, the scheme “did”, informs us that we are actually looking at a decentralized identifier.

The next part, the method “vivid”, tells us which method specification document defines how this type of DID was created and how it is managed across different applicable blockchains or other verifiable data registries. Each method specification has to follow the requirements laid out by the W3C DID Working Group before being approved and accepted. This process has now been completed for Moonlight’s Vivid method spec.

Finally, the method-specific identifier in this case is the Base58 representation of a compressed 33-byte public key. This part is unique and is what will resolve to a specific DID document. In this case, it will resolve to a document following the Vivid spec. You can see the example document here.

These documents reveal how the identifier was generated (e.g. with secp256r1). They also include a copy of the DID itself to be fully self-describing. The end result is that it can be used for all authentication and user interaction, defining the service endpoints needed to handle any such interaction. For example, the Vivid DID spec explains how to integrate with Vivid to interact with DIDs stored in contracts across Neo2, Neo3, and Zilliqa.

DPKI

Coupled with the accessibility and longevity offered by blockchain networks, DIDs as proposed could fundamentally alter the way we interact with others and do business online. Trusted third parties can be replaced with cryptographically validated digital identities, and users can be granted full sovereignty over when, where, and with whom to share their private information.

The main responsibility for a DID is to act as the binding agent, tying an identity together with any number of verifiable claims. Historically, applications like Moonlight would simply use a Neo public key as the identifier, but adopting the DID standard provides much improved interoperability with other projects and networks that also follow the standard.

This can be viewed as the true endgame of widespread DID adoption, the creation of a decentralized public key infrastructure. Moonlight’s work to create a DID method spec for Neo and Zilliqa prepares both networks to play host to this new Internet identity layer.

DID applications

The framework itself is a blank canvas; each digital identity application can have its own niche use for DIDs. In Moonlight’s case, supported verifiable attributes such as email addresses or GitHub accounts could be attached to DIDs representing each Moonlight user.

In another application, skill credentials or academic qualifications could be issued using a DID, allowing their authenticity to be independently verified and ownership to be proven. W3C itself outlines a number of example applications such as these.

Closer to home in the Neo ecosystem, this new framework could also be used to build valuable ecosystem-level resources, such as an open reputation system. Each application on the network could issue its own verifiable claims about an identity, building up a proven track record of trust and filtering out bad actors in the process. This is a particularly valuable tool in a permissionless blockchain network, where malicious users could otherwise simply create a new key-pair in order to start out with a clean slate.

These new tools for identity could also prove to be useful at the protocol level. For example, verified information about a candidate consensus node could be issued, proving that it is able to meet the performance expectations of the network. This type of verifiable information about candidates could emerge as a powerful tool for informing voters and encouraging decentralization.

Tags: