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