The World Wide Web Consortium (W3C) overturned Google and Mozilla’s objections to the decentralized identifiers (DID) proposal, paving the way for the DID specification to be published as a W3C recommendation next month. The review by W3C members of the proposed DID 1.0 recommendation has led to formal objections from some organizations.
DID-core is only useful with the use of “DID methods”, which require their own specification. … It is impossible to examine the impact of the DID-core specification on the web without simultaneously examining the methods by which it will be used. We should follow the precedent set by URL development, where RFC 1738 standardized 10 schemes at the same time standardized URLs in general.
The process of promoting some of the best methods through recommendation will help focus the review on them and is likely to reveal where the did-core specification should change to accommodate the ways they are improving. We suggest not to advance the did-core to the REC state until at least 3 or more methods are ready to move to REC.
The base specification of the DID demonstrated no degree of practical interoperability, instead delegating it to a registry of more than 50 methods.
DID’s architectural approach appears to encourage divergence rather than convergence and interoperability. The presence of over 50 entries in the registry, without real interoperability, seems to imply greater incentives to introduce a new method, rather than attempting to interoperate with one of the many existing growth methods. The absence of restrictions on the register allows methods diametrically opposed to the principles of the group and the disciplinary, and methods that are actively and globally harmful to sustainability. We believe the DID specification may not be solvable (MUST NOT become a recommendation).
The two tech companies fear that the open nature of the specification fosters chaos through a namespace road that encourages the proliferation of non-interoperable method specifications. They are also concerned about the ethics of relying on proof-of-work blockchains to manage DIDs.
The DID specification describes a way to deploy a globally unique identifier without a centralized authority (eg Apple for Sign in with Apple) as a verification entity.
Decentralized Identifiers (DIDs) are a new type of identifier that allows for a verifiable and decentralized digital identity. A DID refers to any entity (e.g. person, organization, thing, data model, abstract entity, etc.) as determined by the DID manager. Unlike traditional federated identifiers, DIDs have been designed in such a way that they can be decoupled from centralized registries, identity providers, and certificate authorities.
In particular, while other parts can be used to enable the discovery of information related to a DID, the design allows a DID’s controller to demonstrate control without the need for another party’s permission. DIDs are URIs that associate a DID subject with a DID document allowing for reliable interactions associated with that subject.
They are designed to allow individuals and organizations to generate their own credentials using systems they trust, “explains the specification. These new credentials allow entities to prove their control by authenticating using cryptographic evidence such as digital signatures.
The goal of DIDs is not to have a central issuing agency, to have an identifier that persists independently of any specific organization, to be able to cryptographically prove checking for an identifier, and to be able to retrieve metadata about the identifier. These identifiers can refer to people, organizations, documents or other data.
DIDs conform to the URI scheme: did: example: 123456789abcdefghi. Here, “did” represents the schema, “example” represents the DID method, and “123456789abcdefghi” represents the specific identifier of the DID method. This would be expressed in a DID document, which is just a JSON object containing other key-value data describing things like how to control the DID controller (the entity capable of modifying the DID document, usually by checking cryptographic keys) in order to have a reliable and pseudonymous interaction.
What Google and Mozilla dispute is that the DID method is not defined, so there is no way to gauge how DIDs will work or how interoperability will be handled.
The W3C states:
There is no doubt that a single DID method may fail to achieve one or more of these properties. The question here is whether the proposed syntax for DID identifiers and associated mechanisms have been sufficiently demonstrated to have defined an extensible class of identifiers with these properties.
Objectors make an analogy to the original URL specification and URL schemes included in this specification. From an architectural point of view, the analogy between URL / URI schemes and DID methods is reasonable. Opponents urge that a DID URI recommendation follow the precedent set by the URL specification, which included several specific schemes corresponding to then common protocols.
While this analogy works on an architectural level, it fails in the context of time. The discussion that took place when the DID recommendation track was created showed that there was consensus that standard DID methods were desirable. The discussion recognized that reaching consensus on specific standard methods would be much more difficult than reaching consensus on a common basis for this class of identifiers. From this point of view, the record of a wide variety of compliant DID methods can be seen as a demonstration that the base specification meets the consensus needs of those developing implementations in this space.
In the sense that there are a variety of implementations of methods that use and conform to the base specification, the base specification demonstrates their interoperability. It is always desirable that some methods exceed even the W3C recommendation. The question that is decided here is which path to advance the core DID to the recommended state, or to keep it pending further work on the standard methods, is the least harmful to the community that needs decentralized identifiers and to the web community. in general.
Opponents argue that the precedent of some standard URL schemes that existed at the time of standardization of the URL specification itself should apply now.
Google and Mozilla also raised other objections when discussing the specs last year. As Manu Sporny, co-founder and CEO of Digital Bazaar, told in a discussion on the mailing list, Google reps felt the specifics needed to address DID methods that violate ethical or privacy standards, such as enabling ubiquitous tracking. . Both companies have also opposed the environmental damage of blockchains.
We (W3C) can no longer take a wait-and-see or neutral stance on technologies that are blatantly energy-intensive, “Elik said. Instead, we must firmly oppose these proof-of-work technologies, including doing everything possible to prevent them from happening. are supplemented or enabled (even optionally) by any specification we develop.
Despite these concerns, as well as resistance from Apple and Microsoft, the W3C overcame the objections in a published decision, a requirement for advancing the state of the specification.
And she ?
What is your opinion on the subject?
WebAuthn: W3C and FIDO Alliance finalize the standard for passwordless logins and invite sites and companies to adopt it
HTML 5.2 is now finalized and becomes the new W3C recommendation and HTML 5.3 draft specification already published
Google, Apple, Microsoft and Mozilla formally oppose a decision by the W3C, which wants to continue the standardization process of DOM 4.1