RE: Ideal set of features and DID Methods?

RE: for independent developers and individual end users, the key question isn’t whether infrastructure exists, but whether using it is optional, whether there is a choice. e.g., one might not want to rely on a particular blockchain, or even on DNS. Mandatory reliance on external infrastructure means losing control, even in “decentralized” systems.

Use a software model that enables a developer, on the spot, while coding his/her app, to model any DID method they need (and as many as they want to) …and make it as easy as defining a new database table or an object class for a new data store.

For example,

[cid:image001.jpg@01DCA4CD.97253040]

From: Filip Kolarik <filip26@gmail.com>
Sent: Monday, February 23, 2026 1:34 PM
To: W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: Ideal set of features and DID Methods?

Hi,
for independent developers and individual end users, the key question isn’t whether infrastructure exists, but whether using it is optional, whether there is a choice. e.g., one might not want to rely on a particular blockchain, or even on DNS. Mandatory reliance on external infrastructure means losing control, even in “decentralized” systems. Public blockchains don’t fully solve this either, since economic and governance power can still concentrate.

One way to address this in DID methods is to ensure that at least one method allows identifiers to work independently, giving users and developers a real choice. This preserves autonomy while institutional users can still adopt more rigid approaches or use methods targeting specific infrastructures.

I would love to see some clear criteria list, there are a lot of great proposals in this thread, and it would be great to minimize fragmentation, but I’m not sure how to get there except by seeing DIDs in real use and observing which approaches gain traction.

That said, ensuring that at least one method is fully independent seems like a minimal baseline for standardization and perhaps a starting point for specialization.

Best regards,
Filip
https://www.linkedin.com/in/filipkolarik/


On Mon, Feb 23, 2026 at 7:48 PM Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
Joe,

You make a strong argument but seem to ignore people as individuals. I hardly know where to begin.

AI, social media, democracy, and human rights are domains of digital transformation that require their own rubric rooted in biometrics and human accountability. Technology is obviously already powerful enough to drive language, culture, and medical science.

I fear that W3C, CCG, and maybe SDOs in general are, as they say: "Yesterday's technology, solving today's problems, tomorrow."

Adrian

On Mon, Feb 23, 2026 at 1:03 PM Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>> wrote:
Manu,

I'm bummed you didn't reference the W3C work in this area, where we developed a common set of criteria for evaluating DID methods, the DID Method Rubric.

https://w3.org/TR/did-rubric


You can see three full evaluations using that approach at https://didevaluations.com <https://didevaluations.com>
I also find it curious that so many believe a limited number of DID methods is a good idea. As a decentralized technology, DIDs reject the idea that any particular entity has the authority to decide which DID methods are good or not. Each party--whether individual, organization, or nation-state gets to pick the ones that meet their needs. Telling someone else that their preferred DID method isn't allowed is an anti-pattern. Why would imagine that its useful for someone to bless the "three to five" best approches? We didn't need that for other internet technologies (FTP is not invalidated by HTTP; telnet is not invalidated by SSH) so why are people pushing for a closed set of methods?

Yes, each jurisdiction will have its opinions, pass laws and regulations, and require that legal entities within it use technology of a particular nature. But the underlying technology is jurisdiction independent, and we should keep it that way. Just as IP datagrams operate independently of jurisdiction, so do DIDs and DID documents. As such, every jurisdiction (and there are ~90,000 independent lawful jurisdictions in the US alone) has the moral and legal authority to impose its own restrictions on whichever DID methods it wants to integrate with official services. This is only possible if different DID methods *can* exist to satisfy that state's requirements. Note that it is not yet clear if ANY DID methods satisfy Utah's new SEDI requirements. So why the rush to reduce? It's premature.

While I agree there is likely to emerge a handful of methods that gather the most use and come to dominate the market, (see BCG's Rule of Three and Four https://www.bcg.com/publications/1976/business-unit-strategy-growth-rule-three-four) There is no point at which the technology needs restriction as it is a naturally limiting phenomenon. Restrictions will only stifle innovation without actually solving the complexity of the ecosystem.

The fact is, not a single DID method today is quantum-resistant.

Think about that.

Most likely NONE of the 225+ DID methods in existence today are likely to be in use next decade. This decade will almost certainly usher in a new category of cryptographic primitives that any surviving DID method is going to have to adopt in some form.

So, I'd argue that NONE of the current DID methods are suitable for long term adoption and deployment. Rather than locking down a particular cryptographic approach, jurisdictions should standardize the interfaces and formats that will enable any particular cryptosuite to fit into the architecture. DIDs do this nicely through verification methods--separating the VDR state from the cryptographic primitives enabled by DIDs--but we have explicitly avoided standardizing VDRs to enable them to continue innovating. The fact is, many people have strong opinions about different technological approaches, such as proof-of-work and proof-of-stake. The brilliance of DIDs is that we can leverage these cutting-edge approaches without becoming beholden to any one of them. Contrast this to the deeply prescriptive EUDI wallet approach that will, necessarily, be deprecated within the decade.

Beyond the necessary future technical innovations, DIDs also represent independent namespaces. I fully expect we will see millions if not thousands of DID methods in practice, as corporations realize they can define their own DID method and achieve a trivial point of quality assurance by knowing by trivial observation which DID methods are "their" DID methods. Why wouldn't Ford want to use a did:ford namespace to identify all of its components in its supply chain?

In the long term, DID methods will likely emerge that enable arbitrary namespaces while leveraging the same VDR interfaces with different root authorities. There is nothing keeping Ford from running its own EVM and its own version of did:eth and calling it did:ford. The only trick is for did:ford is to explain to the world how you map the did:eth endpoints and root authority to did:ford. However, I'm certain Ford has enough clout to literally require their supply chain to adopt its id approach, should it choose to do so.

It's clear to me that since DID methods don't need to ask anyone for permission, that many many people, corporations, and governments will choose to implement their own innovative DID methods, seeking a unique advantage not yet satisfied by other services.

The question isn't whether or not there will be lots of DID methods. The question is how do we reduce the overhead from the differences between those methods.

DID Resolution is the group's response to that, providing an HTTPS interface that each conformant DID Method implements, enabling any client to use the same interface to indirectly query any supported VDR using any resolver trusted for that VDR.

The question of how to reduce the myriad of DID methods to a handful is as ridiculous as asking if we should limit the web to only one or two website providers, just because there are natural monopolies in search, social networking, AI, or whatever niche you want to claim is important. Unfortunately, that merely imagines repeating the walled gardens and silos of the past.

I'd rather keep things open.

-j

On Sun, Feb 22, 2026 at 2:16 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
On Sat, Feb 21, 2026 at 11:24 AM Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>> wrote:
> Rather than standardising numerous DID methods, we could align on a baseline evaluation framework using shared parameters

We went through a version of that exercise two years ago:

https://identity.foundation/did-traits/#comparison-of-did-methods


... which led to this DID Methods Charter proposal:

https://w3c.github.io/did-methods-wg-charter/2025/did-methods-wg.html#deliverables


... which is currently waiting on a W3C Member to volunteer to
co-Chair the group.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/



--
Joe Andrieu
President
joe@legreq.com<mailto:joe@legreq.com>
+1(805)705-8651
________________________________
Legendary Requirements
https://legreq.com