Decentralized Identifiers and where to find them – about did:methods

The anatomy of a decentralized identifier

After her last encounter with decentralized identities in the over-the-air-update project, she wondered “How would I say ‘I am Alice’ using a decentralized identity?”. After all, the only uses of decentralized identities she encountered so far have been to communicate some kind of public key. So she set out to explore the background of decentralized identities.

Taking a step back, she noticed that the problem of decentralized identification is not that trivial. Even in the real world, answering the question “who is this person” is not easy. Imagine being in a bar, catching a nice smile from a friendly face in the back of the room. A centralized way to gather the information might be to ask the bar keeper who this person was. But his knowledge may be incomplete. However, he may know who this person regularly stops by with.

So the decentralized approach would be to ask the bar keeper’s contact or your own friend “who is this” and if they don’t know they may ask their friends. That way, you may get an answer that you will have to believe at this point short of directly asking the person whose name you were keen to grasp. Decentralization means building trust, trust in the chain of people you have to ask for the person’s name.

In the digital world, things are not that much different. Have a look at the following fictional did:bar identifier:

did:bar:example-inn:regulars:doe:john

As any did: identifier, this is a URI that follows the decentralized identifiers specification. In this example, did tells us that we encountered a decentralized identity. Afterwards, there are the following colon-separated segments:

• bar: the DID method, in this case telling us that it is a did:bar which basically instructs us how and where to look for identities, in this case we expect to have to go to a bar.
• example-inn:regulars:doe:john: the method-specific identifier, i.e., the part that tells us how to identify a single identity in the system of bar identities.

Let us take a look at the latter:

• example-inn: this is the entrypoint for did:bar identities, basically which bar to visit, hence which bar keeper to ask.
• regulars:doe:john: the path to the identity to take from the entrypoint, in this case through the bar keeper’s memories. He might remember that the person is a regular, that it’s a Mr. Doe, and finally get to the point of identifying him as John Doe.

Reading the specification, Alice notices that the bar keeper in our example even has an official role, the one of “verifiable data registry”. Well, if you trust your bar keeper, that is. We will definitely discuss this role later on for different DID methods.

Now there is one important question for Alice: if she wants to assign herself a digital decentralized identity, which method to choose. Obviously, she can’t use her regular bar and did:bar in a world-wide asynchronous community.

did:key, did:jwk, and ephemeral identities

In the over-the-air-update project, Alice encountered a very simple identity scheme: did:key, which has a surprisingly complex specification for something that basically encodes a public key. A did:key always looks like

did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6

where the method-specific identifier is nothing more than a base-encoded static public key. Because they are only detached key material, methods like did:key (or the very similar did:jwk which encodes the key as JWK) are called ephemeral DIDs.

While Alice recognized that this won’t be the solution for her own Alice identity, she wondered how the other aspects of the ecosystem related to these identifiers. For one, there is this notion of a DID document. The process of fetching the DID document for a DID is called resolution and usually involves asking the verifiable data registry. In the case of an ephemeral identity it can be assembled completely without any external interaction because the verifiable data registry is kind of the DID itself. For the given example, it would look like the following:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6",
  "verificationMethod": [
    {
      "id": "did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6",
      "type": "JsonWebKey2020",
      "controller": "did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6",
      "publicKeyJwk": {"kty": "OKP", "crv": "Ed25519", "x": "Icj9jU1EoDSw18LGMjIYjLLwnqEykHGM8CQrJqFyz_M"}
    },
    {
      "id": "did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6LSd2kEzu6jguh7Go5HvJyY7RBSKzgwLqVfAFHLiunSSJP2",
      "type": "JsonWebKey2020",
      "controller": "did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6",
      "publicKeyJwk": {"kty": "OKP", "crv": "X25519", "x": "FCC0HdadRrOtAr9s1P5T42gALxtrMeysaJZFc0pmDHk"}
    }
  ],
  "assertionMethod": ["did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6"],
  "authentication": ["did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6"],
  "capabilityInvocation": ["did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6"],
  "capabilityDelegation": ["did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6"],
  "keyAgreement": ["did:key:z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6#z6LSd2kEzu6jguh7Go5HvJyY7RBSKzgwLqVfAFHLiunSSJP2"]
}

There are quite a few things in this document, the most important part being the verificationMethod section that defines two public keys. Alice nearly missed it but the id parameter of such a verification method is actually the DID followed by an URL fragment, e.g., #z6Mkgj9Fq1W6eHf799QaNzAnrSr7fUiE9f5GoXatCaTwADx6. In the other methods, the verification methods are referenced by this identifier.

After having seen this and played around with a did key generator and resolver, she researched a few key features of these ephemeral identities:

