Does the W3C Still Believe in Tim Berners-Lee’s Vision of Decentralization?

The W3C—the standards body for the World Wide Web founded by Sir Tim Berners-Lee in 1994—is now facing one of the most important decisions in its history. It goes to the heart of a core design principle for the Web articulated in 1998 in the opening words of Tim’s Principles of Design for the World Wide Web:

Again and again we fall back on the folklore of the principles of good design…. Principles such as simplicity and modularity are the stuff of software engineering; decentralization and tolerance are the life and breath of [the] Internet.

Tim goes on to explain what is meant by “decentralization”:

This is a principle of the design of distributed systems, including societies. It points out that any single common point which is involved in any operation trends to limit the way the system scales, and produces a single point of complete failure.

As foundational as it is, the decentralized architecture of the Internet and the Web is in serious peril. In 2017, the Mozilla Foundation’s Internet Health Report said:

The benefits of a decentralized Internet are eroding. When we concentrate our online activity on just a few social networks and messaging apps – as billions of us do – it narrows our experience of the Web to one where we are pointed only at content that appeals to our likes in search results and social media streams. Here, we are consumers rather than creators.

So imagine the surprise of the W3C Decentralized Identifier (DID) Working Group when, two years after it was chartered in 2019 to develop a specification for a new type of cryptographically verifiable identifier that would no longer require centralized identifier registries and certificate authorities—and after the Working Group met every requirement of its charter, including all horizontal reviews and other requirements of the W3C process—when the spec to a final member vote in August, none other than Mozilla filed a formal objection to block approval.

Even though votes of W3C members are private, it soon became public that two other formal objections were also filed—by Google and Apple.

In short, three of the four biggest browser vendors had voted to formally block the DID 1.0 specification. This despite the fact that over ten times as many other W3C members voted in favor.

What is going on here?

If you are stunned by this, you are hardly the only one. Evernym joined the W3C in 2017 specifically to work on standards for DIDs and verifiable credentials. We led the original work on the DID specification that began in early 2016. In 2018, we and the rest of the authors contributed it to the W3C Credentials Community Group with the goal of turning it into a full W3C standard. When the two-year charter for the DID Working Group was approved in September 2019, Evernym contributed one of the two Co-Chairs and one of the Editors.

So this sudden turn of events is of tremendous concern not only to us, but to our customers who have been using DIDs in production systems for verifiable credentials including international travel passes, staff passes, credit union member passes, and patient-centric healthcare credentials.

Although DIDs are not required for the use of verifiable credentials, in Section 4.2 of the W3C Verifiable Credentials (VC) Data Model 1.0 specification the authors noted:

It is expected that many verifiable credentials will use DIDs and that software libraries implementing this specification will probably need to resolve DIDs. DID-based URLs are used for expressing identifiers associated with subjects, issuers, holders, credential status lists, cryptographic keys, and other machine-readable information associated with a verifiable credential.

When the VC Data Model 1.0 spec was approved as a full W3C Recommendation in September 2019, it ignited a firestorm of innovation. Since then:

• Dozens of VC-capable mobile wallet apps are now available in the app stores—the vast majority of which support at least one type of DID.
• The Decentralized Identity Foundation (DIF) and the Trust Over IP (ToIP) Foundation—both of whom consider DIDs to be an atomic building block of their infrastructure—have collectively grown to over 300 member organizations.
• Multiple governments have announced decentralized digital identity wallet initiatives including the EU (Germany, Finland, Spain), Canada (British Columbia, Ontario), and Latin America.
• The U.S. Department of Homeland Security is funding the development of DID-based verifiable credentials as a standard the U.S. Customs and Border Protection service can use for supply chain verification in the largest trade network in the world.
• In response to the COVID-19 crisis, DID-based decentralized digital credentials are now being used by the International Air Transport Association (IATA) and dozens of airlines around the world to enable passengers to provide privacy-respecting proof of their health status.

In the face of all of this market evidence for the value of DIDs, why would these browser vendors be objecting?

What were their actual objections?

The table below summarizes the four objections. On the left is the wording from Mozilla’s summary. On the right is a translation into plain English for those not intimate with the DID specification.

