Decentralized Identifiers (DIDs) Explained

DIDs and Decentralized Identities

A decentralized identity system provides an infrastructure that allows components to authenticate subjects without having to call a central authority. Instead of issuing identity assertions on demand, authorities issue verifiable credentials beforehand to a credential holder. Credential issuers bind the credential (indirectly) to a key that is associated with the subject.

Whenever a credential holder presents a credential, the holder must also provide a proof-of-possession of an authorized key associated with the subject. This key is identified via a Decentralized IDentifier (DID) or more precicely a DID URL. To be able to verify such a proof and thus the authenticity of the subject, verifiers must be able to resolve that key.

The Decentralized Identifier

The idea behind decentralized identifiers (DIDs) is to provide the means for a globally unique identifier that individuals can control. DIDs do not include any central identity provider; they are persistent, cryptographically verifiable and resolvable. For that purpose, W3C defines DIDs as URIs.

Like any other URI, DIDs start with a scheme. In their case, the scheme is defined as did.

did:method:method-specific-id

After the scheme there follow an identifier for a DID method and a unique method-specific identifier. In this way, each DID becomes globally unique.

The DID method defines how the DID is created, resolved, updated and deactivated. Consequently, there is not a single way to resolve and work with DIDs but many. Thus, a system that claims to support DIDs often supports only a subset of DID methods.

Architecture Overview

DIDs refer to a DID subject, an entity that they identify. In the context of an identity system, the DID subject is commonly a natural person, the user.

DIDs resolve to DID documents. A DID document contains information related to the DID (or DID subject) such as public keys. A DID controller is authorized to make changes to the DID document as defined by the DID method. It can be the same entity as the DID subject but does not have to be.

Typically, both DIDs and DID documents are recorded on a verifiable data registry. The verifiable data registry can basically be any kind of trusted data storage including databases, distributed ledgers or decentralized file systems.

DID URLs contain the DID plus standard URI components like the path, query or fragment. They provide the means for locating a particular resource inside a DID document or even external to it. The process is called DID URL dereferencing and is partly specific to the DID method. DID URLs can, for example, serve as a pointer to a key within a DID document.

The DID Document

In the core specification W3C defines the DID document as follows:

A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject [...] can use to authenticate itself and prove its association with the DID. [...]

Technically, the only required data in a DID dcoument is the id that holds the DID of the DID subject, i.e. the same DID that resolves to this very DID document. The core specifications defines some common properties but a DID method can add other properties as well.

For DIDs to be useful for the decentralized identity system, the DID document must contain one or more verificationMethods. A verification method contains data that the DID subject may use to, for example, authenticate or interact with parties. For example, a verification method can hold public key material.

A DID document may list several verificationMethods, each is a map with at least the following properties:

• id: The identifier of the verification method in form of a DID URL. The id is used inside and outside the DID document to refer to the verification method.
• controller: Each verification method has a controller, i.e. an entity that may change or remove the verification material. The conroller of the verification method is identified via a DID and is not necessarily the same as the DID controller.
• type: A string value that defines the type of the verification method. The type specifies in which cryptographic context the verification material is used. For example, a verification method of type JSONWebKey2020 is expected to verify JSON Web Signatures. In that case, the key material is placed as a JWK in the publicKeyJwk property as illustrated in the example DID document below.

"@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ]

  "id": "did:example:abc123",
  
  "verificationMethod": [{
    "id": "did:example:abc123#sGCDSbTRsYrZQDfaZ8M4SNCJox8_w5-Pi8oVadExnY4",
    "type": "JsonWebKey2020", 
    "controller": "did:example:abc123",
    "publicKeyJwk": {
      "crv": "Ed25519", 
      "kty": "OKP", 
      "x": "PMpO4J4AQmsBNvyaVV_XReaOOyKJHRks8qEeM8zc2hQ", 
      "kid": "sGCDSbTRsYrZQDfaZ8M4SNCJox8_w5-Pi8oVadExnY4" 
    }
  }]

DIDs and Digital Proofs

Digital proofs are digital signatures: An entity with a private key makes a statement that entities with the matching public key can verify. This statement is called a digital signature.

The verification of a digital signature is only successful when the correct public key is used and the signature is not tampered with. There is no need for a shared secret to verify a signature - private keys remain private. Consequently, digital signatures lend themselves very well for proof-of-possession.

With DIDs there is no need to share the complete public key material for verification. Instead, it is sufficient to share the DID URL when sending the digital proof. The recipient then dereferences the DID URL, using the DID-method-specific rules, to retrieve the public key from the DID document in the verifiable data registry.

{
  ...
  "proof": {
    "type": "JsonWebSignature2020",
    "created": "2023-09-20T13:04:29Z",
    "proofPurpose": "authentication",
    "jws": "eyJhb...IAoDA",
    "verificationMethod": "did:example:abc123#sGCDSbTRsYrZQDfaZ8M4SNCJox8_w5-Pi8oVadExnY4"
  }
}

As mentioned at the beginning of this article, credential issuers bind verifiable credentials (indirectly) to keys. They do so by using DIDs to identify the credential subject. Consequently, the credential subject and DID subject are the same entity. Thus all verification methods listed in the DID document are associated with the credential subject as well.

{
  ...
  "credentialSubject": {
    "id": "did:example:abc123",
    "name": "Anna",
    "birthdate": "1970-01-01",
  }
}

When validating the presentation of a credential, the verifier needs to resolve the DID in the credential and dereference the DID URL in the proof of the holder. It then not only needs to validate the signature but the verifier also needs to check the authorization concerning the DID. In order words, the verifier needs to determine if the verification method that the DID URL in the proof refers to is authorized in the current context (e.g., authentication of the DID).

In a simple use-case the DID in the DID URL of a proof and the DID in the credential are the same. In more advanced use-cases, like guardianship, the DID in the credential and the DID URL may differ because the entity that is identified by the credential is not the same that is presenting it. It depends partly on the DID method which use-cases a DID supports and on the application on how it chooses to utilize the tools to embrace their power.

Conclusion

Decentralized identifiers look pretty simple and familiar because they build upon well established web standards (URI). However, on a closer look they are more than just identifiers. DIDs offer powerful possibilities for implementing decentralized identity use cases.

DIDs not only allow for decentralized key management where individuals can control the key material but they also support advanced authorization use-cases. They are the link that connects the building blocks of a decentralized identity system. Most of the time though, it helps to think of a DID as a pointer to public keys.