W3C says no to Google and Mozilla on decentralized identity

The DID (Decentralized Identifiers) specification will move to the W3C recommendation stage in early August, despite opposition from Google and Mozilla.

When a technical standard is established, should the methods on which it can be based be standardised, in parallel? Google and Mozilla, among others, have advanced the argument against the W3C… without success.

The context ? Development of the DID (Decentralized Identifiers) specification. At the beginning of August, this will become a recommendation, marking the final stage of its ratification process. Thus the W3C decided last week, dismissing at the same time the objections of Google and Mozilla.

The specification paves the way for “decentralized” identities. Which, broadly, will have the following characteristics:

– Independent of any central transmitter
– Persistent (no functional dependency on any organization)
– Cryptographically authenticated
– Associated with metadata

These identities take the form of a URI to which a method is applied to obtain a “document”. This contains information that the owner of the identity can choose to communicate selectively to the services to which he wishes to connect.

The specification does not presuppose any technology. It leaves the door open to DLTs, decentralized file systems, distributed databases, P2P networks, etc.

Voices – including those of Google and Mozilla – have been raised on this subject. With in particular a fear: that certain methods, in particular those based on a single server, tend towards centralization.

More generally, critics of the specification point to its lack of interoperability in practice. In absolute terms, the W3C lists more than 50 methods declared to be compliant… but effectively devoid of implementations. A volume which, moreover, encourages the development of additional methods rather than clinging to one of those listed, in the opinion of Microsoft.

The W3C learns from the past

What do Mozilla et al advise? Proceed as when we had standardized the URLs or the img tag. In the first case, a range of methods had been standardized in parallel. In the second, the image formats used existed a priori. And to add: impossible to make an impact on a specification without doing the same on the methods it will use.

Another element pointed out: the cost, particularly environmental, of methods involving consensus mechanisms of the type proof-of-work.

The reasoning of the W3C can be summarized as follows:

– The discussions showed that it would be more complicated to agree on specific methods than on a common basis

– The number of methods deemed compliant proves the relevance of this base

– History has shown it with many Internet standards: initiating work leads to improvements

– Going forward by adopting a recommendation will motivate developers to start this work

– Questions about decentralization and its costs are not enough to offset the benefit of moving to the recommendation stage

Illustration photo © bluebay – Shutterstock

Leave a Comment