• The identities are self-contained and can be generated by everything that can store a secret key, e.g., trusted platform modules (TPMs), other hardware security modules (HSMs), the Android KeyStore, or simply any software-based key generator.
• Resolution is possible without external interaction. This allows offline verification of, e.g., JWTs with a did:key issuer because its public key as verification method can be resolved directly from the DID.
• Because the DID directly encodes a key, the identity is static, there is no way to rotate its key, add another key or any other modification of the key material without changing the DID itself. Therefore, they are best used for short-lived or single-purpose identities.
• The key focus also means that they do not carry metadata, not even time of creation, owner or something similar. This makes them unsuitable for use cases that go beyond communicating key material.
• On the other hand, ephemeral DIDs can be a means of key communication. Most other DID methods can be reduced to an ephemeral DID by creating a DID based on one of the verification methods of their DID document (losing metadata of the verification method such as revocation details).

Identifying domains and web resources using did:web

After these insights into ephemeral DIDs, Alice knew that these would not be what she was looking for. She looked for other DID methods and found another promising DID method: did:web, a method settling on the internet’s existing momentum. As Alice already operates a web presence, she looked into the steps of building her own did:web identity:

• First and foremost, she needs to host a did.json file under the .well-known directory of her website, making the web server a verifiable data registry. In turn, her identity will be at https://alice.example.com/.well-known/did.json and identify her as did:web:alice.example.com.
• She could even have another did:web identity at her company at http://company.example.com/team/alice/did.json, her professional identity at did:web:company.example.com:team:alice.
• Regardless of the resulting hosting, she would need to ensure that the address is hosted via HTTPS because did:web’s trust model is based on the SSL certificate chain of the web.

As an example of a did:web, Alice looked at the official did:web:identity.foundation of the Distributed Identity Foundation responsible for many standards in the ecosystem. To resolve their DID, she could use a universal resolver or simply curl https://identity.foundation/.well-known/did.json to get

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/suites/secp256k1recovery-2020/v2",
    "https://w3id.org/security/suites/ed25519-2018/v1"
  ],
  "id": "did:web:identity.foundation",
  "verificationMethod": [
    {
      "id": "did:web:identity.foundation#04d63533b05fd69cd05843d41d5cf35ef1461f08ec8f80ea33bc5750751ca2b6a5fa5c1b7ec78d10cb785cac20bdf91a681ac0a7f47cccdf010b4b2a20f9db1e78",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:web:identity.foundation",
      "publicKeyHex": "04d63533b05fd69cd05843d41d5cf35ef1461f08ec8f80ea33bc5750751ca2b6a5fa5c1b7ec78d10cb785cac20bdf91a681ac0a7f47cccdf010b4b2a20f9db1e78"
    },
    {
      "id": "did:web:identity.foundation#6e6b416461e001f17961bbb0df763ed46cd9dcb64a2f37ade0f85579520de5f9",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:identity.foundation",
      "publicKeyBase58": "8S2hqHB2PjNSdDgsULTEqjXx2n3zF32fjGabbDJocGyv"
    }
  ],
  "authentication": [
    "did:web:identity.foundation#04d63533b05fd69cd05843d41d5cf35ef1461f08ec8f80ea33bc5750751ca2b6a5fa5c1b7ec78d10cb785cac20bdf91a681ac0a7f47cccdf010b4b2a20f9db1e78",
    "did:web:identity.foundation#6e6b416461e001f17961bbb0df763ed46cd9dcb64a2f37ade0f85579520de5f9"
  ],
  "assertionMethod": [
    "did:web:identity.foundation#04d63533b05fd69cd05843d41d5cf35ef1461f08ec8f80ea33bc5750751ca2b6a5fa5c1b7ec78d10cb785cac20bdf91a681ac0a7f47cccdf010b4b2a20f9db1e78",
    "did:web:identity.foundation#6e6b416461e001f17961bbb0df763ed46cd9dcb64a2f37ade0f85579520de5f9"
  ],
  "keyAgreement": ["did:web:identity.foundation#6e6b416461e001f17961bbb0df763ed46cd9dcb64a2f37ade0f85579520de5f9"],
  "service": []
}

The document looks very similar to the one of ephemeral DIDs but there is one major addition: the services section allowing to add arbitrary metadata. Alice could put links to her CV there or to her messaging accounts. This is basically her way to make the identity her own. More than just key management. And because the service space is less standardized than other parts of the ecosystem, she is completely free in the types of “services” she could add.

Content with the features of did:web, Alice tried to summarize the main differences to ephemeral DIDs:

• DIDs identify a resource on an HTTPS website using the trust network of today’s internet and its SSL certificate chains.
• DIDs are static while their documents are not, allowing for multiple keys, changes to the key material, and updates of metadata, all while not altering the identity to external parties.
• Because of the dynamic nature of the document, resolution of DIDs now requires external interaction. Instead of offline document generation for ephemeral DIDs, a did:web is resolved using an HTTP call to a JSON document on the internet.
• This JSON document is stored on a web server. All trust, availability and integrity guarantees are only as good as those of the web server.

