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> 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
>
> did://www.w3.org/method:unique-item-id
> e.g. did://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>
> *Sent:* Monday, March 16, 2026 11:49:06 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* 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?
>
>
>
> út 17. 3. 2026 v 3:03 odesílatel Michael Herman (Trusted Digital Web) <
> 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
+1(805)705-8651
------------------------------
Legendary Requirements
https://legreq.com