Moving Beyond the Limitations of did:web

Is it time to reassess the adoption of did:web in light of new ledger-based developments?

Co-authored by: Markus Sabadello (Danube Tech), Alex Tweeddale (cheqd), Carsten Stöcker (Spherity GmbH), Alen Horvat (Netis).

Executive summary

did:web is becoming a honey trap for organisations looking to adopt decentralised identity and credential-based technology. While it is attractive due to its low cost and simplicity (the honey🍯), it is easy to get stuck with it beyond testing environments (the trap 🪤). There are a series of challenges and vulnerabilities with did:web which need to be fully understood before using the method in production environments.

These core issues run deep, to the point where did:web is beginning to falsely represent the true value and core purpose of DIDs, since the DIDs are not decentralised, cryptographically verifiable, tamper resistant, self-certifiable or persistently stored. And while there are proposals to improve did:web, such as did:webs and did:webplus (which do have merit in their own right), we believe that it is now time to reconsider the adoption of a select few ledger-based alternatives.

Ledger-based approaches such as EBSI and cheqd have reached a state of maturity where the value of their DID methods goes beyond simple DID resolution. These additional benefits include:

1. Historically resolvable, traversable and persistent DID Document states, queryable through standardised DID URL dereferencing.
2. Fully resolvable, traversable and cryptographically verifiable trust registries, status lists and schemas, using DID-Linked Resources.
3. Machine readable governance rules and permissions for scalable trust frameworks, using DID-Linked Resources.
4. DID resolvable and cryptographically verifiable proof of ownership of decentralised, digital data stores, such as Decentralized Web Nodes (DWNs).
5. New commercial models for verifiable credentials including payments to unlock ledger-based status lists or trust registries.

At the same time, more established ledgers such as Indy and ION have continued to improve their tooling, developer experience and provide excellent options for general ledger-based DID resolution and digital credential ecosystems.

With these innovations, adopters can build fully decentralised trust ecosystems, without relying on centralised web domains or single points of failure. This realigns the value of DIDs far closer to their original purpose, than the regression and reliance on more centralised architecture perpetuated by did:web.

Introduction

The decentralised identity community has gradually drifted away from initially adopted decentralised DID Methods (such as did:sov and did:ethr) and towards the adoption of more centralised approaches, such as did:web (and even regressing to non-DID solutions such as X.509 Certificates).

This is because the simplicity and cost-effectiveness of establishing a credential ecosystem using did:web has led to a general sentiment that did:web is good enough “for now” or “until something better comes along”. At the same, the more established ledger-based approaches (did:sov, did:indy, did:ethr, did:ion) have had challenges with interoperability, regulatory uncertainty, scalability and integration effort.

Although the narrative of moving towards did:web has held sway, we believe that it is time to reassess its legitimacy in light of significant developments and innovations made by alternatives, coupled with the emergence of more accessible tooling to easily integrate with these methods . To illustrate why it is the right time for this, this paper aims to shed light on two key points:

1. We’re sleepwalking back towards “centralised” identity 🧟

did:web has significant concerns and vulnerabilities when used in production environments, which were never intended to be part of the design of DIDs.

These issues need to be thoroughly understood before deciding to use this method, and additionally, they are adversely affecting the reputation of DIDs in general. This is having the effect of undoing all the good work of establishing a “decentralised” identifier and has led to adopters regressing back to traditional identifier models like X.509 certificates, since did:web does not offer many significant benefits to justify the switch up costs and additional development.

2. We’re too quick to dismiss new ledger-based innovations 🤔

There is no denying that the community has a chequered history with ledger-based approaches to decentralised ID. Owing to these challenges, as well as a handful of illegitimate and immature ledger-based DID methods, there has been a widespread scepticism around any of the developments made in this space.

Yet, in the last year, a few ledger-based methods in particular have seen substantial improvements, many of which have gone unnoticed by the community. These improvements now offer a value proposition extending far beyond simple DID Resolution, including fully resolvable, cryptographically verifiable and persistent DIDs with linked trust registries, status lists and governance rules/permissions.

Therefore, we believe that it is now a viable option to move beyond the limitations of did:web, and begin considering a selection of alternatives, including ledger-based DID methods with greater confidence.

What was the initial goal of DIDs? 🥅

To help frame our argument, a good question to explore, reflect upon, and use as a reference point is: why were DIDs initially created?