Do any of these objections hold real water?

In short, no. Although on the surface they appear to be quite substantive, within hours of Mozilla’s post, members of the DID Working Group had reviewed all four objections and were practically tearing their hair out with frustration at how the objections misconstrued the purpose and design of the DID specification and raised red herrings that have nothing to do with its real technical or business merits.

While a full discussion of each objection would take an entire blog post in itself, here is a brief summary of why none of them hold up under scrutiny.

#1: No practical interoperability of DID methods

Of the four objections, this was the most infuriating to the DID WG members. First—for anyone not familiar with DIDs—the DID 1.0 specification defines the generic requirements for any valid DID the same way the URI specification (RFC 3986) defines the generic requirements for any valid URI and the URN specification (RFC 8141) defines the generic requirements for any valid URN. The whole point is to establish a new class of global identifiers and then let others define their own specifications for particular instances of that class.

With URIs, those instances are called schemes. There are currently 345 schemes registered in the IANA URI Scheme registry. With URNs, those instances are called namespaces. There are currently 70 URN namespaces registered in the IANU URN Namespace registry. With DIDs, those instances are called methods. There are currently 112 DID methods registered in the DID Spec Registries (which the DID WG currently publishes as a W3C Note as we wait for the W3C to formally implement registries).

Because you need to formally define a class before you can define instances, section 1.1 of the DID Working Group Charter explicitly stated that defining any instances of DID method specifications was out of scope.

In other words, the objection that the DID WG should have standardized a whole set of DID methods before defining the DID 1.0 specification is exactly backwards. We need to formally agree on the generic requirements first so that 112-and-counting DID method authors can formally define their specific instances. Which brings us directly to the second objection…

#2: Encourages divergence rather than convergence of DID methods

Given what we just explained, we believe most observers would interpret our having 112 DID methods already registered by implementers—even before the DID 1.0 specification is formally approved by W3C—as nothing less than remarkable evidence of the value the market is already seeing in DIDs. But in their published objection, Mozilla decided to interpret it this way:

The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods. Note this is in contrast with prior examples given (URL schemes, image & video formats). Thus, whether intended or not, the DID specification (and perhaps its inherent architecture) is designed in such a way that encourages divergence of implementations, rather than convergence & interoperability.

The nearly unanimous reaction of the DID WG members after reading that objection was: “Did Mozilla actually read the DID 1.0 spec?” Because the entire point is to ensure interoperability of DIDs regardless of the DID method. You needn’t look any further than the definition of a DID resolver in section 1.3:

A DID resolver is a system component that takes a DID as input and produces a conforming DID document as output. This process is called DID resolution. The steps for resolving a specific type of DID are defined by the relevant DID method specification.

In other words, as long as all DID methods conform to the DID 1.0 specification—the result of the two years of intense focus on interoperability requirements by the Working Group—then by definition all DID methods have a baseline of interoperability. They all input a conformant DID and they all output a conformant DID document. Furthermore, this is actually a much higher level of functional interoperability than URI schemes or URN namespaces, all of which work in different ways and produce different outputs as defined by their specifications.

#3: Centralized DID methods are not prohibited

This objection from Mozilla was particularly frustrating because it completely ignored another explicit deliverable of the DID WG: the DID Method Rubric 1.0. From section 2.2 of our charter:

Decentralized Characteristics Rubric v1.0
The Working Group will develop a rubric of decentralized characteristics for DID Method specifications. This rubric will provide reference points according to which a DID Method specification may self-certify, or an independent third party may evaluate, the DID Method specification’s level of adherence to principles of decentralization.

This work, reflecting many months of effort led by editors Joe Andrieu and Daniel Hardman, reflects what we believe is one of the most in-depth, sophisticated analyses of how to evaluate the actual characteristics of a decentralized system. To quote from the abstract:

The communities behind Decentralized Identifiers (DIDs) bring together a diverse group of contributors who have decidedly different notions of exactly what “decentralization” means. Rather than attempting to resolve this potentially unresolvable question, we propose a rubric — a scoring guide used to evaluate performance, a product, or a project — that teaches how to evaluate a given DID Method according to one’s own requirements.

