- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 27 Sep 2021 22:06:03 -0600
- To: public-credentials@w3.org
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, did:kr). 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 ecosystem. 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. [1]https://www.w3.org/TR/did-spec-registries/#did-methods [2]https://w3c.github.io/did-test-suite/#report-by-methods [3]https://www.w3.org/2020/12/did-wg-charter.html#out-of-scope [4]https://docs.google.com/presentation/d/1MeeP7vDXb9CpSBfjTybYbo8qJfrrbrXCSJa0DklNe2k/edit#slide=id.p1 [5]https://www.ic.gc.ca/eic/site/101.nsf/eng/00068.html [6]https://essif-lab-infrastructure-oriented.fundingbox.com/ [7]https://www.w3.org/TR/did-rubric/ [8]https://github.com/w3c/did-imp-guide/pull/27 [9]https://www.w3.org/TR/did-imp-guide/ -- manu -- Manu Sporny Founder/CEO - Digital Bazaar, Inc. Our Verifiable Credential Deployments https://www.digitalbazaar.com/case-studies
Received on Tuesday, 28 September 2021 04:06:23 UTC