distributed methods description - Was: Updating the DID method registry

Hi,
an off-topic question, I wonder if there could be a way to make methods
somehow self-discoverable, self-descriptive, eliminating the need for a
registry. Is it possible to make DIDs fully sovereign with no need for an
authority?

Thanks,
Filip

On Fri, Jun 7, 2024 at 6:31 PM Phillip Shoemaker <phillip@identity.org>
wrote:

> Thanks Kevin, I completely agree. And if the DID method was deployed and
> maintained, I wouldn’t be asking this question. We are working with BNB on
> this and cannot deploy as is.
> - Never deployed
> - Nothing to maintain
> - Company is non-responsive and their GitHub is not touched in years
>
>
>    - No deployment -> Deprecate immediately
>
>
> How do we get to the above?
>
>
> - - -
> Phillip Shoemaker
> Executive Director, Identity
> E: phillip@identity.org
> M: 1.408.835.8444
>
>
>
> On Jun 7, 2024, at 6:52 AM, Kevin Dean <kevin@legreq.com> wrote:
>
> Name collision is a problem for DID methods. As with domain names, it’s a
> case of “first one in wins”. Unlike domain names, though, where failure to
> renew registration eventually returns the name to the free pool, there’s no
> mechanism for deprecation in the DID registry.
>
> Even if there were, it’s problematic, because DIDs can outlast support for
> their underlying methods. Suppose someone needs to query a DID sometime in
> the future in order to validate some present-day action, and they have
> previously had no exposure to the DID. The logical place to start would be
> the DID registry, but if the DID registry has a different, unrelated
> specification linked to the DID method name, they will be unable to perform
> the validation. Arguably, they could go through the GitHub history to
> determine what version of the JSON file applied at the time of the
> present-day action they’re validating, but that introduces a new,
> non-standard level of indirection to DID processing.
>
> This is analogous to sending an email to a reallocated domain: it might
> get through, but it certainly won’t be to the intended recipient.
>
> In my opinion, DID method name deprecation should be taken up in the new
> working group. I’ve been through something similar in another domain, and
> it led to a tiered approach:
>
>
>    - No deployment -> Deprecate immediately
>    - Limited deployment (e.g., for proof of concept) -> Deprecate after
>    well-defined period (e.g., one year)
>    - Production deployment -> Never deprecate
>
> ------------------------------
> *From:* Phillip Shoemaker <phillip@identity.org>
> *Sent:* Thursday, June 6, 2024 7:52:19 PM
> *To:* public-did-wg@w3.org <public-did-wg@w3.org>
> *Subject:* Updating the DID method registry
>
> How does one go about getting the DID method registry updated?
>
> We wish to deploy a DID method on BNB, but a company named Ontology has
> already registered it a few years ago, and still have not deployed a
> method. Additionally, they did not list their website nor an email address.
> I’ve tried for months to contact the company to no avail.
>
> What is the process to update the registry?
>
> Thank you.
>
> - - -
> Phillip Shoemaker
> Executive Director, Identity
> E: phillip@identity.org
> M: 1.408.835.8444
>
>
>
>
>