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

Responses to DID 1.0 Formal Objections (was RE: Mozilla Formally Objects to DID Core)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 27 Sep 2021 22:06:03 -0600
To: public-credentials@w3.org
Message-ID: <b9d91691-f6e1-fa72-04ce-de6d89cbc871@digitalbazaar.com>
On 9/27/21 4:00 PM, John, Anil wrote:
> https://www.w3.org/2021/09/21-did10-minutes.html 

Now that this is public, I'm happy to share the initial responses to 
Google, Apple, and Mozilla's formal objections to the DID Core 
specification that I sent to the organizations before that meeting happened.

Manu Sporny wrote on September 17th, 2021:

We are having a meeting to discuss the DID Core Formal Objections next
week. The rest of this email contains material that all attendees of the
upcoming DID Core Formal Objections meeting should familiarize
themselves with before attending the call. The information is
categorized into the areas that the W3C Director has classified as
discussion topics via the Agenda.

1. DID methods status, interop, standardization

The success criteria described in our charter states:

* The Working Group will seek evidence of independent interoperable uses
   of the DID syntax and data model from at least two independent
   implementations of each feature defined in the specification.

* The group will add a section detailing any known security or privacy
   implications for implementers, Web authors, and end users.

* The group will maintain and advance a test suite enabling
   interoperability testing, which will ensure the deterministic
   production and consumption of DIDs (URI syntax) and DID Documents
   (data model).

There are 112 DID Methods that have been registered as "Provisional" in
the DID Method Registry[1]. Of these, 47 DID Method implementations have
been submitted to the DID Core test suite with the vast majority passing
all features each method implemented[2].

The interoperability goal of DID Core was at the data model and
serialization layer (NOT interoperability within the same DID Method);
that is, success was to be measured by how many DID Methods used the
same identifier syntax and data model to express features required by
the Decentralized Identifier Ecosystem. The DID Test Suite tested 137
normative features in the specification. Implementers ran their
implementation output against the test suite and the test suite recorded
whether or not their DID Method was conformant with each feature the DID
Method implemented. The end result was a demonstration that 47 DID
Methods conformed with the DID Core specification; that is, they used
the same data model and serialization.

Some of the preliminary DID WG Charter proposals included standardizing
DID Methods. However, several W3C Members objected to standardizing DID
Methods and thus standardizing DID Methods was negotiated to be out of
scope when the DID Working Group Chartering discussions happened[3]. The
DID WG was specifically prevented from ensuring multiple interoperable
implementations within a single DID Method. That said, it happened
anyway (outside of the WG) to some degree (more about this below).

2. Did we achieve practical interoperability?

Given that the goal of DID Core was to ensure that DID Methods used the
same identifier syntax and data model to express the same concepts, and
we had 47 implementations submitted for testing that did this, yes,
there is practical interoperability across DID Methods.

Going above and beyond what was required by our charter, some DID Method
implementers, such as for did:key and did:web, have demonstrated
interoperability between multiple independent implementations in forums
such as those the US DHS Silicon Valley Innovation Program has required
of vendors implementing this technology in government programs[4]. The
same is true for Canadian government initiatives[5] as well as European
Union initiatives[6].

The DID WG would be willing to add the topic of standardizing some DID
Methods under a future charter.

3. Did we achieve to make DID decentralized, given centralized methods?

Yes, there are 112 DID Methods[1] where the majority of them are based
on more "decentralized" technologies, such as distributed ledgers
(did:ion, did:sov, did:v1) or storage-less distributed systems
(did:key), than others that are based on centralized systems (did:ccp,

The fact that we cannot stop individuals from choosing the systems on
which their DID Methods are based should be an indicator that we have
achieved to make things decentralized. That said, it became evident
early on that not everyone agrees on every type of "decentralization"
(governance, computational, political, regional, etc.) that is important
for a DID Method. For this reason, the DID WG has spent a considerable
amount of time creating a DID Rubric[7] that enables organizations to
evaluate whether or not a DID Method meets the decentralization criteria
that's important to them. The Rubric currently contains 36 criteria to
be considered, a number of them on different axes of "decentralized".

What the group has discovered over the past several years of
pre-standards and standards work is that "decentralization" is not a
binary condition, but a multi-dimensional one where different parties
weigh each dimension differently and there is no single correct answer
wrt. Centralized vs. Decentralized. The DID WG did, as much as it could
practically do, without imposing draconian rules that at best, wouldn't
be followed, or at worst, could be viewed as censoring the ability of an
individual or organization from choosing a solution based on their needs.

The DID WG believes that it has achieved the decentralization goals that
it intended to achieve and has documented the areas of debate such that
others can benefit from the many dimensions of the decentralization vs.
centralization debate.

4. DID methods and energy requirements

Some distributed ledgers consume greater computational resources than
others. Whether that consumption is warranted or wasteful is an ongoing
conversation far beyond the scope of the DID WG. Within the WG, resource
usage has been a regular topic of debate, and like the "centralized vs.
decentralized" discussion, the answer largely depends on the
requirements of the individual or organization using the DID Method.
There is implementation guidance that is currently being written[8] that
urges implementers to carefully consider the potential environmental
impacts of their DID Methods, as well as additional criteria for the DID
Rubric[7] to help people decide which DID Methods best meet their needs.

The DID WG is actively addressing this concern in the DID Implementation
Guide[9] and the DID Rubric[7], intends to continue this discussion in
future WGs, and welcomes others to contribute to the authoring of this
sort of material.

5. Do we encourage divergence with an ever growing number of methods?

One property of decentralized systems is not being able to control the
number of individuals and organizations that implement the system. The
DID Spec Registries provide one mechanism for DID Methods to register,
but there is no requirement for them to use it. The nature of a
decentralized system is not compatible with a required central authority
determining who may do what.

To put the number of DID Methods in perspective, however, we point out
that there are currently 346 URI Schemes registered in the IANA URI
Scheme Registry, yet many don't seem to be concerned with an ever
growing number of URI Schemes. One of the reasons for this is an inverse
power law that comes into play in most markets, where a market over
time, will tend to consolidate on a handful of implementation choices.
Many modern systems have largely settled on https and webrtc and left
gopher and ftp behind; but the consolidation took many years to play
out. In the same way, we expect this to happen with DID Methods. This is
already happening to a degree, with many implementers supporting things
like did:key and did:web over some of the more esoteric DID Methods. The
start of successful technology cycles often start with an explosion of
options followed by market consolidation due to the difficulty of
supporting every option. This is something that any W3C WG has very
little control over when introducing new technologies.

The DID WG would most likely be open to strategies that would provide
healthy nudges to the market to consolidate sooner rather than later,
understanding that we have few tools to enforce that in a decentralized

6. JSON Web Keys and format cross-compatibility guidance

The topic of JSON Web Keys and cross-format compatibility guidance was a
topic of regular debate in the Working Group and the result of that
debate was the current contents of the DID Core specification. If
further language is desired, it is suggested that those wanting that
language to exist in the specification submit a PR that can be reviewed
and further debated by the Working Group.

This would be a good topic to include in a future DID Working Group Charter.


I hope this information has been helpful in understanding that the
formal objections that have been raised have been considered by the DID
Working Group, that the WG has addressed its Charter, W3C Process, and
technical requirements, and we look forward to finding a resolution to
the formal objections and moving forward with the standardization of
Decentralized Identifiers.



-- manu

Manu Sporny
Founder/CEO - Digital Bazaar, Inc.
Our Verifiable Credential Deployments
Received on Tuesday, 28 September 2021 04:06:23 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:22 UTC