Re: distributed methods description - Was: Updating the DID method registry

Why not just list both?

There is no requirement for exclusivity.

On Fri, Jun 7, 2024, 9:15 PM Kevin Dean <kevin@legreq.com> wrote:

> Self-discoverable is likely not possible, as that would require a
> centrally defined (though not necessarily centrally controlled) discovery
> mechanism, which would bind every DID client to the technology underlying
> that mechanism.
>
>
>
> Because DIDs have widely varying interaction protocols (e.g., DNS and HTTP
> for did:web), any DID client that wants to support a given DID method has
> to know about it ahead of time. The DID Specification Registries is one way
> to publicize the DID method, but it could also be shared privately, e.g.,
> within an industry consortium whose members are interested in
> interoperability amongst themselves and not outside of the consortium.
>
>
>
> Self-descriptive is already possible to some degree in that the DID
> Specification Registries entry contains a link to the specification and the
> type of its verifiable data registry. However, as the specification is
> intended for human consumption and as the verifiable data registry is a
> freeform informational field, these are not very useful.
>
>
>
> DIDs are already fully sovereign in that the publication in the DID
> Specification Registries is entirely optional.
>
>
>
> *From: *Filip Kolarik <filip26@gmail.com>
> *Date: *Friday, June 7, 2024 at 12:40
> *To: *Phillip Shoemaker <phillip@identity.org>
> *Cc: *Kevin Dean <kevin@legreq.com>, public-did-wg@w3.org <
> public-did-wg@w3.org>
> *Subject: *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
>
>
>
>
>
>
>
>
>
>