Something that should be a bit of a warning flag is that I have two decades of identity-related experience but I still have no idea what DID <i>even is</i>.<p>For reference, I've worked with three vendors' implementations of LDAP, several versions of SAML, OAuth, JWT, Okta, Azure Active Directory, etc, etc... I've even deployed Smart Card authentication in the field several times.<p>I literally have no idea, not a <i>clue</i> what DID is supposed to be in a practical sense, <i>despite</i> having read a significant volume of material on a subject.<p>Like, okay, it's "identity"... somehow? How? What? Where?<p>The documentation is impenetrable buzzword-compliant gibberish that makes SAML's documentation look like crystal-clear poetry in comparison.
"Mozilla:<p><pre><code> The DID Core spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ methods.
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.
The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability.
[W]e believe the DID specification may not be fixable (MUST NOT become a Recommendation)."
</code></pre>
"The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods. The objections are overruled."
A standard flexible enough where you can do literally anything is usually a bad standard. The point of standards is to write up some small-ish base that everyone can agree on so that people can talk to each other. A standard containing everything where each implementation implements a different incompatible subset, is a failure.
I've been following DID for a while and I really don't think its the right approach. The voices of concern from Mozilla and Google are spot on: the DID specs expect everyone to coordinate on finding the right structure for different types of data but the real world is messy and no "correct" structure exists.<p>DID in my opinion is unlikely to succeed. Real builders don't use it, because it is cumbersome and requires agreeing with (a step up from collaborating with) other opinionated developers who have different specific use cases in mind.
As a user, I am very happy that W3C has overruled the objections. As a developer, it may a bit of a PITA, albeit a necessary one.<p>For Google, it makes sense for them to request at least some "standard" methods. If the number of DID methods is sufficiently large, Google won't be able to use their network effect to dominate any of them. Surprise, that's the aim of the spec.<p>For Mozilla, it makes sense to support a small set of DIDs, their resources are not infinite.<p>As a user, I want to use the DID method that works for ME. For example, <a href="https://en.wikipedia.org/wiki/BankID" rel="nofollow">https://en.wikipedia.org/wiki/BankID</a> is used universally in Scandinavia and I would not see why would anyone use DID for identifiers of "real world" things if a govenrment-accepted mechanism cannot be used (eg "did:bankid:*") for signing those identifiers etc. Because I <i>already use</i> BankID for all important authn things in my daily life. In Estonia, ID cards are used for legally binding signatures since forever, I can totally see how they might want to use that to sign their DIDs: <a href="https://en.wikipedia.org/wiki/Digital_signature_in_Estonia" rel="nofollow">https://en.wikipedia.org/wiki/Digital_signature_in_Estonia</a><p>Regarding Web 3.0 garbage in the registry: just ignore it, nobody is going to use it seriously. Those entries are just marketing by those projects. If it was up to me, I would split the registry into two sections: registries with significant stakeholder backing (BankID and the likes) and everyone else (so that you can ignore them).
So if Google, Apple, and Mozilla all opposed this what are the chances it ever actually becomes useful?<p>Just because something was given the stamp of approval by the W3C doesn’t mean they actually have to implement it.
I may be suffering from a deficiency of reading comprehension. Can someone please explain to me in plain terms what a DID is and what it's for? It's a "globally unique persistent identifier that does not require a centralized registration authority"[1] - great, an identifier for <i>what</i> exactly? Is it just supposed to be an identifier for <i>anything at all</i>? Local and remote resources? People? Pokemon cards?<p>[1] <a href="https://www.w3.org/TR/did-core/#terminology" rel="nofollow">https://www.w3.org/TR/did-core/#terminology</a>
Decentralization is a legitimate and important topic that is confused by the hype-driven blockchain bandwagon: a flock of a thousand red herrings. When searching for actual foundations to build a DApp on, you typically find libraries published by Crypto-startup-of-the-Week LTD. Why should I trust them?<p>Regardless of the legitimate issues raised by objectors, I am happy to have some W3C standard to build on. Methods may be underdefined, but as consensus is reached I could pivot to it. And even if no consensus is ever reached, I can at least try and reach consensus with the communities I care about.<p>Coupled with ActivityPub [1], this feels like a much safer foundation for building a DApp than anything else I have been able to find. The only thing that confuses me is the relationship between DID [2] and the Verifiable Credentials [3]. Can anybody explain how they relate, and how they should be used together (or not)?<p>[1] <a href="https://www.w3.org/TR/activitypub/" rel="nofollow">https://www.w3.org/TR/activitypub/</a><p>[2] <a href="https://w3c.github.io/did-core/" rel="nofollow">https://w3c.github.io/did-core/</a><p>[3] <a href="https://www.w3.org/TR/vc-data-model/" rel="nofollow">https://www.w3.org/TR/vc-data-model/</a>
The notion of decentralized identity has been an enchanting vision since Christopher Allen first articulated it in 2016. Since then, DID spec has been around for years in draft form, and there are at least a dozen vendors and/or projects producing DID-compatible or DID-relevant technology.<p>Of course, these different packages are not (yet) compatible, but that's not the problem. The problem is that, after a good 4 or 5 years, it's hard to find a single project that uses DID protocols at scale in a worthwhile and effective manner.<p>There are tons of pilot projects and PoCs. A few go into production at limited scale, languish for a while, and then do a slow fade.<p>I agree with other commenters that DID does not seem to address real-world pain points. I also think that the spec appears murky, abstract, overly complex and hard for developers to work with. I have tried to use DID in projects a couple of times, and found myself sidelining or pushing it into a corner of the system, because it did not seem to serve a useful purpose.<p>There's a recent alternative to DID, which is narrower in scope and more pragmatic. That is "login with Metamask" or "sign-in with Ethereum" (or something similar in the case of other blockchain platforms).
Wow, the person who wrote that text has some talent for bureaucratese. It's comparatively rare to see that in English, since the language tends toward clear verbs and the active voice. But here I had to re-read a bunch of sentences to figure out what refers to what, while wondering if I need to take a coffee break. I would say that the author probably moonlights as a writer for NYT or something—if the dryness of the document wasn't quite outstanding, beyond what is still considered fit for consumption.
The objections by Mozilla & Google make sense if you assume by denying their requests that the methods should be define prior to moving forward, but to me, the core as defined is more than enough to move forward and the next step is to define the methods.<p>Worst case, the core is flawed and the specs are revised to align to what has been learned flushing out the methods or it is abandoned for whatever reason. Mozilla & Google saying they object based on everything not being defined sounds like the opposite of progress to me.<p>The core already lays out specs for methods and clearly they’re good enough for other workgroups to already be moving forward refining methods for specific use cases. Here’s an example:<p><a href="https://identity.foundation/peer-did-method-spec/" rel="nofollow">https://identity.foundation/peer-did-method-spec/</a><p>If there’s an significant issue with moving forward, I am not understanding it.
There is validity in the W3C position as well as the objections raised by the various parties. However, the respective positions of the parties are on different axes.<p>It is helpful to look at the DID-core as the WHAT with the methods of the DID to specify HOW.<p>The methods set is left open by W3C (i.e., an item in the method registry) and rightfully so. The objectors want it to be a defined, possibly closed set before it moves to Recommendation track.<p>To see why this makes sense, suppose I am a service provider and I need identity services to authenticate and authorize. If I define the data elements that constitute identity (eg: name+phone or emailaddr or nationalid etc.,) in my application. The then DID allows the server and the client to agree on identity by exchanging the DID document and verifying the claims in it using the methods in the DID document.<p>If we need flexibility in the set of dataelements that constitute identity, then the methods MUST be kept open. The method is only an interface contract that specifies how to validate a specific DID.<p>Suppose there is a method that relies on nationalid then any future service that also supports the method should be able to interoperate. Whether a service implements that interface or not is a choice that the service can make.<p>By decoupling the WHAT from the HOW, I could have a fully decentralized identity system (perhaps with services provided by the OS or apps) and sharing only zero-knowledge-proofs with the counterparties without sharing underlying information (or only information necessary for the transaction).<p>I think this makes sense and is a step in the right direction.
Caveat: I know several people involved in the DID standards development and consider them friends.<p>Decentralized Identifiers (DIDs) are important because a decentralized global network with fully decentralized versions of things like Facebook, with users controlling their own data, may not be possible without them.<p>There is a lot in the DID specs. They are perhaps best viewed as an abstraction layer for decentralized authentication, authorization, rights management, and messaging. There are many ways of implementing these standards, and this is accomplished by allowing many different DID methods. Some methods, like 'peer', do not use public sources of truth like blockchains. Many of the various methods use some given blockchain as a public source of truth. Some use a distributed file system like IPFS. The abstraction in the DID specs should allow all of these methods to interoperate (e.g., have a IPFS DID document with a btcr controller, btcr being one of several DID methods using the Bitcoin blockchain).<p>DID methods are not a wild west however, despite the picture painted by some. There are registries for recognized DID methods that impose controls on DID method specs before they can be listed in the registry [1].<p>Also, I think any DID support will likely require a plugin mechanism. The app implements the DID abstraction layer and DID common functionality, then offloads DID method specific functionality to an available plugin for that method or signals an error if no plugin for that method is available. It is ironic to me that Mozilla raised the objection here, because in my mind the plugin system that made people aware of plugins is the Firefox plugin system.<p>[1] <a href="https://www.w3.org/TR/did-spec-registries/" rel="nofollow">https://www.w3.org/TR/did-spec-registries/</a>
My take is that the Director of the DID working group is tired and wants this to be over. They want to enjoy a few months break and some future Working Group can deal with the problems.<p>We've all been there. Coding is complete, but QA comes back with some fundamental issue that might require us to redo the design of the program. We'd rather not.<p>Winners ship.
My TLDR. DID is already a registered URI scheme [1]. The method on a DID [2] is more or less a URI sub-scheme / protocol. Its for the blockchain / web3 crowd for something like the definition of a NFT. Most of their startups will shut down in a year or two anyways. Won't really matter. No one is going to manually type these in, or understand them by reading them. I'd agree that there really isn't a point of declaring it a standard as the DID scheme is already registered.<p>[1] <a href="https://www.iana.org/assignments/uri-schemes/prov/did" rel="nofollow">https://www.iana.org/assignments/uri-schemes/prov/did</a><p>[2] <a href="https://www.w3.org/TR/did-core/#methods" rel="nofollow">https://www.w3.org/TR/did-core/#methods</a>
An "Explain Like I'm Five" of what DID is (for those who don't know, like me):<p><i>"Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party.</i>"<p><a href="https://www.w3.org/TR/did-core/" rel="nofollow">https://www.w3.org/TR/did-core/</a>
Seems it's going to flop as hard as the Semantic Web and RDF, if not harder, given Google and Mozilla are not going to implement it, and Apple never implements anything anyway,
From Mozilla's objection: "The lack of restrictions on the registry are allowing methods ... which are actively globally harmful to sustainability."<p>That seems to me like Mozilla trying to push their social justice goals down into tech standards now.