The World Wide Web Consortium has rejected Mozilla and Google’s objections regarding the Decentralized Identifiers proposal. This will allow the DID specification to become a W3C Recommendation.
Two tech companies are concerned that the open-ended nature of the spec creates chaos and encourages the proliferation of non-interoperable methods specifications. In addition, the ethics of using proof-of-work blockchains to manage DIDs are also a concern.
DID is a specification that describes how to deploy a globally unique identification without a central authority (e.g. Sign In with Apple) as a verifying entity.
The specification states that they are intended to allow individuals and organizations to create their own identifiers by trusted systems. In addition, these identifiers allow entities to verify their control by authenticating with cryptographic proofs, such as digital signatures.
The Goal of DIDs is to have:
- No central issuing agency,
- An identifier independent of any particular organization,
- The ability cryptographically to prove control over an identifier, and
- The ability to fetch metadata about that identifier.
These identifiers may identify people, organizations, documents or other data.
DIDs conform to the URI schema: did:example:123456789abcdefghi. Here “did” represents the scheme, “example” represents the DID method, and “123456789abcdefghi” represents the DID method-specific identifier.
The documentation explains that DID methods are the process by which a specific type of DID is created, resolved, updated and deactivated.
This information would be written in a DID Document, a JSON object containing key-value data. It describes how to verify the DID Controller (the entity that can modify the DID documents, usually through control over cryptographic keys) to have a trusted and pseudonymous interaction.
Google and Mozilla object that DIDs are not defined. This means there is no way to assess how DIDs will work or how interoperation will be handled.
Google claimed that DID-core can only be used with ‘DID Methods’, which require their own specifications. As a result, it’s impossible to review the impact of the core DID specification on the web without concurrently reviewing the methods it will use.”
DID method specifications are a new URI scheme like the http scheme [RFC7230], but each is unique. There are three types of DID methods: the tax DID specification, the web DID specification, and the meme DID specification.
These are documented on GitHub and then recorded in a verifiable registry. In case you haven’t guessed, this is a blockchain – a distributed, decentralized public ledger.
There is, however, a point of centralization: The W3C DID Working Group has been created to resolve disputes over DID method specifications that violate any of the eight registration process policies.
Mozilla claims that the specification is fundamentally flawed and should not be considered for a W3C Recommendation.
In last year’s mailing list post, Tantek Celik, Mozilla’s web standards lead, wrote that “The DID architectural approach seems to encourage divergence instead of convergence & interoperability.” “The registry has 50+ entries but no interoperability. This suggests that there are more incentives to create a new method than to integrate with one of the many growing existing methods.”
Mozilla is significantly undercounted. The W3C’s DID Working Group currently lists 135 entities, an increase of 105 in June 2021 or 86 in February 2021 when the spec was created. The W3C, which stated this week that it is seeking public-interest non-profit status for DID methods, may not be able to supervise the creation of DID methods if there is significant interest.
Mozilla and Google also raised objections in the last year’s spec debates. For example, representatives from Google felt that the spec should address DID methods that violate the privacy or ethical norms, such as pervasive tracking.
Both companies objected to blockchains’ environmental damage.
Celik stated, “We (W3C) cannot no longer take a wait-and-see or neutral position on technologies involving egregious energy consumption.” We must, instead, strongly oppose such proof of work technologies. This includes blocking their incorporation or enablement (even optionally) to the best extent possible.
Despite these concerns and resistance from Apple and Microsoft, the W3C overruled the objections in a published decision, a requirement for advancing the spec’s status.
You May Like These Stories: