W3C home > Mailing lists > Public > public-credentials@w3.org > September 2021

Re: Mozilla Formally Objects to DID Core

From: Bob Wyman <bob@wyman.us>
Date: Fri, 3 Sep 2021 00:07:40 -0400
Message-ID: <CAA1s49X85JfnCxe6Mq-E_t_3tFc37s=hkCRQNFfBoGONivSgTA@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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

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

bob wyman

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

> 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
> --
> Chief Technical Officer
> www.transmute.industries
> <https://www.transmute.industries>
Received on Friday, 3 September 2021 04:09:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 3 September 2021 04:09:06 UTC