The Rubric reflects a critical point about decentralization: not only should the DID WG not dictate what DID methods are and are not “allowed”—but neither should the W3C. Decentralization means not just allowing but encouraging “innovation at the edges”. Note that this does not mean the DID WG should have no rules about registration of new DID methods in the DID Spec Registries. We do in fact have such registration policies. But they do not include the editors passing judgement on whether a DID method is or is not “decentralized”. That is for the market to decide—just as the market has decided for years now what URI schemes and URN methods best meet its needs.

#4: DID methods using proof-of-work blockchains are harmful for environmental sustainability

From the perspective of the DID WG​​, this is the objection that felt most like a red herring. Not because this is not a legitimate concern about certain types of ​blockchains. But because the DID 1.0 specification has nothing to say about any specific blockchain, distributed ledger technology, distributed file system, or other form of verifiable data registry. In fact the term “verifiable data registry” did not even originate with the DID 1.0 specification—it was carried forward from the W3C Verifiable Credentials Data Model 1.0.

A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials.

In addition, Mozilla’s objection ignores the fact that: 1) there are entire families of popular DID methods that do not use any blockchain at all (e.g., did:key, did:peer, did:keri, did:web, did:ssb, did:orb), and 2) there are also entire families of DID methods use public permissioned ledgers or proof-of-stake blockchains that do not have these environmental concerns.

To be clear, Evernym cares very deeply about environmental sustainability. The DID methods we currently support are energy efficient. But to object to DIDs because some DID methods use proof-of-work blockchains is tantamount to objecting to electricity because some electricity is produced by coal-fired power plants.

If these objections do not hold up, then what are the real reasons Mozilla, Google, and Apple are opposed?

The one meeting the W3C management has held on this issue simply rehashed the original objections. So no one can say for sure what these vendors’ real motivations are. However, for anyone watching closely, the following facts appear relevant:

1. These three browser vendors currently control 87% of the market.
2. Through the CA/Browser Forum, they effectively control the list of root X.509 certificates included in the browser to enable all SSL/TLS encrypted connections (the lock in the browser address bar).
3. Google and Apple control two of the largest federated social login systems (“Login with…” buttons) that intermediate hundreds of millions of Web interactions every day—interactions that would become direct and private with DIDs.
4. Google and Apple also control the world’s two dominant mobile phone operating systems.
5. Google and Apple recently announced support in their respective proprietary mobile phone digital wallets for mobile driver’s licenses based on the ISO 18013-5 standard that assumes an X.509 certificate chain that is not compatible with the W3C Verifiable Credentials Data Model 1.0 open standard—and worse, allows tracking of everywhere you use your mobile driving license.
6. Excluding one-time income from litigation, 92% of Mozilla’s 2019 income came from its 2017 Google ad deal.
7. None of these three vendors have announced support for the W3C verifiable credential open standard.

But perhaps the most relevant fact of all is actually the one right in front of our noses: the browser has become the single biggest point of centralization on today’s Web. Take a second look at the quote we cited earlier from Mozilla Foundation’s 2017 Internet Health Report (this time with highlighting added)

The benefits of a decentralized Internet are eroding. When we concentrate our online activity on just a few social networks and messaging apps – as billions of us do – it narrows our experience of the Web to one where we are pointed only at content that appeals to our likes in search results and social media streams.

Now, turn this lens to look at the browser itself. Where are we really concentrating our Web activity? Who is really in a position to exert the greatest control over billions of Web users every day? And how real is their interest in shifting control away from that point of centralization—back into the hands (and keys) of the user?

How will this be resolved at the W3C?

Once a formal objection is lodged against a W3C Proposed Recommendation, the W3C process leaves it up to the W3C Director to make a final determination. The Director is currently exploring different avenues for how to resolve this issue. If in the end the DID Working Group is not satisfied with the Director’s decision, the court of last appeal is to request a democratic vote of all W3C members.

This is why it may ultimately come down to the question of how many W3C members agree with Tim Berners-Lee that “decentralization and tolerance are the life and breath of [the] Internet.” Do they support new technologies like DIDs and VCs that will help us “redecentralize” the Internet? Or is our only choice to accept increasing centralization and concentration of power?