This document is intended to help the Director and his delegate to understand all sides of the arguments related to the Formal Objections to the Proposed Recommendation of DID 1.0. It is not an analysis of every argument raised.
The Working Group requested Candidate Recommendation for DID 1.0 on March 9, 2021, a revised CR snapshot was requested on June 15, 2021, and then Proposed Recommendation on July 28, 2021
The Advisory Committee review closed on August 31, 2021:
The formal objection from Google states:
DID-core is only useful with the use of "DID methods", which need their own specifications. These specifications are listed in the did-spec-registries WG Note, but none has made it past "PROVISIONAL" status, and the Note doesn't even define what its Status column means. It's impossible to review the impact of the core DID specification on the Web without concurrently reviewing the methods it's going to be used with. As the DID WG's charter states, we should follow the precedent set by the development of URLs, in which RFC 1738 standardized 10 schemes at the same time as it standardized URLs in general.
We strongly support the goal of decentralizing identifiers, but a review of a few of the provisional methods raises questions about how effective and ethical DID will be at accomplishing this. Some, like did:ccp:, are centralized under a single server. Many rely on proof-of-work cryptocurrencies, which fail the sustainability goals of the Ethical Web Principles. The process of advancing a few of the best methods through the Recommendation track will help focus review on them, and is likely to reveal places the did-core specification should change to fit the ways they improve.
We suggest holding off on advancing did-core to REC status until at least 3 or more methods are also ready to advance to REC.
(*) Note: Anonymized1 formal objection is Member confidential but a record of each Formal Objection must be publicly available
(5.6. Recording and Reporting Formal Objections).
The formal objection from Anonymized1 states:
We agree in full with the concerns raised by Google in their Formal Objection. The specification should have at least one, interoperable method that works out of the box, either (preferred) included or (less preferred) registered. To borrow Microsoft's words, the Working Group must take up "the challenge of defining a[...] fully interoperable DID method that meets industry use cases and can be specified as a mandatory to implement[...] method."
Lawrence Berkeley National Laboratory requested adding a requirement "to provide a system- and processor-independent assessment of the energy requirements of a DID method." Whatever this mandatory method is, it must not be unsustainable / in violation of the Ethical Web Principles.
The spec should not move to REC until such a method is in place.
Additionally, we agree with Microsoft's compatibility concerns re: JSON and JSON-LD.
The formal objection from Mozilla, whose request is not to publish the document at all, states:
Summary:
- No practical interoperability.
- Encourages divergence rather than convergence.
- Centralized methods allowed, in contradiction to WG & spec goals & name.
- Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y).
No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”, none of which themselves have interoperable implementations. We agree with the analogy to URLs & schemes, as Google noted: “precedent set by the development of URLs, in which RFC 1738 standardized 10 schemes at the same time as it standardized URLs in general”. The Web has similar experience with the img tag & image formats, and the video tag & video formats. In each of those cases, there were multiple interoperable formats before the tags themselves were standardized. In addition, we agree with the comments made by Microsoft to “recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.”
Encourages divergence rather than convergence. The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods. Note this is in contrast with prior examples given (URL schemes, image & video formats). Thus, whether intended or not, the DID specification (and perhaps its inherent architecture) is designed in such a way that encourages divergence of implementations, rather than convergence & interoperability.
The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability. In particular:
- 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.
- Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y). Also as noted by Google, the registry contains methods which rely upon proof-of-work which is wasteful. “Successful” proof-of-work systems waste a staggering amount of electricity world-wide (e.g. Bitcoin consumes more energy than most countries) demonstrating that the more such methods are adopted, the more their energy requirements grow, without any discernible upper bound, which is grossly irresponsible given the global environmental crisis (recent IPCC report).
Lawrence Berkeley National Laboratory suggested “the registry should include a requirement to provide system- and processor-independent assessment of the energy requirements of any methods being registered.” We don’t think this goes far enough.
We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the TAG Ethical Web Sustainability principle).
For these reasons we believe the DID specification may not be fixable (MUST NOT become a Recommendation). We suggest returning the specification to Working Draft status.
On September 21, 2021, the Team attempted to establish a common ground between the parties, but no consensus was reached. Since then, the Working Group updated several of its adjunct documents. There is work in progress on adding an ethical considerations section in the DID Implementation Guide v1.0. Additional text was added to encourage method reuse.
The Working Group wrote answers to the DID Formal Objections. Those responses are partially quoted in the analysis below.
Decentralized Identifiers (DIDs) v1.0, Core architecture, data model, and representations states:
Decentralized Identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities.
DID 1.0 provides the framework to deal with DID methods in a general way. All of the objections raised are not directed against the framework itself but rather against the DID methods listed in the registry and used in the implementation report.
Google indicated:
We suggest holding off on advancing did-core to REC status until at least 3 or more methods are also ready to advance to REC.
Anonymized1 [*] indicated:
The specification should have at least one, interoperable method that works out of the box, either (preferred) included or (less preferred) registered.
The Working Group responded:
In the first iteration of the DID Working Group, we standardized DID Syntax, the DID Resolver interface, and the DID Document. We didn’t standardize DID Methods because 1) we were asked to aggressively narrow scope by the W3C Advisory Committee, 2) we didn’t feel that the entire community could agree on standardizing any singular DID Method when we chartered the group and the W3C Advisory committee had concerns over “picking a winning DID Method”, 3) we don’t need to do that to demonstrate interoperability for a data model specification, and 4) we can (and did) test for interoperability without standardizing DID Methods (as described above).
Similarly to RFC3986 (Uniform Resource Identifier (URI): Generic Syntax), DID 1.0:
The DID Specification Registries contains a registry table for DID methods. It is an informative reference from the DID 1.0 specification.
Both the Working Group and the objectors agree that a good future state would be to have a handful of “truly decentralized methods” that are standardized and broadly adopted.
The Charter of the Working Group did place out of scope work on specific DID Method specification. The Working Group asserts it would be best to let the community experiment with various methods and attempt to standardize some methods after 2 years.
The objectors assert that DID 1.0 should not be a W3C Recommendation before its impact can be reviewed, which requires reviewing the methods it is going to be used with.
Out of the methods included in the registry, some participants in the Working Group estimate that 2 methods are deemed ready for standardization: did:key and did:web. These methods have multiple implementations.
When reviewing the transition request to Proposed Recommendation, the Director assessed that the DID Working Group demonstrated adequate implementation experience of DID 1.0 Core and interoperability on existing methods, even if none of the methods are on a standardization track yet.
Mozilla indicated:
No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”,
Google clarified in March 2022:
The core of our objection is getting lost [in the report]; maybe because the first two points are (to us) the same core objection (“Lack of demonstration of interoperable methods” and “Lack of demonstration of practical interoperability”). The lack of demonstration of interoperable methods is LEADING to the core problem. Mozilla stated this better as "has not demonstrated any degree of practical interoperability" - that any interoperability that might be enabled by the current DID Core 1.0 is only enabled by reliance on other specifications that are not yet standardized.
The Working Group responded [see the full answer]:
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. The same. is true for Canadian government initiatives as well as European Union initiatives
The Charter of the Working Group requested that the Group 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 Working Group asserts that the implementation report of DID 1.0 demonstrates the interoperability of the DID 1.0 approach. With 47 implementations submitted for testing, the proposed syntax and data model of DID 1.0 demonstrated its applicability.
The objector asserts that having a syntax and data model is not enough to demonstrate practical interoperability.
The DID 1.0 design goals state:
| Interoperability | Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability. |
At the moment, without a proper DID Resolver defined by the DID method, it is not possible to resolve or verify DIDs. While it is important to agree on a syntax and data model, it is not possible to use the DID 1.0 specification without an actual method, thus forcing all tools and software libraries to choose which methods to support and preventing actual use of DID documents without having mutual supportfor at least one DID method. So practical interoperability remains limited in the absence of common DID methods.
Mozilla indicated:
The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods.
The Working Group responded:
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 Working Group has very little control over when introducing new technologies.
The DID Working Group 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.
The Working Group asserts that market forces will encourage convergence around a
limited set of DID methods. It should be noted that RFC1738 (Uniform Resource Locators (URL)) was originally published with
10 specific schemes, including ftp, http and file. This was done as part of the specification defining the URL syntax.
The objector asserts that absent a standardized set of mandatory or near mandatory methods there will be further fragmentation and divergence. Additional text was added to the DID Implementation Guide v1.0 to encourage method reuse.
There are already 112
methods registered, compared to the 10 specific schemes defined in the original URL specification. In the absence of common methods, the registration of new
DID methods is likely to
continue to occur. The market may converge on using did:web and
did:key as common methods however.
Google indicated:
We strongly support the goal of decentralizing identifiers, but a review of a few of the provisional methods raises questions about how effective and ethical DID will be at accomplishing this. Some, like did:ccp:, are centralized under a single server.
Mozilla indicated:
The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability. In particular:
- 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.
The Working Group responded:
Many of us (objectors and DID Working Group members) do not want to support the registration of “centralized” (by some definition) DID Methods. However, the DID WG expects that many understand that we can’t stop centralized DID Methods from existing, just as we cannot all agree on which factor(s) outlined in the rubric define “usefully decentralized” methods, and it’s better to document the reality of the entire ecosystem than pretend that part of it doesn’t exist. We could refuse to register centralized DID Methods, but then we must make the whole “is it decentralized enough” value judgement when people try to register their DID Methods, which often does not come down to an objective measure.
If any of the objectors would like to pursue this, the DID Working Group would need to understand what concrete set of objective requirements we could apply to all DID Methods to draw a clear line between “centralized” and “decentralized”. Given the hours of discussion this topic has received in the DID Working Group, I expect it will be difficult for the objectors to put forward concrete objective criteria that the group has not already considered.
Similarly to RFC3986 (Uniform Resource Identifier (URI): Generic Syntax) with schemes, DID 1.0 does not constrain the DID methods. The DID Spec Registries provide one mechanism for DID Methods to register, but there is no requirement for them to use it:
New DID methods are defined in their own specifications to enable interoperability between different implementations of the same DID method.
The Working Group asserts that the DID 1.0 specification cannot prevent centralized DID Methods from existing, just as the community cannot all agree on which factor(s) outlined in the rubric define(s) “truly decentralized” methods. As such, it’s best to document reality and allow all methods to be registered instead of applying a value judgment.
Mozilla argues that the registry should disallow centralized methods.
To make their intent clearer, Mozilla also added in March 2022:
We recognize that there is no meaningful way to avoid the use of new code points, though we believe that the W3C should provide a mechanism to indicate that they are disfavored, like the Recommended=(Yes|No) that RFC 8447 defines.
The DID 1.0 design goals state:
| Decentralization | Eliminate the requirement for centralized authorities or single point of failure in identifier management, including the registration of globally unique identifiers, public verification keys, services, and other information. |
| Control | Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities. |
The methods that demonstrated the most interoperability, did:web and did:key, are
decentralized methods to
a degree (see also Centralization
and Internet Standards): did:web relies on knowledge of DNS. did:key relies on knowledge of a
repository of cryptographic public keys. As such, those 2
methods do not satisfy the design goals of decentralization and control as outlined by DID 1.0.
The Working Group is iterating on the DID Method Rubric document, intended to be a collection of criteria for creating Evaluation Reports that assist people in choosing a DID Method. The Working Group also responded:
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. There is no single correct answer with respect to the question of Centralized vs. Decentralized. The DID Working Group 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.
Google indicated:
Many [provisional methods] rely on proof-of-work cryptocurrencies, which fail the sustainability goals of the Ethical Web Principles.
Anonymized1 [*] indicated:
Lawrence Berkeley National Laboratory requested adding a requirement "to provide a system- and processor-independent assessment of the energy requirements of a DID method." Whatever this mandatory method is, it must not be unsustainable / in violation of the Ethical Web Principles.
Mozilla indicated:
The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability. In particular:
[...]
- Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y). Also as noted by Google, the registry contains methods which rely upon proof-of-work which is wasteful. “Successful” proof-of-work systems waste a staggering amount of electricity world-wide (e.g. Bitcoin consumes more energy than most countries ) demonstrating that the more such methods are adopted, the more their energy requirements grow, without any discernible upper bound, which is grossly irresponsible given the global environmental crisis (recent IPCC report ).
Lawrence Berkeley National Laboratory suggested “the registry should include a requirement to provide system- and processor-independent assessment of the energy requirements of any methods being registered.” We don’t think this goes far enough.
We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the TAG Ethical Web Sustainability principle.
The Working Group responded:
The DID specification is a data model specification and thus does not recommend any specific backing technology or network for a decentralized identifier. There is a good article on this particular point here:
https://www.coincenter.org/open-blockchains-and-decentralized-identity-standards/
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 Working Group. Within the Working Group, 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 that urges implementers to carefully consider the potential environmental impacts of their DID Methods, as well as additional criteria for the DID Rubric to help people decide which DID Methods best meet their needs.
The DID Working Group is actively addressing this concern in the DID Implementation Guide and the DID Rubric, intends to continue this discussion in future WGs, and welcomes others to contribute to the authoring of this sort of material.
Several of the methods rely on decentralized ledger technologies (DLT), in particular using Proof of Work (PoW) to validate transactions.
From Wikipedia:
Proof of work (PoW) is a form of cryptographic proof in which one party (the prover) proves to others (the verifiers) that a certain amount of a specific computational effort has been expended.
The amount of energy required to make such a proof and its sustainability in terms of environmental impact has been controversial. The TAG has published the following opinion:
The web, as a whole, is a big source of carbon emissions, because it is a big consumer of power. New web technologies should not make this situation worse. We will consider power consumption and the resulting emissions when we introduce new technologies to the web. This includes maximizing the lifespan of physical devices through maintaining compatibility, as well as minimizing data storage and processing requirements.
The TAG did not raise concerns about energy consumption during its wide review. The TAG did not however review any DID methods since those were not part of the specification and thus was outside the scope of their review.
Again, DID 1.0 does not constrain the DID methods. The DID Spec Registries provide one mechanism for DID Methods to register and the Working Group chose not to impose further requirements in the registration process.
Mozilla clarified in March 2022:
we recognize here too that the WG cannot stop people using DID with PoW technologies. However, we believe that it is appropriate for the WG to standardize at least one DID method that is both (1) decentralized and (2) does not depend on PoW.
The Working Group recognizes the issue and is willing to do whatever W3C determines is appropriate for Rec-track documents, as long as such environmental considerations sections or sustainability review are part of the horizontal review process and applied consistently on all groups. It is already considering adding a section for environmental criteria in the Rubric Method document.
Note: This comment was not raised as a formal objection.
Microsoft indicated:
- Interoperability could be improved with a single foundational key representation. We would prefer implementers use JSON Web Key for representing cryptographic keys. We believe JSON Web Key would be a great baseline of support that could be extended with additional formats. Any additional formats included in the spec text should include the appropriate usage context. Related to: DID-Core Section 5.2.1.
- We recommend additional non-normative guidance on cross-compatibility between the JSON and JSON-LD representations in Section 6. We further recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.
Mozilla concurred with those comments.
The DID 1.0 specification defines 2 representations, JSON and JSON-LD, while allowing any other representation, such as CBOR, XML or YAML, that is capable of expressing the data model.
The JSON-LD representation is an extension of the JSON representation: all of the production and consumption rules for JSON are applied to JSON-LD. However, a conforming consumer of the JSON-LD representation is not required to process the JSON representation:
The Working Group participants' interest focused on the JSON-LD representation. All of the implementations used during the Candidate Recommendation phase have used the JSON-LD representation. The test suite has extensive tests for JSON-LD.
The preference of the Working Group participants remains in the JSON-LD representation but would certainly welcome participants interested in the JSON representation. Without additional participants, it is unlikely that more effort will be put on the JSON representation in the near term.
The charter of the Decentralized Identifier Working Group received the Director’s approval on September 5, 2019. The detailed disposition of comments is available.
No formal objection was raised during the charter review:
During the charter review,
it isn't a priority for us [Mozilla] to argue about it) but did indicate that chartering the Group was not a good use of W3C’s resources:
it's not clear to us that this work will produce something decentralized. The cost of reaching interoperability on new DID methods makes this appear more centralized than URIs, where the cost of registering a domain is low and well-understood.
The information was sent based on the initial draft of this report. Some adjustements were applied to the report following the comments but others were declined (and are therefore still relevant).
I think the core of our objection is getting lost; maybe because the first two points are (to us) the same core objection (“Lack of demonstration of interoperable methods” and “Lack of demonstration of practical interoperability”). The lack of demonstration of interoperable methods is LEADING to the core problem. Mozilla stated this better as "has not demonstrated any degree of practical interoperability" - that any interoperability that might be enabled by the current DID Core 1.0 is only enabled by reliance on other specifications that are not yet standardized. When you mentioned "the Director assessed that the DID Working Group demonstrated adequate implementation experience of DID 1.0 Core and interoperability on existing methods", the Director was probably mistaken: while some DID documents do interoperate assuming that the two implementations have de-facto standardized a method (which in practice always seems to be did:key: or did:web:), 1) the Proposed Recommendation and its normative references aren't enough to write those interoperable implementations, and 2) did:key: and did:web: don't use all aspects of DID documents, and the remaining unused aspects haven't been shown to interoperate.
The WG compares DID Methods to URI schemes, and we think this is an appropriate comparison, but we think the way the WG's FAQ presents the comparison is misleading in several ways, which have been propagated into the Team-endorsed text in the document:
- The Team's document ought to acknowledge that there are a small number of URI schemes that DO enable core interop across systems (e.g. HTTP). If URIs were just a identifier syntax for app-specific URIs and the like, they would have considerably less interop impact.
- As this is a discussion of the initial standardization of DID technology, the Team's document should cite RFC 1738 (which included definitions of 10 schemes) instead of RFC 3986. Following RFC 3986's model of referring to other standards will be appropriate once there are some other standards defining DID methods.
- Similarly, the Team should compare the ~112 DID methods registered at its first standardization with the ~15 URL schemes defined or imagined at its first standardization, not the 346 schemes registered almost 30 years later.
We'd like to double-check that the Team is presenting the WG's FAQ to the Director as opinion rather than fact?
The Team's document characterizes all three objections as asking for "truly decentralized" methods, but we don't know what that would mean and don't insist on it. We want to see the WG figure out its own design constraints for "good" methods (as the Rubric starts to do) and standardize some of those. As the Team's document says, it seems clear that did:key: and did:web: aren't sufficient for the WG's own goals. Note that we were not expressing concern over allowing "bad" methods into the registry; just a desire to see interoperable implementations of some that the WG considers "good".
On the registration of DID methods that are harmful to sustainability, I would point out that the TAG did not REVIEW any methods - because they aren't part of the DID Core, and are thus outside the scope of their review.
One last point - in the 2019 Charter Review section, the text should mention that Google did not respond to the charter vote, Anonymized1 abstained, and Mozilla objected without raising a Formal Objection. (The text of Mozilla’s response is clearly an objection, but they stated up front that they simply didn’t have the bandwidth to make the argument.)
See also the answer to the Google comments.
DID 1.0 provides the framework to deal with DID methods in a general way. All of the objections raised are not directed against the framework itself but rather against the DID methods listed in the registry and used in the implementation report.
We don't believe this is correct. Absent interoperability on methods, it is not clear that there is meaningful interoperability of the framework either. This is especially true given that, for instance, did:key doesn't meaningfully use most of the features of DID.
The comparison with URI schemes is in-apt. The issue is *not* that there is a registry with multiple schemes, but that there is a lack of any widely implemented common subset. At the time that URIs were standardized in 1994, there was already very widespread support for HTTP and emerging support for HTTPS to the point where it was highly probable that any URI-consumer would be able to consume at least HTTP. That is not the case with the DID method registry which still lacks any methods with multiple implementations.
Even if it were to emerge that did:key and did:web became widely supported in this fashion (which is not the case now), that seems to represent a failure of this process, not a success, as they do not really address any of the WG objectives of a decentralized system.
Similarly to RFC3986 (Uniform Resource Identifier (URI): Generic Syntax) with schemes, the Working Group is pointing out that there are 346 URI Schemes registered in the IANA URI Scheme Registry, and market forces will encourage convergence around a limited set of DID methods.
pointing out...will encourageis taking a position when there are not facts in evidence. This is just a bare assertion. Contrast that with the next paragraph where you refer to our position as "asserts". We're looking for balance here.Also comparing the present numbers of a well-established mature registry decades after standardization with the numbers of a relatively new registry that is still awaiting standardization is not an apt comparison.
The objector asserts that the specification and the requirements around the registry should further encourage reuse of existing methods. Additional text was added to the DID Implementation Guide v1.0 to encourage method reuse.
This is not accurate. What we assert is that absent a standardized set of mandatory or near mandatory methods there will be further fragmentation and divergence.
We're not looking for more language exhorting people to reuse but for a common minimum set.
Mozilla argues that the registry should disallow centralized methods.
That is a literal point from our FO, however our intent is more subtle. We recognize that there is no meaningful way to avoid the use of new code points, though we believe that the W3C should provide a mechanism to indicate that they are disfavored, like the Recommended=(Yes|No) that RFC 8447 defines. If it would help, we could amend our FO to clarify this.
On Proof of Work (PoW): we recognize here too that the WG cannot stop people using DID with PoW technologies. However, we believe that it is appropriate for the WG to standardize at least one DID method that is both (1) decentralized and (2) does not depend on PoW.
We also have concerns & disagreements with statements in the DID WG FAQ, so we would like clarification as to whether you Philippe are presenting that FAQ as factual to The Director, or if it is being presented as the WG's opinion (not the Team's), no more (or less) valid than viewpoints being expressed by objectors? If the former, then we will need more time to submit a corrections document for that submission as well.