Re: Ideal set of features and DID Methods?

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>
wrote:

> On Sat, Feb 21, 2026 at 11:24 AM Amir Hameed <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
+1(805)705-8651
------------------------------
Legendary Requirements
https://legreq.com