RE: Ideal set of features and DID Methods?

DID Methods are essentially (and have always been) namespaces for entities/objects/subjects – Every Little Thing on the planet – each with some associated metadata. Why make a simple concept complicated?

Today, for example, there’s almost 400 million Internet domain names; growing at a rate 3.3-4.5% per year. On average, there’s 33,000 new domain names created every day. Zero complexity like you’re describing.

Michael Herman
Chief Digital Architect
Web 7.0 Foundation

From: Amir Hameed <amsaalegal@gmail.com>
Sent: Saturday, February 21, 2026 9:24 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: Steve Capell <steve.capell@gmail.com>; Manu Sporny <msporny@digitalbazaar.com>; Melvin Carvalho <melvincarvalho@gmail.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Ideal set of features and DID Methods?


Rather than standardising numerous DID methods, we could align on a baseline evaluation framework using shared parameters such as:

Technical dimensions:

• Network mode (offline, online, hybrid)

• Storage model (local, ledger, distributed)

• Latency / availability expectations



Non-technical dimensions:

• Privacy characteristics

• Environmental impact

• Interoperability profile

• Pricing / economic model

Variations and specialisations could continue to exist, but without each requiring formal standardisation. This may preserve innovation while reducing verifier and implementer burden.



Kind regards,

Amir Hameed Mir


On Sat, 21 Feb 2026 at 9:48 PM, Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>> wrote:

Dear Manu, dear Steven, all,



I would like to briefly echo Steven’s point.

From an implementer’s perspective, verifier burden is real. In a decentralised environment, verifiers cannot predict which DID method will be presented, which leads to growing resolver complexity, larger security review scope, and increasing interoperability friction.

Method diversity has enabled valuable experimentation, but without some degree of convergence, the ecosystem risks fragmentation and slower adoption.

The suggestion to align around a small number of architectural patterns and corresponding DID methods feels pragmatic.



Kind regards,

Amir Hameed Mir


On Sat, 21 Feb 2026 at 8:11 PM, Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
RE: I don’t know how many did methods is too many but my instinct says more that 3 is making life hard - and more than 5 means most implementers won’t bother

In the real world, there is going to be trillions of DID methods needed to name every type of Every Little Thing on the planet. We need to wake up to that. To say 3 is the right number is ridiculous. To say 5 is too many is equally short-sighted.

Here's an example (without further explanation) from one of our Web 7.0 DID method taxonomies...
[Image]


Michael Herman
Chief Digital Officer
Web 7.0 Foundation

Q: YOU'RE RIDING A HORSE FULL SPEED, THERE'S A GIRAFFE NEXT TO YOU, AND A LION CHASING YOU. WHAT DO YOU DO?
A: GET YOUR DRUNK A** OFF THE CAROUSEL.
________________________________
From: Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>>
Sent: Friday, February 20, 2026 5:30:45 PM
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Cc: Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>>; W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Ideal set of features and DID Methods?

dear Manu

> and on the other hand,
>
> there are MANY different types of vehicles in the world, and even more
> brands that specialize in aspects of each type of vehicle. Perhaps
> there should be as many different types of DID Methods in time?

I’m not 100% sure about that analogy.  Yes there are lots of specialised vehicles but we don’t all have to learn to drive every type.

In the decentralised world we envisage, the verifier doesn’t know what did method an issuer might have chosen and, to make sure he can verify whatever is presented or discovered, he needs to support them all.  By analogy, he needs to drive private vehicles, heavy trucks, forklifts, and combine harvesters.

I don’t know how many did methods is too many but my instinct says more that 3 is making life hard - and more than 5 means most implementers won’t bother

So, IMHO, this community needs to put aside their differences, let go of their pet preferences, and agree on a small number of architectural patterns and use cases (ie genuine reasons for difference) then standardise a small number of did methods - one for each pattern.  Or else we’ll still be arguing in our goldfish bowl while the ocean around us has moved on.

If and when a small number of standardised did methods see serious uptake, then there could be valid reasons to introduce some new highly specialised ones.  But doing that now is what I think is sometimes known as a “footgun”

Kind regards

Steven Capell
UN/CEFACT Vice-Chair
Mob: +61 410 437854

> On 21 Feb 2026, at 1:41 am, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
>
> On Fri, Feb 20, 2026 at 5:02 AM Melvin Carvalho
> <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>> wrote:
>> For more detail, here’s a longer piece on how did:nostr fits within this broader landscape, for those less familiar with it:
>>
>> https://melvin.me/public/articles/did-nostr.html

>
> FWIW, I found that web page really compelling Melvin. I suggest that
> those interested in decentralized DID Methods read it because if we
> were to just delete "nostr" from the entire page, I think it outlines
> a number of the ideal set of features we're looking for in a fully
> decentralized DID Method.
>
> I find myself internally conflicted about "How many DID Methods are
> enough?". On the one hand, "at least three -- generate from public
> key, Web/DNS-based, and fully decentralized"... and on the other hand,
> there are MANY different types of vehicles in the world, and even more
> brands that specialize in aspects of each type of vehicle. Perhaps
> there should be as many different types of DID Methods in time? Well,
> maybe not as many because there is only so much to differentiate DID
> Methods from each other... but certainly more than three, or possibly
> ten. Is twenty five too many? Fifty?
>
> More specifically, Melvin, I'm wondering if the "alsoKnownAs"
> equivalence could work in reverse. Where we add something to did:key,
> such as: did:key:...?aka=nostr, which would auto-generate the
> nostr-equivalent key. IOW, it would hint that you could do a nostr
> lookup that might work via a did:key?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/

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

>