[wg/did] Remove "Decentralized Identifier (DID) Method Specifications" from deliverables.

[plehegar]

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

[pchampin]

[[
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)

[pchampin]

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

[pchampin]

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

[plehegar]

The charter was announced