The Power of DIDs #1: DID Resolution

How It Establishes Trust and Enables Digital Identity

As we interact with the digital world, it becomes increasingly important to ensure trust, security, and privacy. Decentralized Identifiers (DIDs) are a new way to establish a digital identity without relying on centralized authorities such as governments or corporations. In this blog series, we will discuss everything you need to know about DIDs, starting with the most critical feature that DIDs offer: DID Resolution.

What is DID Resolution?

A DID is a digital address consisting of a string of characters that can refer to subjects in the physical world. The four core properties of DIDs, as defined in the W3C DID Core specification are: permanent, persistent identifiers; it never needs to change, cryptographically verifiable; control over a DID can be proven using cryptography, decentralized; there is no central registration authority required, and last, resolvable.

DID resolution is the process of obtaining a DID document or technical metadata for a given DID. This might sound dry or boring at first, but it is actually a crucial step. DID resolution establishes the link between physical identity and digital identity. This makes it possible to establish higher-level concepts such as reputation and trust. DID resolution enables us to share messages and data, establish connections and relationships and interact in and with the digital world.

DIDs and other applications

DID Resolution is a fundamental piece of functionality that enables a lot of higher-level protocols applications, and services. The information returned by DID Resolution can be used for various purposes, including:

• Verifiable Credentials (VCs); looking up a public key to verify a digital signature from the Issuer of a Verifiable Credential. This is required in an exchange of a VC between Holders, Issuers and Verifiers.
• Establishing DIDComm connections or engaging in OpenID Connect transactions; obtaining the cryptographic data needed to establish authenticity, security and encryption of the transactions.
• Decentralized Web Nodes or connecting to agents; discovering the (service) endpoints for interacting via secure protocols thereby making these connection possible.

Architecture

DID Resolution has three components in the technical architecture: the client, the DID resolver, and the Verifiable Data Registries (VDRs). A client invokes the resolver. The resolver’s task is to look up the associated DID document from the Verifiable Data Registry, according to the DID method. Looking up a DID is method-specific, implying that the design of the individual DID methods determine how the process of looking up a DID works; defining the syntax of the DID and how to get from the DID to the DID document. DID documents are stored in plain text (on Verifiable Data Registries such as blockchains, or simply downloaded from a server or API), or are constructed from more dynamic virtual data structures, which require more complex DID resolution processes. The crucial part to understand here is that DID Resolution is not confined to one single protocol, unlike DNS or HTTP. It includes an abstraction layer that makes it possible to resolve any given DID to a document in many different ways, not only using blockchains, distributed ledgers, or databases, but also involving web servers or simple local processes.

Interaction between the client and the DID resolver

A similar abstract interface exists for the interaction between the client and the DID resolver. Unlike DNS, when the client invokes the resolver, there is no concrete way or specific client-server protocol. The client can invoke the resolver and transmit the DID, plus additional resolution options, in the request to the resolver. This could be a local process (by calling a local native library including in the same piece of software) or a remote service (by connecting to a remote DID resolver over protocols such as HTTPs or DIDComm).

Additional functionalities of the DID resolver

Various resolution options can be used to pass additional instructions to a DID resolver and control its behavior. For example, this makes it possible to transform the DID document between different representations (e.g. JSON-LD or CBOR), support different key formats (e.g. Base58 or JWK or Multibase), instruct the resolver to enable or disable caching, or perform some extra validation steps before returning to the client. And in addition to the DID document itself, the resolver can also return metadata about both the DID document and the resolution process, which can be useful in various ways.

This gives DID Resolution a lot of room for additional functionalities and innovation!

Try it out

To try out DID Resolution yourself, see the following resources:

• Godiddy.com documentation about DID Resolution: https://docs.godiddy.com/en/apis/universal-resolver
• DIF Universal Resolver: https://dev.uniresolver.io/

Summary

DID Resolution is a critical feature of DIDs that enables a lot of higher-level protocols, applications, and services. The architecture of DID Resolution includes the client, the DID resolver, and the Verifiable Data Registries. DID Resolution involves an abstraction layer, making it possible to resolve the DID document in many different ways.

As we move towards an increasingly digital world, the issue of digital identity has become more pressing. How can we establish and maintain trustworthy digital identities that provide us with privacy, security, and control? Decentralized Identifiers, or DIDs, hold the answer.