Universal Resolver for DID’s – What it is and Why it matters
Universal Resolver – What is it and Why it Matters?
Tuesday 3G
Convener: Nader Helmy
Notes-taker(s): Nader Helmy
Tags for the session - technology discussed/ideas considered:
DIDs, Universal Resolver, DIF, decentralized identity, software tools, open source
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
The DID spec provides a general framework for user control of a cryptographic identifier https://w3c-ccg.github.io/did-spec
Since DID is a generic framework, the way that any given DID works is defined by the DID method. DID methods are an implementation of the DID spec which identifies a particular schema for CRUD operations on the DID
C - create
R - resolve
U - update
D - deactivate
DIDs are written with the syntax Template:Font colorTemplate:Font colorTemplate:Font color
Since there are so many DID methods, there is motivation for a common library/service that allows usage of a DID regardless of method. Every DID method is implemented in a unique way, meaning it has its own libraries, dependencies, and software stacks. In addition, each method specifies a different way of speaking to its respective blockchain, ledger, or distributed filesystem.
The Universal Resolver solves a part of this issue by giving a common interface that allows any DID to be resolved. It is a completely open-source project hosted by the Decentralized Identity Foundaton (https://identity.foundation/) and is a collaboration from many developers and companies across the world
In broad terms, Universal Resolver is a service which provides a common interface for all DID Resolution, regardless of method.
It is implemented as a set of Docker containers running side by side on a local machine. The basic architecture is 1) a user makes an HTTP call to the UR with a specific DID, 2) the UR parses the DID and determines which method it belongs to, then 3) the UR calls the appropriate method-specific driver. Every driver is an implementation of the Resolver for one or more DID methods.
The Universal Resolver SHOULD BE DEPLOYED BY THE DEVELOPERS USING IT
It is imperative to run a “local” version of the resolver in order to trust its results. Since the Resolver performs the verification of a DID Document and ensures the information is accurate, anyone who wishes to use the Universal Resolver should do so independently. This service runs locally and can serve your applications and demos with current and valid info about DIDs
Two separate codebases:
- Universal Resolver - https://github.com/decentralized-identity/universal-resolver
- You can think of this as the backend service. It includes the Docker containers and the HTTP interface. You can resolve DIDs from the command line using CURL
Universal Resolver Frontend - https://github.com/decentralized-identity/universal-resolver-frontend
This provides the web interface with clickable buttons!
Public instance (used for demo purposes only): https://uniresolver.io/
3 Questions that everyone using UR should answer:
- How is it deployed (UR and drivers)?
- E.g. local or public instance, running as a hosted service, etc.
- How do drivers talk to their target system (blockchain, ipfs, peer, etc.)?
- Running a full node, using a software library/API, etc
- If the driver uses an API, how is the API implemented?
- Is the API speaking a particular node, a pool of nodes, a cache, etc?
Notes:
- Drivers are contributed in the form of a Pull Request to the DIF Github repo found here https://github.com/decentralized-identity/universal-resolver
- Comprehensive list of all DID methods - DID method registry https://w3c-ccg.github.io/did-method-registry/#the-registry
- It is a common misconception that the UR is a centralized service. While uniresolver.io is a public instance of the codebase, it is only used for demo purposes. The Resolver is meant to be run locally by the person verifying the results.