Re: Ideal set of features and DID Methods?

On Mon, Feb 23, 2026 at 1:01 PM Joe Andrieu <joe@legreq.com> wrote:
> 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.

What if failing to mention that was just a ruse to draw out your
opinions on DID Methods, Joe? :P

If only I were that clever... my apologies, Joe -- bumming you out is
among the list of things I don't want to do to you. I thought I had
copied and pasted the Rubric as well, but looks like I failed to do
so.

That said, I definitely forgot to mention the Rubric Podcast for those
that are unaware of it and want to deep dive into some of these
rubrics / features / traits:

https://rubric.cc/home-episode-slider/

> why are people pushing for a closed set of methods?

Well, that's certainly not my intention (though I can understand how
it can come across as that). This is more about prioritizing -- we
only have limited cycles, can we get behind a small subset to start...
and then go from there?

> Note that it is not yet clear if ANY DID methods satisfy Utah's new SEDI requirements.

Oh, interesting. What parts of SEDI do you think are difficult to
address with DIDs as they exist today?

> The fact is, not a single DID method today is quantum-resistant.
> Most likely NONE of the 225+ DID methods in existence today are likely to be in use next decade.

I think there are ways for things like did:cel and did:webvh to
survive the transition intact. I believe, though I haven't thought
deeply about this, that all you need is a log format that links the
events together using cryptographic hashes and post-quantum witnessing
to happen before the pre-quantum cryptocalypse. If you have those two
things, you can transition (without changing your DID) from
pre-quantum keys to post-quantum keys.

It's true that none of that is in place today for any DID Method (that
I know of).

> I'd argue that NONE of the current DID methods are suitable for long term adoption

I don't think this argument holds, see above.

> Contrast this to the deeply prescriptive EUDI wallet approach that will, necessarily, be deprecated within the decade.

On this, we agree. :)

> I fully expect we will see millions if not thousands of DID methods in practice

I do think that we're making it easy to have "brandable" DIDs, for
better or worse. That is, DID Methods that just re-use common traits,
data structures, and APIs that have common implementations. I don't
know how useful that is, other than to marketing departments (who, by
the way, are the financial engine that funds vast swaths of the
operation of the Web currently).

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

Yes, and I think the thing that SteveC might be missing is that (in
theory) a DID Method driver only needs to be written once for someone
to support the DID Method. Once I, as a verifier, decide that I want
to accept DIDs from some place new, turning on that capability is as
simple as checking a box in my DID Resolver software (yes, yes, we're
not there in a general sense yet, but the Universal Resolver is a case
in point, here). Markus' DID Resolver design is quite a powerful one
that I expect others to follow.

> The question of how to reduce the myriad of DID methods to a handful is as ridiculous as

I have a different take here:

There are people in the European Union that have successfully argued
against DIDs because we haven't produced a standardized one yet. For
better or worse, that's how the Europeans run things -- if there ain't
a standard, they're not going to write it into their regulation. So,
I'm interested in focusing our energies to give them at least one
standardized DID Method that is useful to Europeans (to start) and
perhaps they open the aperture in time. I know it's a slippery slope,
but this is more around priorities and focusing our limited energy for
maximum societal gain vs. trying to constrain innovation.

DID Methods don't need permission to innovate -- we all designed it to
be so. We couldn't contain it if we tried (a good thing). What we are
trying to do is to remove some of these roadblocks to adoption using
the limited focus and time that we have. If we are successful, there
will be many, for some definition of "many", DID Methods in real use.
My money is on "hundreds", but I'm as uncertain of that number as I am
the temperature on Tuesday of next year.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Tuesday, 24 February 2026 22:55:33 UTC