There are problems with Decentralized ID (DID). Link to the W3C spec for DID. As a quick example go to https://resolver.identity.foundation/ and check out all the DID services available. If you want to start a new project and create a DID where would you go? Crazy Eh.
Some of these DID projects are no longer supported. For example the did:git spec was pulled from W3C. Instead the project moved to Authentic Data Provenance Log Format. So whats wrong with DID? Keep reading to find out.
Explosion of DID Domains
DID locators and DID ids are the same
The W3C spec for DID says the DID universal locator (urn) and the DID identifier are one and the same. This conflates identity and location. The problem is every organization wants to have their own method of creating ids, and that leads to separate domains, and that leads to separate locations. Every organization now has their own id generation methods, their own specs for meta data, and their own secure storage solutions. As a result a standard implementation of DID would need to support over 100 different DID specs! Expect this number to continue to increase.
No Respect for Reality
DID doesn't handle key replacements, key recovery, or revoking permissions
The hardest part of managing Public/Private Keys (PKI) is managing their lifecycle. PKI are zero knowledge proofs. You can encrypt one way and decrypt the other. When one end of the key changes the other end must change too. This nightmare of coordinating a key space should have been solved, but it has not been solved. If you want to switch out a key, DID doesn't help you. There should be a way to coordinate the switchover to the new key, and that might include some period where both old and new key sets are valid and used. Specifically the DID spec doesn't have a time dimension with no way to specify current, last, or next. Once you switch over to a new key there is no official support to read data encrypted with the old key. Stated more elegantly, I refer to the Authentic Data Spec.
In addition there really isn't good support for using multiple public key pairs. In an asynchronous, distributed system there may be some bad, corrupted nodes, and key generation might have a weakness. Therefore you may want to do polymorphic encryption or rotate through keys on each request. This requires have multiple key pairs in use, a requirement not directly supported in the spec. Having multiple keys is kind of supported, but how you aggregate and use those keys requires meta-data not included in the DID spec.
DIDs Are Incoherent
Too many different DID method specs, no path to evolve
This is a consequence of too many different DID specifications and no solution for allowing digital identities to evolve over time. Today you need to navigate 100+ DID domains and different specs. What happens when organization need to support a new feature, especially some new key aggregation or key sharing scheme, and their only option is a fork of their own DID schema. The users and clients of the DID spec will be left needed to navigate backwards/forwards compatibility themselves.
In summary I don't see DID spec taking off. DID is especially limited in the Web3 world of highly distributed, asynchronous computing, where key lifecycle, key sharing, and key aggregation are a must.
If you are interested in the Universal DID Resolver you can find the architecture on github here https://github.com/decentralized-identity/universal-resolver/blob/main/docs/dev-system.md