The idea for a Decentralised Identifier (DID) was initially conceived around 2015, close to the same time when Self-Sovereign Identity (SSI) emerged as a concept. One of the earliest documents that influenced this development was “Decentralised Public Key Infrastructure” (DPKI), drafted at Rebooting-the-Web-of-Trust (RWoT) #1 and co-authored by notable thought leaders in the SSI space, as well as Vitalik Buterin, who went on to found Ethereum.

This work recognised that the problem with traditional identity systems is that they were based on centralised and hierarchical roots of trust, which ultimately revolved around a small set of actors. In contrast, the DKPI paper proposed that a new type of identifier was needed: one which was independent of central authorities and control.

At the time, a theoretical concept known as Zooko’s triangle was often used to describe three desirable properties of identifier systems:

1. Human-meaningful 💡
2. Secure 🔒
3. Decentralised 🕸️

The existing “identifier” system, the Domain Name System (DNS), fulfilled the “secure” and “human-meaningful” properties, but did not fulfil the “decentralised” property.

DIDs on the other hand were designed to be “secure” and “decentralised”, but not necessarily “human-meaningful”. This was why many of the original DID methods were based on distributed ledgers (did:sov, did:ethr). It was only several years later that other derivations of DID methods such as did:web, did:key, did:peer and did:jwk were developed.

Why is this important to understand?

The invention of, specifically, the did:web method, had a profound impact on the W3C DID Working Group, as it was seen as a DID method that could fulfil the technical requirements of a DID (with regard to its syntax and capability for DID resolution), but it was not a “Decentralised Identifier” in the original sense. This is because it was not decentralised, persistent or cryptographically verifiable.

This created a level of dissonance between did:web, which has gained increasing adoption, and the actual purpose, utility and extensibility of DIDs — prompting a rhetorical question that we will consider throughout — if a DID is not decentralised, why use DIDs at all?

The did:web honey trap 🍯

did:web is undoubtedly very simple to use, cost-effective and is functional for proving the concept of DID resolution. Yet, it’s a bit like a honey trap.

This is because the reliance on did:web as the primary DID method supported in client applications, beyond testing environments, has significant vulnerabilities as well as having a negative effect on the reputation of DIDs. It pulls a lot of adopters in, who then get stuck with it as their idea of what DIDs are capable of eroding many of the fundamental properties of DIDs, which we will discuss in turn.

DID Document Provenance and Versioning

One unique and largely underappreciated feature of the DID Core specification is the feature of provenance, i.e. the ability to resolve DIDs back to a specific point in time, even if the DID Document has been significantly updated since that period.

DID Document provenance enables important use cases such as data and service portability, stable address books, key rotation, and key updates. To support this, the DID Core specification defines various DID parameters (versionId, versionTime) and metadata properties (updated, nextUpdate).

