w3c
[wg/did] Remove "Decentralized Identifier (DID) Method Specifications" from deliverables.
From @OR13: [[ Remove "Decentralized Identifier (DID) Method Specifications" from deliverables.
In addition to reasoning for #427 :
Previous formal objections focused on several dimensions of the DID specification including determining if “sufficient decentralization was achieved” and “measuring the trade offs and cost for achieving decentralization”... This included commentary on Proof of Work and Proof of Stake, and their impact on the environment, securities laws, and international trade related topics, including sanctions and political acceptability.
Based on the discussions observed in community groups related to the specification, and the dialog following the previous formal objections, it is our assessment that W3C is not the correct venue to address these political challenges, or the technologies underlying them.
We believe IETF might be a better venue to address some of these concerns, evidenced by the recent interest in Detecting Unwanted Location Trackers (https://datatracker.ietf.org/wg/dult/about/). ]] From 2023 AC Review
[[ This group at the W3C should focus on the data model, URLs, dereferencing and resolution, not standardization of specific did methods.
We object to standardizing any specific DID methods at W3C, especially those that might leverage proof of work. (...)
In addition, since did methods by their nature deal with key material and cryptography, it is likely better that did methods seeking standardization do so at a venue that can provide adequate review and support, such as at the IETF. ]] From 2023 AC Review (member-only)
From @jandrieu [[ [This charter] includes unnamed DID Methods in scope, which we see as fundamentally undermining the entire point of decentralized identifiers: decentralization. (...) The primary technical objection to putting DID Methods in scope is simple conflict of interest. By empowering the DID WG to develop specific DID Methods, it would result in the group picking winners and losers among the 180+ DID Methods currently known. Not only would that give those methods an unfair advantage in the marketplace, it would affect WG deliberations in two important ways. First, the working group would, by necessity, need to learn those selected methods, placing a massive burden on participants, and elevating the techniques of that particular method to accepted canon--which will inevitably taint the DID Core specification with details based on those techniques. Second, this will require the group to evaluate, debate, and select one or a few of those 180+ methods, which will suck up the available time and energy of the working group, forcing them to work on "other people's methods" rather than advancing the collective work that all DID Methods depend on. Those who want to pursue DID Methods at theW3C should propose their own charter based on a specific DID method.
Our second technical objection is more prosaic: there are no DID Methods ready for W3C standardization, as evidenced by the blank check in the current charter request. It may be within the bounds of the W3C process to authorize such an open ended deliverable, but we believe it is a fundamental problem that the chairs cannot even recommend a specific method for inclusion in the charter. Frankly, this weird hack of not specifying the method and restricting that work to FPWD lacks integrity. If its important for the group to develop a method, name it. If it is important for the group to develop a method, make it fully standards track, without restriction. This middle-way is a false compromise that will satisfy no one. (...) Distracting the group with DID Methods specifications would just limit the time and resources the DID WG can bring to bear on solving the real issue of interoperability between methods. ]] From 2023 AC Review
From @rxgrant [[ While it is appropriate for the W3C to at any time convene WGs to standardize any DID Methods that members find sufficient interest in, this MUST occur in new working groups other than a rechartered DID-WG (call those "Fit for Purpose DID Method WGs"). Those groups MUST NOT also have authority to change the DID-core specification.
Any bugs found in a then-current "Decentralized Identifiers (DIDs) Core architecture, data model, and representations" specification ("DID-core") can be addressed by narrowly-authorized DID-WG recharters. ]] From 2023 AC Review