Decentralized Identifiers (DIDs) provide a way for entities to convey self-managed cryptographic material for identity assertion, and metadata. Entities can be anything, from persons, IoT devices, governance bodies, legal corporations to websites. DIDs are most commonly used when issuing or presenting Verifiable Credentials, and can be used as a more flexible and safe alternative to JWK Sets served on a URL.

Implementations of the DID specification, a.k.a. DID core data model, are known as DID methods. A DID method specifies how DIDs of this particular type are managed (created, updated, deactivated) and resolved. For instance, a DID of the Web DID Method could be did:web:reinkrul.nl. According to the DID Web Method specification, its DID document must be resolved at https://reinkrul.nl/.well-known/did.json.

Example

The did:web DID document could look as follows:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3c-ccg.github.io/lds-jws2020/contexts/lds-jws2020-v1.json"
  ],
  "id": "did:web:reinkrul.nl",
  "assertionMethod": [
    {
      "controller": "did:web:reinkrul.nl",
      "id": "did:web:reinkrul.nl#1",
      "publicKeyJwk": {
        "crv": "P-256",
        "kty": "EC",
        "x": "cGZZFl9B6W9J8_egIs7anPVyGTd5XUWM-hYMP2WV4Eo",
        "y": "aXfV9P_1N1-On4W2McXKAePzpYE-F_zx8Q0K1OWvyCM"
      },
      "type": "JsonWebKey2020"
    }
  ]
}

This DID document defines an elliptic curve public key that will be for assertion purposes, typically used for signing statements (e.g. presenting credentials).

Identifying DID method traits

When designing an ecosystem that uses DIDs, choosing the right DID methods is crucial: it can make or break security, usability and maintainability. Most important categorical traits of DID methods are:

  • Self-contained: the DID itself is enough to resolve the DID document without querying any external resources. For instance, in the DID JWK method (e.g., did:jwk:eyJjcnYiOiJQLTI1N...(etc)), the DID specifies the literal public key as JWK, that will end up in the resolved DID document. These DID methods are often cheap and simple to use, since there aren’t any external dependencies. The big trade-off is that they don’t support key rotation or deactivation, meaning key leakage and long-lived keys are a problem.
    • did:jwk, did:key, and did:x509 are examples of self-contained DID methods.
  • Self-certifying: the DID itself can be used to verify the resolved DID document, creating high confidence in the resolved DID document. The DID typically contains a hash of the DID document (e.g., did:ion), or because it’s self-contained. If a DID method is not self-certifying, secure transport or distributed ledger technology (DLT, often in the form of blockchains) is needed to ensure the integrity of the DID document.
  • Key rotation: the ability to update the cryptographic keys associated with a DID without changing the DID itself. This is crucial for maintaining long-term security and usability. It can also be used a backup-key mechanism in case the primary key is lost or compromised.
  • Infrastructure: many DID methods rely on distributed ledger technology (DLT, often in the form of blockchains) that provide a secure, tamper-evident operation log. For instance, did:ion (long form) is built on top of Bitcoin, using its ledger to anchor operations. This can provide a high level of security and decentralization but also introduces dependencies on the underlying ledger’s availability and performance. DIDs that do not depend on DLTs, like did:web, may be simpler and faster but might require additional measures to ensure security and trust guarantees.
    • Be aware of DID methods using complex DLT, can lead to parties using a service provider as gateway to the DLT, which may introduce centralization and trust issues.

Summarizing

When choosing a DID method, it’s important to consider the specific needs and constraints of your ecosystem. For example, if you require high security and the ability to update keys regularly, a method that uses DLT might be a good fit. On the other hand, if simplicity and low cost are more important, choose a DID method that requires simpler infrastructure.

Each DID method comes with its own set of trade-offs in terms of security, decentralization, and operational complexity. Understanding DID method traits and trade-offs, and how they align with your requirements is essential for a successful implementation of DIDs in your ecosystem.

For further reading, the Decentralized Identity Foundation (DIF) recently started identifying DID method traits in more detail, see DID Method Traits for more information.