Have you heard of Decentralized Identifiers (DIDs)? They’re a work-in-progress W3C recommendation that I’ve seen pop up in a couple places - mostly recently in the just-updated Thoughtworks Technology Radar. Since I’ve been interested in technologies related to identity and access management, I thought I should take a look.
Why do you need identifiers?
When you want to refer to a subject, for example a person, in a data processing system, you need an identifier for them. If you’re operating in a single system, you can get away with a surrogate key: an arbitrary identifier assigned by the system. For example, in a typical web application each user gets assigned an user ID. Usually it’s either randomly generated or based on an incrementing counter.
If you’re need to exchange data between multiple systems, the systems need to be able to refer to the same subject with the same identifier. One solution is to have a central authority that issues identifiers. For books, this could be ISBN. For humans, it can mean using national identification number such as henkilötunnus in Finland1 or using their account elsewhere as the identifier via services like Facebook Login.
What if you do not want to be tied to a central authority, or no suitable authority exists? Self-sovereign or decentralized identifiers could be the solution. The idea is to create unique identifiers such that the controller of the identifier can cryptographically prove that they control it. DID is an attempt to create a standard framework for such identifiers.
What are DIDs like?
Note: I’m basing this post on the version “W3C Working Draft 27 October 2020” of the DID specification.
DID identifiers (“DIDs”) are URIs and they look like this:
did:example:123456789abcdefghi
There are three parts separated by colons. The first part, did
, identifies
the URI scheme. The second part, example
, identifies the DID method, and the
last part, 123456789abcdefghi
, is the method-specific identifier.
Each DID is associated with metadata (“DID document”) and the DID method tells
you how to find (“resolve”) that metadata. The specification itself does not
specify any methods but there already are plenty of them in the DID Method
registry. Most of them seem to be blockchain-based, but there’s e.g.
the github-did that looks up a specially-named file in a specially-named repo
for the given user. My GitHub account is miikka
,
so I could control the DID did:github:miikka
if I created a suitable file.
The specification defines the data model for a DID document and includes three serialization formats (“representations”): JSON, JSON-LD, and CBOR.
You can, of course, define your own representations if you want. If the Clojure community would find use for DIDs, I imagine somebody would quickly define an EDN represetation.
Here’s a JSON-LD example of DID document for did:example:123456789abcdefghi
:
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
Under authentication
, there’s a Ed25519 public key that can be used to verify
that somebody is acting on behalf of the subject of this DID. Again, there are
plenty of verification methods if Ed25519 does not float your boat.
What’s the point?
There’s a related standard called Verifiable Credentials (VCs). They’re a way to issue cryptographically verifiable claims about a subject and, well, you need to able to identify the subject. I believe this is the origin of DIDs.
There’s a list of use cases for VCs. They include stuff like universities issueing VCs to certify that a person has completed a degree.
At this point, I’m not sure what to think. Does this solve a real problem in such a way that people are willing to use it?
In any case, this is a framework with so many options that if you intend to build something actually interoperable on it, you should start by defining a profile of what representations, verification methods, resolution methods etc. have to be implemented and should be used for your use case.
-
Are you a citizen of Finland? Consider signing this initiative to outlaw using HETU to authenticate people. ↩︎