RE: How/why "methods" became part of the original Decentralized Identifier conversations?

Joe, here is the intended wording regarding authority resolution: https://hyperonomy.com/2026/03/17/did7-authority-scoped-decentralized-identifier-scheme/#resolution-model


Michael

From: Joe Andrieu <joe@legreq.com>
Sent: Tuesday, March 17, 2026 9:45 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>; Drummond Reed <drummond.reed@gmail.com>; Manu Sporny (msporny@digitalbazaar.com) <msporny@digitalbazaar.com>; Markus Sabadello <markus@danubetech.com>; Daniel Hardman - Personal () <daniel.hardman@gmail.com>; public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Subject: Re: How/why "methods" became part of the original Decentralized Identifier conversations?

On Mon, Mar 16, 2026 at 11:36 PM Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Melvin, https://www.rfc-editor.org/rfc/rfc6920.html is very interesting. It suggests a backward compatible syntax for adding an Authority component to a DID 1.1 legacy identifier...


The DID authority component is the method name, although most of it don't think of it that way. We don't 100% map to the syntax in 3986 because we didn't care to repeat the :// but, literally the authority part of a DID method is the method name. That name tells you who the DID is secured in the VDR. It is literally and figuratively the authority that gets to decide how/where you go to get the raw state for DID document construction.

We intentionally do not rely on authority parts as defined for host-based interactions, as decentralized systems do not rely on a URL-reachable host.


did://authority/method:unique-item-id

Legacy DIDs (did:method:unique-item-id) can assume a mapping to a default authority value of: www.w3.org<http://www.w3.org>

did://www.w3.org/method:unique-item-id<http://www.w3.org/method:unique-item-id>
e.g. did://www.w3.org/key:hash<http://www.w3.org/key:hash>

Support for Authority is needed, for example, to create proper DID identities for things like context schema documents.

As respectfully as possible, this is not needed.

Your framing of authority is an unfortunate attempt to incorporate legacy centralized authority into a decentralized architecture. It's an understandable attempt to internalize how what we are doing is different or similar to current approaches like the Web. Unfortunately, it's moving the goal posts to an endline many of us oppose.

All you need for specifying schemas is a unique identifier, a URI, not a URL. You could use a URN or a DID. In practice, software SHOULD NOT attempt to dynamically respond to arbitrary schema. For security reasons, production software should only ingest data using formats that it already understands. Opening attachments without understanding the format is an analogous failing; its one of the biggest security flaws on the Internet that we regularly invite users to download and open arbitrary data objects. We don't want to continue that pattern into the DID ecosystem. Build for contexts and schemas that you understand. Error out on those you don't.

All that schema publishers need to do is to specify a unique identifier for the schema when they publish it. JSON-LD and RDF rely on URLs for those identifiers, which means they can also use DIDs for those identifiers.

To your question about methods as a component in the DID architecture, it is a necessary solution for allowing arbitrary VDRs. We knew at the beginning of the work that data substrates like Bitcoin and Ethereum would be great candidates for Verifiable Data Registries and the way that you engage each of these is dramatically different. So if we want a unified identity layer that allows for arbitrary back-end solutions, we need a way to specify *which* back end mechanism is to be used. did:key proved out the power of that approach when it enabled embedding the VDR literally in the DID itself.


This wasn't the purpose for my original question, but I like the outcome. Thank you. 🙂

Michael Herman
Chief Digital Officer
Web 7.0


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>>
Sent: Monday, March 16, 2026 11:49:06 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: Drummond Reed <drummond.reed@gmail.com<mailto:drummond.reed@gmail.com>>; Manu Sporny (msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>) <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Markus Sabadello <markus@danubetech.com<mailto:markus@danubetech.com>>; Daniel Hardman - Personal () <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>; public-credentials (public-credentials@w3.org<mailto:public-credentials@w3.org>) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: How/why "methods" became part of the original Decentralized Identifier conversations?



út 17. 3. 2026 v 3:03 odesílatel Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> napsal:

To: The Original DID People,

Who remembers how/why "methods" became part of the original Decentralized Identifier conversations?  What was the original catalyst/reason d’etre for having “methods”?

Why aren’t we all just using something simple and universal like: urn:<hash>?  …that is, one universal syntax plus multiple diverse back-end technology implementations?

Originally there was work using schemes like ni:// (RFC 6920) and related hash-based identifiers, which provide standardized content-addressable identifiers. I also built a proof of concept using ni:// for the web, which fed into later CG discussions.

DIDs emerged when the problem expanded beyond identifying content to identifying subjects with control: keys, rotation, and service endpoints. That shift introduced the need for method-specific resolution. At the same time, “decentralized” became a popular framing, including from a marketing perspective, which influenced the terminology and direction of the work.

From there, multiple use cases and stakeholders led to a proliferation of methods.
In the case of did:nostr, the aim is closer to the original hash-based simplicity, using the public key as a stable identifier, with did:nostr:<hash> as a compromise to interoperate with the DID ecosystem.




Michael

Web 7.0


--
Joe Andrieu
President
joe@legreq.com<mailto:joe@legreq.com>
+1(805)705-8651
________________________________
Legendary Requirements
https://legreq.com