Ideal set of features and DID Methods?

The recent discussion around did:cel, did:webvh, did:nostr, CEL,
Glogos, Dacument, and the various ways of creating a cryptographic
event log helped highlight that while we're converging on a set of
useful features for standardized DID Methods, we're also not quite
there yet from a community consensus standpoint on which features
should go into which DID Methods. There also seems to be consensus
that fragmentation beyond a minimal set of DID Methods that cover the
majority of use cases we have will harm adoption.

We also have a W3C DID Methods Charter proposal that lists three
general classes of DID Methods that the group will standardize:
ephemeral, web-based, and fully decentralized. I'll focus on the
latter two in this email as that is where much of the discussion over
the past several weeks has focused; the goal, again, being to achieve
the maximum level of convergence. I am also going to try to not talk
about the desired DID Methods by name, but rather their feature set
(also known as DID Traits).

To be clear, these are only my opinions on which feature sets are
desired, based on what I've seen our customers and others deploying
DIDs and VCs seem to be comfortable with, and I'm sure others might
disagree with some or all of the groupings below. What I'm hoping to
tease out is where the disagreement is, specifically, and then narrow
into the "why". Disagreements often occur when people have different
sets of requirements, and if that's the case, there can be a good
argument there for different solutions. I don't think "fragmentation"
is a bad thing if there are different requirements... it's only bad if
we have the same requirements but we decided to go different ways.

So, with that as a foundation, let's get started... what are the ideal
features for a few DID Methods we plan to standardize?

General Design Goals
------------------------------

Minimalism - a DID Method should have a tight security and feature
profile. This makes it easier to implement and understand.

Easy to Bootstrap and scale - a DID Method should be easy to bootstrap
in a very small community, but should be able to scale globally
without requiring significant investment in new infrastructure.

Low total cost of operation - a DID Method should have a low cost of
operation such that it is not a burden to maintain for its intended
target population.

did:DNS-BASED
----------------------

One desired DID Method is one that is based on the domain name system.

The DID Method publishes a static DID Document via a standard HTTP
server in a standard location. did:web is an example of such a DID
Method.

That said, there are some other features that would be useful for this
DID Method, such as:

* A link to cryptographic event log from within the DID Document
(service endpoint)
* The cryptographic event log is obliviously witnessed
* The cryptographic event log is fully self-contained (ideally, no
external links/dependencies)
* The latest hash of the DID Document is published in a DNS TXT record

The CEL would allow you to query the method throughout time and would
give verifiers further assurance that the domain owner hasn't done
anything funny with the DID Document over time.
Yes, the cryptographic event log would have to be optional because we
are dealing with a legacy DID Method and it would only be enforced by
verifiers that require it, such as some large organizations.

The hash of the DID Document in DNS TXT might NOT be optional since
it's something that most people that have deployed did:web are capable
of doing easily, and it protects against web server compromises.

My hope was that we were going to add those features, and only those
features, to did:web to achieve a purely DNS-based DID Method.

The target population that would use this DID Method is any individual
or organization that desires their identity to be tied to a domain
name (corporations, governments, etc.).

did:FULLY-DECENTRALIZED
----------------------------------------

Another desired DID Method is one that is completely independent of
the domain name system. The features for this DID Method are:

* No dependency on DNS for the identifier, log, or witnesses
* The identifier is self-certifying
* The DID Document is constructed from a cryptographic event log
* The cryptographic event log uses oblivious witnesses
* The cryptographic event log can be retrieved from "dumb" storage servers
* Freezing/forking is prevented through cryptographic log heartbeats
* Key compromise is prevented through a recovery key or key pre-rotation

None of those features are optional, every DID of this type must use
those features.

The target population that would use this DID Method is the general
public -- individuals with mobile phones and computers that are
capable of creating and using these DIDs directly, or through service
providers that offer these types of DIDs for a cost that is barely
noticeable to an individual.

Other Non-Critical Features
-------------------------------------

I expect that there are features not listed above that others feel are
critical. For example, I know that "domain portability" (the ability
to change domains associated with a did:webvh) is a feature that's
desired by some in that community. I do agree that there is a use case
there, but don't think the security trade-off is worth it (having to
worry about the fact that the underlying domain can change throughout
time and being mandated to implement that feature).

But, maybe I missed other features -- is there something that you feel
is a hard requirement in one of the classes above, or an entirely new
class of DID Method that isn't listed above?

Other Desired Outcomes
---------------------------------

There are other outcomes that are desired as well.

It would be nice if the log format and the witnessing ecosystem was
decoupled from and re-usable in other use cases -- namely, UNTP-like
bill of lading / supply chain use cases, provable/portable Social Web
ActivityPub accounts/messages, and other "historical record" use
cases. If we do this right, we get a fully decentralized DID Method
AND a generalized cryptographic event log technology out of the
standardization process.

It would also be nice if did:plc ended up using the
fully-decentralized method as well.

Are there other desired outcomes?

-----------------

I hope the above helps further refine where I thought we were going
with the Web-based and Fully Decenralized DID Methods listed in the
DID Methods WG charter.

So, with all that said, where do we disagree on the requirements?
What's missing? What goes too far? Or, are those the requirements and
we agree at a macro level and the only thing left is to whittle away
at the details?

-- manu

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

Received on Sunday, 25 January 2026 22:03:43 UTC