The did:web method simply does not support these features; and while it would theoretically be possible to extend the did:web method to add a version history (see did:web issue #61), it would never be immutable and cryptographically verifiable as it is in other DID methods. Recently, we’ve seen proposals such as did:webs which aims to use KERI to witness and relay did:web event logs to add an extra layer of provenance.

This is a welcome improvement to did:web 👏 but may create interoperability challenges between did:webs witness “smart” applications and others, unless it’s implemented within something like the Universal Registrar / Resolver.

Data Integrity and Tamper-Resistance

Using centralised hosting providers, such as a web-domain, to store DIDs may have a significant difference in the longevity, authenticity and auditability of DIDs and any Verifiable Credentials reliant on the DID authentication. This is because:

1. DIDs may be spoofed or compromised: DIDs and DID Documents stored at a centralised web endpoint can be compromised and replaced by malicious actors.
2. Hosting providers are known for down-time: Hosting providers (even highly reputable and sophisticated providers) could terminate accounts due to factors such as non-payment of fees, violation of Terms of Service, etc.
3. did:web links may be deprecated and throw errors: A link pointing to a DID Document may be changed, resulting in a dead-link and error for a client application relying on the verification of a Credential signed by a deprecated DID.

Privacy and the “Phone Home” problem

The “Phone Home” problem is a significant privacy and confidentiality issue associated with the did:web method. With did:web, the issuer can track or record:

1. Any time your DID is requested by a verifier,
2. The frequency of requests,
3. Timestamps of requests,
4. IP addresses,
5. User agent details.

This information can be correlated, allowing the “issuer” to potentially identify the interactions of specific “holders” — which is a significant risk to privacy and the legitimacy of DIDs and Verifiable Credential solutions. This is something that is incredibly important for adopters of the method to consider, because this results in the use of Verifiable Credentials replicating the same problems as “Web2” in terms of tracking and big data analytics.

Self-Certifiability

did:web DIDs have no inherent “self-certifiability”. This means that the DID identifier itself does not cryptographically link to the DID Document at all. This reduces the level of assurance a relying party will have in a did:web DID because the DID Document contents and associated keys may have been edited or spoofed without any cryptographic checks validating the DID’s authenticity.

There have been proposals to improve this aspect of did:web, such as did:webplus, but again, while it is a reasonable attempt to paper over the cracks, it will still be vulnerable to other issues, which may be mitigated through alternative methods. Ultimately, while using did:web has been a practical approach to set up a decentralised identity solution quickly and efficiently, this comes at the cost of security, cryptographic integrity and provenance.

The Slope of Enlightenment for Ledger-based DID Methods 📈

There has undoubtedly been a history of hesitancy and scepticism around the need or requirement for ledger-based DID methods because centralised methods such as did:web, did:key and did:jwk can largely accomplish the same core value in terms of simple DID resolution.

Ledger-based DID Methods have also historically built a poor reputation. There are a myriad of ledger-based DID methods (likely over 100) within the DID Spec Registries, and largely these methods come with a catch, including

1. Interoperability challenges: with unique transaction types which require a particular software stack to utilise
2. Scalability issues: with high transaction volumes and high volumes of requests
3. Integration blockers: with poor/incomplete documentation and long integration timelines
4. Blockchain hysteria: with too many projects professing to “put everything on the blockchain”, leading to privacy nightmares and valid questions of their legitimacy.

However, more recently, we are beginning to see a level of maturity in a select few ledger-based DID methods that are starting to take advantage of the broader aspects of the DID Core spec.

We have also seen substantial developments in the interfaces for consuming and using ledger-based DID methods, with the Universal Resolver and Registrar projects providing a way to consume an array of ledger-based DID methods with interoperability, without bespoke integrations.

Gartner Hype Cycle Graphic

Having initially peaked and then dropped off into the “Trough of Disillusionment”, we now think that a select few ledgers, with recent innovations, are climbing into the “Slope of Enlightenment”.

For this reason, we want to reiterate that not all ledgers should be viewed with the same hesitancy as the majority, and it is worth reassessing their maturity, legitimacy and capability to deliver on the fundamental components of DID Core, including:

Persistent DID Document Version Lookup and Retrieval ↩️

As described earlier as a omission of did:web, being able to persist and query historic versions of DID Document states is highly valuable in production environments, where Credentials are expected to have a long life span or in use cases where issuers frequently rotate their keys or update their DID Documents.

Going into production environments, it is very important for a “holder” to be able to prove that the keys signing their Credential were valid at the point of issuance, even if the issuer has rotated to new Verification Method keys multiple times since issuance.

Without version lookup and retrieval, Credentials will have a far shorter life cycle and Level of Assurance — these Credentials will likely need to be issued more frequently because key rotations will overwrite previous keys unless the historic information is persisted.

DID methods, for example, “did:cheqd” and “did:ebsi” both currently have working, production-ready DID Resolvers with query parameters to fetch historic versions of DID Document states from their respective methods, including standardised query parameters such as “versionId” and “versionTime”. For example:

• did:example:38428720–301e-4168-abac-c93581f08a3c?versionId=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?versionTime=X

Service providers like Godiddy.com provide the same functionality for several additional DID methods, creating the first of many value adds between ledger-based methods and did:web.

Verifiable Trust Registries and Status Lists 🍏

Trusted Issuer Lists are a critical component in the world of Decentralised Identifiers (DIDs) and Verifiable Credentials. They serve as a registry of trusted entities that are authorised to issue credentials or conduct other actions, thereby enhancing the trustworthiness and reliability of the credentials issued within the system. However, Trusted Issuer Lists have experienced a similar teething problem to did:web, in the sense that most approaches to them are based on centralised, traditional infrastructure.

Recently, several organisations and initiatives have made significant strides in implementing ledger-based Trusted Issuer Lists, including:

1. European Blockchain Services Infrastructure (EBSI)’s Trusted Issuer Model, enabling DIDs and their associated Verifiable Attestations to be written to a permissioned Trusted Issuers Registry.
2. cheqd’s approach to DID-Linked Trust Registries, enabling DID Controllers to create Trusted Issuer Lists within a “Collection” of “Resources” associated and linked with their DID. This is made possible via an emerging W3C specification called DID-Linked Resources.
3. Open Credentialing Initiative (OCI)’s Trusted Issuer Registry, managed through a smart contract deployed on the public Ethereum blockchain.

Similarly, Verifiable Credentials Status List v2021 is the most commonly adopted way of currently tackling credential revocation. However, this method requires an issuer to publish a public Verifiable Credential to a centralised server, which displays the latest revocation status of issued Credentials within a bitstring. The centralised nature of the server reflects similar issues to those raised earlier around did:web, particularly in terms of persistence, uptime, security, verifiability and data integrity.

Again, this is being solved by ledger infrastructure, with approaches such as:

1. cheqd’s ledger-based Status List 2021 which publishes each Status List entry and bitstring as a distinct DID-Linked Resource, resolvable and identifiable via a DID URL.
2. Ethereum’s Ethereum Improvement Proposal (EIP) worked on by the team at Spherity, which uses similar logic to Status List v2021, but with additional improvements to delegation.
3. Hyperledger’s AnonCreds revocation which uses cryptographic accumulator based Status Lists, written on ledger, to calculate whether a Credential is part of a revoked set in a privacy-preserving way (note that there has also been great work by the Indy and AnonCreds communities to update the AnonCreds spec and make it ledger-agnostic, meaning that this is no longer an Indy-specific approach).

In combination with a ledger-based DID method, these on-chain trust lists create a robust, and importantly, decentralised way of managing additional contexts such as trusted issuers and credential statuses. They offer a balance of security, transparency, auditability, and control, while also providing resilience, privacy, and usability. All of which cannot currently be achieved using did:web or centralised alternatives.

Universal Resolver and Registrar 💫

One fundamental aspect of DIDs that should be kept in mind is that by the use of “methods”; this technology has always been designed to be an abstraction layer on top of pretty much any identifier system. No matter if an application uses did:web, a ledger-based DID method, or any other method such as did:key, there is always a common syntax and the common DID Document format which describes the subject. The exact process of obtaining the DID Document for a given DID of course is defined by the method and can vary greatly. In fact, this design has been a common point of discussion within the W3C DID WG, and there have been questions whether such an abstraction layer provides sufficient “useful interoperability”, considering the differences between DID methods.

Initiatives such as the well-known Universal Resolver and Universal Registrar open-source projects at the Decentralized Identity Foundation (DIF) make it easy to use this abstraction layer not only in theory, but also in practice.

These components can be used to perform the standard DID operations (Resolve, Create, Update, Deactivate) across many different DID methods via a single “universal” interface. Building on top of such standard interfaces removes the complexity of bespoke integrations with each method and creates a more “future proof” way of interfacing with DIDs, since applications can easily plug in support for additional DID methods at any time, and layers of concern are cleanly separated. Commercially hosted services such as Godiddy.com also offer this type of interoperability interface as a service.

Realising the True Power of DIDs 💪

A crucial point and takeaway is that did:web adoption presupposes that the power of a DID is in its ability to be resolved to fetch the keys listed in the DID Document. While this is often all that is required for a use case, it only uses a fraction of the potential of the DID Core specification’s extensible design.

Ledger-based DID methods haven now taken DIDs beyond simple resolution, and utilise the persistence and immutability of the architecture to provide trusted resolvable DID URLs to external ledger-rooted resources, such as Decentralized Web Nodes (DWNs), Trusted Issuer Lists, Status Lists, schemas and other governance information.

DID-Linked Resources (DLRs) are game changers ⚡

DID-Linked Resources (DLRs) is an emerging W3C specification that takes ledger-based resources (such as Trusted Issuer Lists, Status Lists, Schema Registries, Overlay Capture Architecture etc) and identifies/retrieves them using DID URL patterns and dereferencing.

It enables organisations to leverage the benefits of on-chain, persistent and verifiable lists and resources, while creating a common syntax for identifying and retrieving them, across any ledger-based DID method. It also reuses the same trust patterns established in the DID Core spec, since the author of a DLR needs to sign the transaction with the same key material within the linked DID Document.

This generic architecture for DID-Linked Resources is shown in the diagram below, and for readers who want to learn more, we’d suggest reading cheqd’s Architecture Decision Record on their technical composition.

DID-Linked Resources diagram

The DLR specification additionally provides a set of query parameters to identify and retrieve different derivations of digital resources, associated with a DID, which may be combined to create rich filters, including (but not limited to):

• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceId=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceCollectionId=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceType=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X&resourceVersionTime=XMLDatetime
• did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X&resourceMetadata=true

DID-Linked Resources has currently been fully implemented by chains such as cheqd and Cardano with EBSI also interested in supporting them. DLRs can be applied for various use cases, such as:

1. Ledger-agnostic AnonCreds
2. DID-Linked and fully verifiable Trust Registries
3. DID-Linked and fully verifiable Schemas
4. DID-Linked and fully verifiable Status Lists
5. Encrypted DID-Linked Status Lists, Trust Registries or Schemas with Payments required to unlock.

Through using DID-Linked Resources, issuers can include ledger-based Resource in the contents of issued Verifiable Credentials. These resources can be relied upon by Verifiers with full confidence in their authenticity, data integrity and security. Not only can this add additional value to Credentials, but also does not create interoperability challenges as these are only optional “add ons”.

These benefits however, can only be realised using ledger-based DID methods, as with did:web, it would be possible to create DID-Linked Resources, but they would again be vulnerable to the same limitations as the DID method itself.

For this reason, DID-Linked Resources complement ledger-based DID methods, and ledger-based DID methods enable innovations like DID-Linked Resources. This specific development takes the benefits of using a ledger much further than simple DID resolution, allowing issuers to create far more robust roots of trust for full scale, production-ready Self-Sovereign Identity ecosystems.

Decentralized Web Nodes (DWNs) and DID-Relative URLs to establish trust

A Decentralized Web Node (DWN) is a data storage and message relay mechanism which entities can use to locate public or private permissioned data related to a given Decentralised Identifier (DID). DWNs were created by the team at TBD for the furtherance of Web5, an internet based on identity primitives and digital credentials.

The DWN specification utilises the “services” section of the DID Core spec alongside query-based DID URL dereferencing to allow DID Controllers to point to specific storage or messaging endpoints. For example:

• did:example:alice?service=DecentralizedWebNode &message= toBase64Url( JSON.stringify( { MESSAGE } ) )

This syntax not only uses the security and provenance of a DID, but extends the value of DIDs away from purely resolution, and provides DIDs the ability to authoritatively identify external data and resources, where third parties can be confident that the data belongs to the DID Controller. This has a lot of overlap with DID-Linked Resources, and builds on very similar principles.

With did:web on the other hand, extensibility via the “services” section, while possible, is limited by the same vulnerabilities as the method itself.

Looking ahead

With one eye on the fragilities of centralised DID methods such as did:web, and another on the developments made by a selection of ledger-based DID methods, we hope to see a general movement away from the vulnerabilities of the former.

Already, several initiatives are underway that attempt to combine the benefits of did: web and ledger-based approaches. These include the did:webs, did:webplus and the recent RWOT advanced topic paper on moving beyond did:web, which use the current did:web design as a starting point and propose to add a layer of cryptographic verifiability, auditability and persistence. While such improvements do not fully eliminate the downsides that come with a dependence on DNS and web infrastructure, they do provide good stepping stones away from some of the fragilities of their predecessor.

Looking forward towards the latter, we hope that some of the legitimate players and innovators in the ledger space can begin to undo some of the scepticism rooted here, for three reasons:

1. Technical innovation: As described above, DID URL dereferencing, service discovery and DID-Linked Resources provide additional benefits to the use of DIDs, in line with their initial conception; where notably, these benefits cannot be gained from using did:web.
2. Regulatory clarity: We are now seeing strides made in regulatory clarity for ledger-based approaches in the context of eIDAS 2.0, with “electronic ledgers” now set to be listed as valid “qualified trust services” under the European Electronic Identification (‘eID’) framework. 🤞
3. Accessibility and interoperability: Open Source projects such as the Universal Resolver and Registrar provide interfaces for developers to utilise any supported DID method without a time-consuming integration, using REST APIs.

Although we do not expect a full movement to ledger-based methods overnight, we hope that the information and explanations provided here help readers recognise the benefits that some ledger approaches can now provide over did:web; and, where the use case makes sense, we hope that adopters may be more open to considering these methods into their design decisions.