Re: Mozilla Formally Objects to DID Core

Tantek Çelik objects, in part, because:
>
>  * Centralized methods allowed, in contradiction to WG & spec goals & name.
> As Google noted, some methods in the registry such as did:ccp use a single
> server, and thus any interop with such a method would bias toward
> centralization, and likely be literally centralized rather than
> decentralized. Centralization might be at an architectural level, or – at
> a minimum – a service level, even if multiple “implementations”
> claimed to support it.


I have shared a similar concern since my first reading of the spec. It
seems odd to define methods for "decentralized identifiers" which are, by
definition, to have only one implementation. The problem I see, which is
perhaps the same problem that concerns Tantek, is that a method
specification may specify not only how to work with the DID but also the
specific Internet address of the implementation. For instance, the did:ccp
method specifies not only Read, Update, Revoke, etc., but it also states
that https://did.baidu.com/ is the one and only permitted implementation of
the method. Thus, if I were to implement a method identical to that
specified by did:ccp, but on my own machines, I would have to register a
new method, perhaps: did:bobwyman-ccp. This does not seem reasonable.

Would Tantek have objected less if the DID specified both the implementer
and the method? For instance, if DIDs used tag: URIs (RFC 4151
<http://www.faqs.org/rfcs/rfc4151.html>), but with an added "method" field,
they would provide global identifiers which are "unique across space and
time," but would not bake centralization into the system. Given such a DID
structure, a DID like:

> did:ccp:ceNobbK6Me9F5zwyE3MKY88QZLw

would have been written as:

> tag:did.baidu.com,2020:did:ccp:ceNobbK6Me9F5zwyE3MKY88QZLw

And, given that the ccp method was published, then I might implement
support for issuing DID's using that method. One of my DIDs might look like:

> tag:foo.wyman.us,2020-09-02:did:ccp:ceNobbK6Me9F5zwyE3MKY88QZLw


One nice benefit of adopting something like tag: URIs is that the central
registry would not need to register methods which were intended to have
only a single implementation. The central registry could provide a generic
"private" method and then define a process for discovering a description of
the method. So, given a DID like:

> tag:did.baidu.com,2020:did:private:ceNobbK6Me9F5zwyE3MKY88QZLw

I might retrieve the appropriate private method specification from:

> https://did.baidu.com/.well-known/did-method/private


Alternatively, the DID spec could say that all methods not defined in the
registry should have discoverable implementation-specific descriptions,
thus, the method for working with:

> tag:did.baidu.com,2020:did:randomV1.0:ceNobbK6Me9F5zwyE3MKY88QZLw

would be described in:

> https://did.baidu.com/.well-known/did-method/randomV1.0


I suspect that using such tag:-derived DIDs would result in many fewer
registered DID methods and probably a great deal more use of common DID
methods.

Would Tantek have objected less if DIDs were more like what I've sketched
above?

bob wyman




On Wed, Sep 1, 2021 at 10:14 PM Orie Steele <orie@transmute.industries>
wrote:

> https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html
>
> The objection mentions comments from Google and Microsoft, but does not
> link directly to them.
>
> Does anyone have a direct link to the comments from Google and Microsoft?
>
> OS
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>