Re: Ideal set of features and DID Methods?

ne 25. 1. 2026 v 23:06 odesílatel Manu Sporny <msporny@digitalbazaar.com>
napsal:

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

Hi All

I’d like to offer some perspective from the did:nostr side, as it was
mentioned and fits uniquely between the categories you outlined.

did:nostr offers two key "fully decentralized" qualities: self-certifying
identifiers (via secp256k1 public keys) and no DNS dependence. Resolution
works offline, with the public key alone sufficient to produce a valid DID
document. Additionally, the relay network provides decentralized
distribution for profiles and service endpoints, without relying on
centralized infrastructure. Nostr also has millions of users and a
well-funded ecosystem.

However, did:nostr intentionally omits features like CEL, oblivious
witnesses, and key recovery, placing it between did:key and a
fully-featured decentralized method. This lightweight approach aligns with
the goals of simplicity and ease of adoption, requiring no network calls,
no log traversal, and no infrastructure.

Should the fully-decentralized category accommodate both feature-complete
and lightweight methods? Just as did:web and did:webvh serve distinct
needs, perhaps a split could cater to varied use cases: one for
high-assurance (CEL-based) and another for low-infrastructure, rapid
adoption contexts.

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

Cheers
Melvin


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