Status: Final
The W3C Member review of the Decentralized Identifier (DID) 1.0 Proposed Recommendation concluded with Formal Objections from three organizations.
Google:
DID-core is only useful with the use of "DID methods", which need their own specifications. ... 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.
[W]e 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.
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.
[Member]:
The specification should have at least one, interoperable method that works out of the box.
The spec should not move to REC until such a method is in place.
Mozilla:
The DID Core spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ methods.
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 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.
[W]e believe the DID specification may not be fixable (MUST NOT become a Recommendation).
These objections center on concerns over how well the existing implementations of the proposed identifier syntax, data model, properties, representations, operations, and resolution functions demonstrate that DID core has achieved the requirements to have a class of identifiers where:
- there should be no central issuing agency;
- the identifier should be inherently persistent, not requiring the continued operation of an underlying organization;
- it should be possible to prove control of the identifier cryptographically;
- it should be possible to discover metadata about the identifier.
– Use Cases and Requirements for Decentralized Identifiers
It is not questioned that any single DID method might fail to achieve one or more of these properties. The consideration here is whether the proposed DID identifier syntax and associated mechanisms has been sufficiently shown to have defined an extensible class of identifiers that has these properties.
The objectors draw an analogy to the initial URL specification and the URL schemes that that specification included. From an architectural perspective the analogy between URL/URI schemes and DID methods is reasonable. The objectors urge that a DID URI Recommendation follow the precedent established with the URL specification where that specification included several specific schemes mapped to some then-common protocols.
Though this analogy succeeds at an architectural level it fails in the temporal context. The discussion at the time the DID Recommendation Track work was chartered showed consensus that standard DID methods were desirable. The discussion acknowledged that reaching consensus on specific standard methods would be significantly more challenging than reaching consensus on a common foundation for this class of identifiers. From that perspective the registration of a wide variety of conforming DID methods can be seen as a demonstration that the core specification meets the consensus needs of those developing implementations in this space.
In this sense – that a variety of method implementations exist that use and conform to the core specification – the core specification demonstrates its interoperability. It continues to be desirable that some methods also advance to W3C Recommendation.
The question decided here is which path -- advance DID core to Recommendation status or hold it awaiting further work on standard methods -- has least potential harm to the community that needs decentralized identifiers and to the web community more generally.
The objectors argue that the precedent of having some standard URL schemes at the time the URL specification itself was standardized should apply now.
The DID core specification as it is now does not lack proofs of implementability. The histories of many Internet standards show that future work can -- and often does -- lead to improvements to an initial standard. This is a feature, not a flaw. It is ultimately a judgment call of the community as to how long a technology must be deployed before the community updates a standard.
If DID core advances to Recommendation status the Working Group and the community of DID method designers and implementers have consensus that with this architectural layer standardized they have satisfied a portion of their needs and this will permit them to focus next on the specification of recommended methods, whether that be from among those already deployed or by combining features from several designs into one or more "bests of class".
The discussions over the meaning of the term "decentralized", the debate over how well specific DID methods meet the requirements of each of the different classes of applications that use them, whether – and by what criteria – the method registry should restrict what is permitted to be registered, and the balance of acceptable cost of the resources used by each method with the expected benefit of the class of application for which the method is intended will certainly continue. No evidence has been presented that the DID core specification closes options or complicates those discussions.
If DID core is held from advancing to Recommendation this would decrease the motivation for other designers of decentralized identifier systems to follow the consensus of a community who were chartered to create a deliverable in this space. One can easily foresee unnecessary deployment of other URI schemes compounding the interoperability challenge that the community has been working to address.
The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods. The objections are overruled.
The DID core specification is approved to advance to W3C Recommendation.
In its next chartered period the Working Group should address and deliver proposed standard DID method(s) and demonstrate interoperable implementations. The community and Member review of such proposed methods is the natural place to evaluate the questions raised by the objectors and other Member reviewers regarding decentralization, fitness for purpose, and sustainable resource utilization.
-Ralph Swick, for Tim Berners-Lee
30 June, 2022