Truly decentralized identities on distributed ledgers

So far, all DIDs Alice has encountered were somewhat decentralized but did not yet have typical decentralized verifiability provided by blockchains or distributed ledgers. Therefore, she decided to have a look at one example of DIDs on distributed legers, in this case did:iota on the IOTA ledger (the IOTA ledger being the verifiable data registry here).

{
  "doc": {
    "id": "did:iota:2304aa97:0x139b54aa5e5601e7950014b2906d410fd26a6bc271d5f77499b7c55351e23f79",
    "verificationMethod": [
      {
        "id": "did:iota:2304aa97:0x139b54aa5e5601e7950014b2906d410fd26a6bc271d5f77499b7c55351e23f79#Msuy0S_hW-6IFxqtCUx2YhzwyoYklWhSGizoQICyEBg",
        "controller": "did:iota:2304aa97:0x139b54aa5e5601e7950014b2906d410fd26a6bc271d5f77499b7c55351e23f79",
        "type": "JsonWebKey2020",
        "publicKeyJwk": {
          "kty": "OKP",
          "alg": "EdDSA",
          "kid": "Msuy0S_hW-6IFxqtCUx2YhzwyoYklWhSGizoQICyEBg",
          "crv": "Ed25519",
          "x": "xc8ziqeVtSVVRjqB5yhxg3tQyV3gvrKICecSSxvmsN0"
        }
      }
    ]
  },
  "meta": {
    "created": "2025-04-22T09:16:45Z",
    "updated": "2025-04-22T09:16:45Z"
  }
}

Alice was a bit astonished at first, it looked different. A did:iota documents contains the familiar elements in the doc part of the document and has additional metadata like creation and update date. In the actual doc part of the DID document, did:iota identities support everything did:web identities support too, including services where you may add metadata, keys and more.

Seeing the metadata immediately triggers the question how the resolution actually works that it can fetch these. In this case, did:iota:2304aa97:0x139b54aa5e5601e7950014b2906d410fd26a6bc271d5f77499b7c55351e23f79 consists of two method-specific identifier parts: 2304aa97, the network identifier (IOTA testnet in this case), and 0x…, the object identifier within the specified network. Resolution therefore means pointing a IOTA client to the network and asking a node in that network to retrieve the object in its current state using the given object identifier. From there, the document can be assembled.

That is also the point where the meta field becomes sensible because a distributed ledger’s state tracks updates in transactions and nodes may be at different state of synchronization. The IOTA client at resolution time may ask a node A in the network that has not yet seen the latest transaction for the given object which has been processed by node B. So querying a few seconds later may yield an updated document with a different timestamp. Therefore, IOTA’s additional outer structure for the DID document is much more of a feature of decentralized storage where you will always need to know which state has been assumed as “current” at the time of retrieval.

Compared with did:web identities, Alice identified the following major differences:

• The decentralized storage on a ledger guarantees the document to be stored on all nodes of the network instead of just one web server with a JSON file. This increases reliability and availability.
• The document can be updated as a did:web document can. However, updates can be tracked in transactions on the object. Tampering with the identity therefore needs access to the proper transaction signing key.
• Because updates are encapsulated in transactions on a network of multiple nodes, they now take time to propagate through the whole network (whereas an update on a did:web‘s JSON file is instantaneous).
• The availability, integrity, and trust guarantees of the IOTA network incur costs: each transaction that updates the identity will come with a small fee to pay for processing and storage.

In the end, Alice decided that she is but a humble developer without major trust requirements for her personal identity. For the time being, she will stay with did:web for its ease of use and integration into her existing presentation to the world. However, if she ever found herself immersed in Web3, she would definitely get herself an identity on a ledger.

filancore Sentinel and decentralized identities

At this point, Alice is getting a bit overwhelmed. There are so many more DID methods out there and so many more trade-offs to consider. However, she is also glad that she does not need to understand all those intricacies of the different specifications because she can just proxy DID and DID document handling for the whole identity lifecycle from creation to deletion through filancore Sentinel.

Furthermore, filancore Ankrypt allows creation of DIDs and documents using key material from many different sources, from software-generated keys to those from hardware chips. Combined with filancore Sentinel’s pluggable HSM support, the identity management can scale from tiny IoT device to hundreds of identities in an identity and access management system.

And when the scale increases, filancore Sentinel provides the did:ankr DID method which allows grouping identities anchored on a persistent distributed storage and storing the bunch of associated data in a different storage backend, providing a cost-efficient way to manage large amounts of decentralized identities.

Stay tuned for more details on decentralized identity management with filancore Sentinel, especially aspects of key material management and comparisons with public key infrastructure.