Fighting for Consensus at the World Wide Web Consortium (W3C)

From “W3C Process Document” https://www.w3.org/2021/Process-20211102/

It’s unfortunate that I find myself formally appealing a decision by the W3C Decentralized Identifier Working Group (DID WG) chairs. Simply put, the decision was not made according to the applicable W3C Process, which requires seeking consensus through selecting proposals with the weakest technical objections.

The decision to appeal was not made lightly. It will force into the public view a disagreement between parties who generally have high mutual regard and respect. I personally think the DID WG chairs are well-intentioned and doing their best to resolve the challenges of the underlying work. However, in this particular case, we have a failure to secure consensus and an unfortunate autocratic imposition of the chairs’ position on a group in significant dissent.

I got involved in this particular stream of work after attending the first ID2020 and Rebooting the Web of Trust II after over ten years in the user-centric identity movement as championed by the Internet Identity Workshop and ProjectVRM. I became (and remain) an editor for Verifiable Credentials Use Cases and Use Cases and Requirements for Decentralized Identifiers and the DID Method Rubric, all W3C publications. I am treasurer and board member of Rebooting the Web of Trust, a collaborative writing workshop that incubated early Decentralized Identity technologies like DIDs and VCs. My business is a small consulting company that helps clients better understand the human requirements for decentralized identity systems and applications. I also created the DID Directory DID Directory and host a podcast about DID methods, The Rubric. In short, I have over 15 years invested in bringing this technology to realization, as a consistent contributor to the shared work of the broader community and as a leader in both W3C and external efforts.

After years of serving as invited expert to the VCWG and DIDWG, we joined the W3C this year to specifically to oppose the Chairs’ decision in this matter.

Technical Background

While this appeal does not rely on a technical argument for overturning the chairs decision, our primary technical reasoning is straightforward.

Enabling the DID WG to develop specific DID methods will actively undermine the work’s fundamental goal of decentralization.

A New Architecture Building on the Old Architecture

We have an opportunity in decentralized identifiers to reinvent outdated architectures that rely on, and extend, the innate authority of centralized actors. The World Wide Web is an amazing achievement in operational decentralization. Unfortunately its naming system is fundamentally based on centralized authority, and therefore subject to manipulation and abuse in ways that decentralized systems are designed to avoid. DIDs represent an opportunity for identifiers to be first class citizens for the World Wide Web, without needing to defer to any centralized authority. Not IANA. Not DNS. DIDs provide a way for anyone to stand up an identification system and for anyone to use that system. It is, in its way, a profound restructuring of what identity means in digital systems. Combined with Verifiable Credentials, this emerging identity system provides a decentralized way for individuals to engage digitally with promise of greater privacy, improved user control, and increased respect for our humanity.

A fundamental innovation of DIDs relative to public key cryptography is the level of indirection between the identifier and the cryptography, with different DID methods providing different means for managing this level of indirection.

DIDs resolve to DID Documents, where resolution is defined by the DID method specified in the DID itself. The data required to determine the current authoritative DID document for a given DID is stored in the Verifiable Data Registry of that method.

Consider the DID did:example:abc. This is a well-formed DID using the “example” method. The mechanism to turn that DID into a DID document based on that DID method’s Verifiable Data Registry is called resolution.

First, client software sends the DID to a resolver expected to handle that particular method (“example”). The resolver then uses operations defined by the “example” method to retrieve salient data from the Verifiable Data Registry. Finally, the resolver produces a well-formed DID document and returns that to the client. The client can then interpret the DID document to use the current cryptographic and service endpoint information for that DID.

Because of this level of indirection between the DID and the DID document, DID controllers can update the DID’s cryptographic material without changing the identifier itself (and without relying on a trusted third party). This means that normal, operational security actions like key rotation and revocation can be implemented without requiring direct communication with relying parties. The VDR acts as the intermediary. In fact, the DID controller does not even need to know who is relying on the DID; there is no requirement for direct communication about updates to the DID document. In contrast, updating private key information with traditional public/private key cryptography requires communicating the new public key to all dependent parties.

By design, DIDs enable any form of Verifiable Data Registry. As long as a method can specify how you perform the Create, Read, Update, and Deactivate operations for a DID using that VDR, it’s a valid method. This has allowed DID methods based on bitcoin (did:btcr and did:ion), ethereum (did:ethr and did:elem), bespoke blockchains (did:v1 and did:cosmos), Amazon’s QLDB, and even public keys actually stored in the DID itself (did:key and did:jwk). This fundamental goal of allowing any type of VDR means that interoperability stops at the resolver, which itself provides the integration between resolver clients and a method’s VDR, allowing any method to define its own mechanism for transforming a DID into its DID document, using any kind of VDR.

Parallels to HTML and HTTP

The architecture of DID methods is a lot like the architecture of the web itself, where browsers dereference URLs to access webservers that interact with a backend to provide a resource back to the browser. By design, the browser doesn’t need to know how the web server and back end communicate, nor how the data is stored in the backend. All the browser needs to know is the interface HTTP and HTML.

The equivalent is true for DIDs. With a standard for DID resolution, any DID client would have a standard mechanism (resolution) that can be provided by any conformant DID method, allowing the retrieval and use of DID documents without intimate knowledge of how the VDR works.

That’s the route to interoperability for DIDs, just as it was and is for the web.

Progress to date

We built the first two components of the DID system in the DID Core 1.0 specification, namely, a URL syntax for DIDs and a data model for DID documents, which provide the cryptographic material for verifiable interactions related to that DID. In effect, this is like defining URLs (RFC3986) and HTML (originally RFC1866). At the time of the groups initial chartering, we intentionally left DID resolution out of scope, instead merely defining a contract for what DID resolution should provide (without specifying how it is to be provided). Resolution is how one takes a given DID and retrieves the associated DID document. Resolution is the http of DIDs. It takes a well-formed URL (the DID) and specifies how you process bits sent & received over the wire to get the resource indicated (the DID document in this case).

This is the next step in the work: defining an interoperable mechanism for resolving DIDs for different DID methods. Under the hood, resolution is necessarily method-specific because each method is free to use any verifiable data registry (VDR), and, inevitably, different registries have different mechanisms for creating, reading, updating, and deactivating DIDs. While it will be impossible to have a common specification for all potential VDRs (unless you force all methods to use the same VDR mechanism), it is possible to define an interface that all methods could provide, in order to allow client software to resolve a DID and ignore the method-specific details. This is how we get interoperability between DID methods.

This is a stark contrast to the idea that the next step in the work is standardizing specific DID methods. Some have argued that developing a specific DID method would somehow improve interoperability. However, we believe the only interoperability benefit we get from standardizing a specified DID method is either (1) for different implementations of that single method or (2) imposing the mechanisms of that DID method on other methods. Focusing on a single method does not, and cannot, improve interoperability between Methods, especially those based on fundamentally different VDRs.  As a decentralized technology, imposing the mechanisms of any given method on other methods is antithetical to the point of the work. In a truly decentralized system, anyone can define a new DID method and it should “just work”. That means interoperability between DID methods is the fundamental priority. We achieve that by specifically focusing on a shared, standardized mechanism for DID resolution rather than focusing on specific methods.

Summary of Technical Objection

Having the DID WG standardize specific DID methods creates moral hazards that will inevitably reduce the decentralization of DIDs themselves. Whichever methods the group chooses will attain unprecedented acceleration and impact. It will take an increased attention from the WG focused on those methods, taking away from attention that could go to advance all DID methods. That attention will also increase the WGs familiarity with how chosen methods solve certain problems and those approaches will necessarily already have the blessing of the WG, making them preferred favorites over approaches used by other methods. In short, giving the DID WG the permission to focus its attention on selected favorites would directly undermine its ability to advance the work with equal respect for all methods.

Procedural Objection

We also object on procedural grounds to the inclusion of standards-track documents for unstated new specifications in a so-called “maintenance charter”. A working group chartered for maintenance should not be creating new standards-track documents for arbitrary, unspecified DID methods. Maintenance groups should be focused on maintenance, not creating new specifications, especially unnamed specifications. Like the technical argument for decentralization, we do not rely on this procedural flaw in this appeal.

Formal Request to Deny Chair Decision

I am formally appealing to the Director of the W3C to deny the decision by the DID WG Charter chairs to override dissent about the inclusion of DID methods in the scope of the next DID WG Charter, as embodied in part in the decision to merge PR#20 and PR#27 into the DID WG Charter.

The decision is best summarized in the comment merging in PR#27

The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year.

Despite many, many discussions, no other proposal within the group has garnered as much support as this one has for the creation of a new DID Working Group, which will focus on maintaining Decentralized Identifiers (DIDs) v1.0 and publishing errata updates to that specification. The charter also permits the next DID WG to begin work on DID Methods and DID Resolution, but does not require it, e.g., the group that forms may do as much or as little work on these optional topics as desired.

Now, regarding the other open PRs, #29 and #30:

The predominant concern raised has been with the inclusion of DID Methods as optional work in this charter. The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary. So we have concluded that PR Remove mention of DID Methods from the charter #29 is no longer relevant to this discussion. We are leaving it open for comments, but they will not change the decision at this point.

There have been suggestions for an alternative group focused exclusively on DID Resolution. We support the effort to create a DID Resolution Working Group that focuses entirely on DID Resolution, as that will strongly support the work of the DID Working Group, which must focus on the DID Specification. We encourage the proponents to develop their proposal and present it to W3M and the AC Forum as a new Working Group. However, because it would not be a DID Working Group, we have concluded that PR Proposal: Charter for the DID Resolution WG (as a replacement to current proposal) to continue the work of DID 1.0 #30 is no longer relevant to this conversation. We are leaving it open for those who wish to continue designing a separate DID Resolution-focused WG, but we do not expect such work to change the decision at this point.

2023/03/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

I am appealing on five points, all of which highlight the chairs’ failure to with respect to W3C Process.

I discuss each of these below.

The PR lacks consensus

Both staff and chairs have acknowledged that adding DID methods to the spec lacks consensus.

@brentzundel: I am merging this PR over their objections because having the flexibility to go this route could be vital should our efforts to move DID Resolution forward be frustrated.

2022/09/21 https://github.com/w3c/did-wg-charter/pull/20#issuecomment-1253912348

@pchampin: We clearly didn’t manage to reach consensus here

2023/01/11 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1379253408

@brentzundel: There is no consensus at this stage, nor do I believe it is possible to achieve it.

2023/01/23 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1401199754

The lack of consensus does not appear to be in question.

Consensus was not legitimately sought

The W3C 2021 Process document places consensus at the core of the W3C:

Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).

In the section on managing dissent:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

And, in the section on deciding by vote:

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.

Unfortunately, the chairs did not fulfill these obligations to use all available means of reaching consensus through technical discussion.

They avoided the issue. They denied the issue. Ultimately, they did not lead a technical discussion in an effort to find proposals that create the weakest objections.

• Avoidance
• Denial
• Deference to political priorities over technical discussion

Avoidance

Despite consistent efforts by myself and others who share my concerns, the chairs actions have had the effect of avoiding dissent rather than working with the group to find the proposal with the weakest objections. They ignored Github issues, held no conference calls, created a false impression of engagement, and failed to respond to direct outreach.

Ignoring Github issues

After the initial discussion at TPAC, @brentzundel merged PR#20 on Sep 21, 2022, which put DID methods in scope, with the note that this was against objections voiced at TPAC. I commented in opposition to that merge on October 25, 2022, requesting the PR be reverted. To this date, neither chairs nor staff have even bothered to respond.

No group phone calls nor email discussion after TPAC

After the initial objections were acknowledged at TPAC there were neither group conference calls nor any outreach to the mailing list on this matter. Instead of facilitating a conversation to reach a consensus, the chairs acted as if there were no significant issues for the group to discuss.

False engagement and misdirection

After lengthy discussion on the PR#27 in question (largely by others) @brentzundel created another PR #29 with the stated goal of finding the proposal with the “best consensus” introduced in his comment on #27 on

He did in fact create PR #29, which also led, at the request of @TallTed and @brentzundel to PR#30 to shift the entire focus of the charter to DID Resolution. However, neither of these alternatives were actually given serious consideration by the chairs:

@brentzundel: It was never my understanding that a DID Resolution WG would replace the DID WG. I do not support that course of action. If folks are interested in pursuing a DID Resolution WG Charter separate from the DID WG Charter, the place to do it is not here.

2023/03/22: https://github.com/w3c/did-wg-charter/pull/30#pullrequestreview-1339576495

And again, in the comment announcing the chairs decision

@brentzundel: However, because it would not be a DID Working Group, we have concluded that PR Proposal: Charter for the DID Resolution WG (as a replacement to current proposal) to continue the work of DID 1.0 #30 is no longer relevant to this conversation. We are leaving it open for those who wish to continue designing a separate DID Resolution-focused WG, but we do not expect such work to change the decision at this point.

2023/03/24: https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

Unfortunately, although the chairs’ obligations under the process was to consider all opposing positions and to find the proposal with the weakest objections, @brentzundel made it clear that when counter proposals were offered, they were not welcome. They were not discussed. They were not brought to the attention of the working group. They were summarily dismissed.

Radio Silence via other channels

Despite reaching out to the chairs via email in a personal letter, the chairs never directly responded or engaged in any fruitful dialog on this matter. The email was cited in the same comment as the previous in @brentzundel’s comment on #27 on

@brentzundel I want to especially thank Joe for reaching out directly and engaging in a private conversation where we discussed this PR, the future of the WG, and the reasons we became involved in this work in the first place.

2023/01/24 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1402233965 :

Frankly, @brentzundel’s assertion that “we discussed” anything is a fiction. He did not respond via email nor phone call nor any channels other than communicating his directives through Github comments.

After the recent VCWG face-to-face meeting in Miami, I pulled Brent aside to talk in person for a moment after everything wrapped. In that brief in-person conversation, I affirmed my disagreement with his current position. He restated his belief that this work isn’t “subject to consensus”, which I briefly debated. During this exchange, Brent said “I don’t care. I just don’t care.” He then asked me, as a point of clarification, if I intend to Formally Object if the current PR is merged. I repeated the same position I have made clear since TPAC in September. Yes. I would not only Formally Object, I would use all ethical and lawful means to oppose this decision, including filing an appeal of his decision to override dissent.

Denial

Brent has repeatedly denied that consensus applies to charter development:

@brentzundel : There are no WG consensus requirements in establishing the text of the charter.

2022/12/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1353537492

While Pierre-Antoine has no problem acknowledging that consensus matters:

@pchampin We clearly didn’t manage to reach consensus here.

2023/01/11 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1379253408

Surprisingly, in that same comment from Brent, he confirms my position:

@brentzundel Consensus must be found by the WG for any items developed in the WG, regardless of what the charter allows.

2022/12/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1353537492

Somehow he wants to be able to act as the chair in this matter, using his authority as chair to direct the output of the group towards a particular charter with particular language, but he simultaneously denies that the Charter is an “item” developed by the WG, despite it being done with DID WG resources, by the DID WG participants, under the leadership of the DID WG chairs.

In person, and in various GitHub issues and on Working Group calls, when faced with diverse opinions, unfortunately, it is an all too common response from Brent that “consensus doesn’t apply.”

Deference to political priorities over technical discussion

A significant frustration during this discussion was the repeated deference to non-technical factors rather than focusing on technical distinctions. Rather than debating what would make the most technical sense, the vast majority of arguments for the chairs’ position were political. Not once did the Chairs put forth any arguments other than deference to the perceived requirement from the Director.

Political factors are inevitable, but it is through technical discussion that the work of the W3C moves forward. The nature of standardization is the forging of alignment between competing interests so that the net result satisfies the greatest value. While we may have different tests for what comprises “value”, it is understood that some collective notion of shared benefit, as perceived by the working group, is the driving goal of collaboratively working through our differences. Each participant brings to the table their perspectives and through technical discussion the working group finds consensus around a shared specification that the W3C can formally recommend to the public as a global standard.

From the process document regarding consensus and dissent:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

https://www.w3.org/2021/Process-20211102/#managing-dissent

Takeaway point: the group should favor the proposals with the weakest objections.

And

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.

https://www.w3.org/2021/Process-20211102/#Votes

Takeaway point: resolving dissent should occur through technical discussion.

Later in the document, it discusses how a group formally addresses an issue:

In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound.

https://www.w3.org/2021/Process-20211102/#formal-address

Takeaway point: Adequacy of a response depends on technical soundness.

And the following from Section 5.4 Reopening a Decision When Presented With New Information:

The Chair may reopen a decision when presented with new information, including:

* additional technical information

* comments by email from participants who were unable to attend a scheduled meeting,

* comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

https://www.w3.org/2021/Process-20211102/#WGChairReopen

Takeaway point: reopening a decision is appropriate for new technical information not new political information (unless by email from participants who didn’t get their input in earlier).

In summary:

1. The group should favor the proposals with the weakest objections.
2. Resolving dissent should occur through technical discussion.
3. Adequacy of a response depends on technical soundness.
4. Reopening a decision is appropriate for new technical information not new political information

I interpret this to mean that resolving consensus per the W3C process SHOULD depend on considering competing proposals based on technical discussions and selecting the proposal that has the weakest technical objections.

That did not happen in this case.

Three alternative PRs were under consideration.

PR#27, the PR that explicitly added DID methods as in scope. https://github.com/w3c/did-wg-charter/pull/27

PR#29, a PR alternative suggested by @brentzundel that removed DID methods from the scope, with minimal other changes. https://github.com/w3c/did-wg-charter/pull/29

PR#30, a PR alternative suggested by @christopherallen that put forth a DID Resolution WG charter to focus the group on the next step in interoperability and to avoid the alleged mandate from the Director that the next DID WG MUST standardize DID methods. https://github.com/w3c/did-wg-charter/pull/30

PR#27 elicited several technical objections, including multiple participants who made it clear that both Formal Objections and an Appeal would be filed if this charter is put forth.

PR#29 triggered several statements of preference, on both sides, but only one technical objection.

PR#30 triggered a few statements of preference, on both sides, but no technical objections.

In the face of this evidence, both #29 or #30 had weaker technical objections than #27.

On Technical Objections

There is a legitimate question about what constitutes a technical objection. I rely on the process statement that responding to a formal objection must be what “a W3C reviewer would generally consider to be technically sound”.

Technical issues raised (all quotes from Github):

1. There is no DID Method ready for standardization. (technology is not ready)
2. Standardizing DID Methods is like standardizing websites. (layer violation)
3. There is a technical route to meet the letter and the spirit of the prior formal objectors’ request for further implementation guidance. It includes showing the transport layer using the DID Resolution specification, including its test cases, educating the formal objectors regarding what was achieved, and moving specification of example DID Methods outside this WG’s work items. (there’s a better route to technical interoperability)
4. We don’t want to give the impression that some DID methods are more “important” or “required” than others. (decentralization means no privileged parties)
5. We are told there is a mandate to include standardization of DID methods into the working group charter, but the parties that mandate this inclusion have not been actively involved in the WG process in the past, and there is no evidence that they plan to be involved in the future. This lack of active participation raises questions about the legitimacy of their mandate and the potential impact that these objections may have on the future of this standardization process. (consensus-driven technical standardization depends on participation)
6. If we work on any DID method/s, will this put it/them in a “blessed” state, against which no other DID method/s can possibly compete? I highly doubt it. Though, if it does, that would tend to indicate that all desirable features are fully optimized in that method; else, another method would be registered eventually if not immediately. (Dispute of technical issue #4)

Political Issues raised (all quotes from Github):

1. A given did method deserves its own working group (a different group would be better able to manage its own work)
2. I believe it is the case is that the WG must put forward a charter that will not be the subject of a Formal Objection again. (Avoiding Formal Objections is a political goal.)
3. It has been made abundantly clear by those who formally objected to the DID Specification v1.0 that in their view, a future charter that doesn’t include possible DID Methods will be rejected. (Avoiding rejection is a political goal.)
4. There is documented evidence that we were requested, or at least strongly encouraged (“should”), to include DID methods in the next charter. (Deferring to that suggestion in the face of dissent is a political choice.)
5. This does NOT say we will specify any DID methods. It does NOT say we will not specify anything to do with DID Resolution. It leaves the door open to either or both, which flexibility I and the (I believe, substantial) majority of the group … have talked about as both desirable and likely to be needed. (“Flexibility is desirable” is about retaining political authority, not a technical argument that such flexibility will improve the technology.)
6. There were formal objections and comments made to DID-CORE 1.0 expressing concerns around DID methods. but those objections were overruled with a comment that those concerns will be addressed in the future work. If recharter happens now, it would be appropriate to respect the above and mention DID methods in the charter. (Deference to prior objections is political, not technical.)

So there were both political and technical issues raised by various individuals. However, the question that the process requires the group consider is which proposal had the weakest technical objections. Let us look at the Github conversation on these three PRs.

The following table lists all of the group participants who commented on PRs #27, #29, and #30 (noting that we aren’t clear if the staff liaison should be counted as a participant with regard to consensus):

Those that commented relative to a particular PR are given

• “+” for a preference for that PR
• “FO” for the intention to file a Formal Objecti+on if that PR is merged
• “-” to indicate opposition to that PR
• “NC” to indicate no comment made on that particular PR

	#27	#29	#30
brentzundel	+	NC	–	“The DID WG chairs have met.” “The technical objection to changing this charter into a charter for DID Resolution was outlined by @pchampin above.”
TallTed	+	–	+	“I have not said I would be lodging [an FO] in any case”
rxgrant	FO	+	+	“If we allow DID Method specifications under this change to the charter, this kind of disagreement is going to consume the WG. That is a technical issue that must be addressed.”
jandrieu	FO	+	+	“My only recourse if this language remains in scope is to file a Formal Objection, which will have its own unfortunate consequences in the ensuing public debate”
kdenhartog	+	–	NC	“While I’m not actively invested in this discussion” “I don’t believe only resolution will go far enough because the content that can be returned by a DID document is arbitrary and loosely defined.”
OR13	–	+	+	“I approve #29 and request changes on #27.” “I don’t think defining methods is required to achieve interoperability.” “I don’t believe the WG should attempt to standardize DID Methods. I believe doing so undermines the principle of decentralization, and although it might seem contradictory, interoperability at the core data model layer.”
Sakurann	–	-/+	NC	“I don’t believe that rechartering should happen now.”, “If … I would be ok [with DID methods] not being in scope.”
peacekeeper	+		NC	“I slightly prefer #27 (see my comment #27 (comment)) but could also live with this here.”
burnburn	+	NC	NC	“Suggest ‘developed’ instead of ‘adopted’.”
christopherA	FO	NC	+	“To be clear, I am considering a formal objection … should there be a chair decision to merge this PR.”
pchampin	+		–	“I personally prefer #27, but I won’t object to [#29] if it helps moving forward.”,  “I don’t think we can get away with [#30]”

Summary

	#27	#29	#30
Formal Objections Signaled	3	0	0
Comments in favor	5+1	3.5	5
Comments opposed	5	2.5	2

From this evaluation of the working group’s Github conversation, we see #30 has the weakest objections, followed by #29, with #27 having the strongest objections of all three proposals. This count includes both political and technical objections to make the strength of dissent even clearer. If we were to count only those objectors who cited technical arguments, the results would be even more favorable to PR#30.

	#27	#29	#30
Formal Objections Signaled	3	0	0
Comments in favor	5+1	3.5	5
Technical Objections Raised	5	1	0

The decision making process led by the chairs did not “favor proposals that create the weakest objections”, a violation of W3C Process, Section 5.2.2 Managing Dissent https://www.w3.org/2021/Process-20211102/#managing-dissent

I want to highlight a particular fact about these numbers. They represent a snapshot of a brief and incomplete conversation by the Working Group. One of the primary tenets of this appeal is that the chairs did not lead a discussion for the consideration and improvement of either of these alternative PRs. Once dissent was voiced, all conversation was effectively shut down. Instead, the working group should have further discussed the options represented by #29 and #30 and iterated on both to find the best single charter for the group to proceed. It is the failing to have this conversation—coupled with the expectation to blindly follow the directive of the chairs—that is the process violation at the heart of this appeal.

It is evident from comments in the discussion and in their final decision that any alternative to the chairs interpretation of the Director’s comments in responding to the DID Core Formal Objections, would be ignored. Quite simply, the chairs treated a suggestion from the Director as a mandate to override dissent instead of working together as a group to discover a better option.

Claims of “W3C Consensus” are erroneous, out of scope, and irrelevant

In announcing their decision to continue to override dissent (in the merging of #27) @brentzundel said:

@brentzundel: The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year.

2023/03/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

Unfortunately, the chairs do not cite the basis of their assertion that #27 will produce a charter that best represents the consensus of the group. We have shown in this appeal that the discussion on Github does not justify such a conclusion.

Brent continues:

The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary.

Unfortunately, it is not the chairs’ role to determine the consensus of the W3C, nor is it stated anywhere in the Process that chairs MUST defer to suggestions the Director made in response to previous Formal Objections to a different work product. In fact, as clarified by Phillippe Le Hégaret in regard to the Director’s response to those prior objections (in personal email):

The “should” is NOT a “must”, otherwise it would say so explicitly in the Director’s decision. In other words, the Working Group is allowed to disagree with the direction set by the Director.

Phillippe Le Hégaret, personal email, 2023/03/23

The chairs interpretation of the Director’s response as a mandate is contrary to W3C Process. There is no requirement from the Director in this matter. The chairs incorrectly claim that there is, stating that a W3C Consensus exists that somehow overrides the group’s independent authority. They have used this claim as the fundamental justification for overriding dissent.

The claim of a W3C Consensus is erroneous because the W3C as a whole never had an opportunity to voice their position on the claimed consensus. The response from the Director was a statement resolving an immediate set of objections, stating his suggestion for future work. It was not a statement of W3C consensus requiring the DID WG to charter a new DID WG with methods in scope.

The claim of W3C Consensus is out of scope because the Chairs do not have the authority to assess consensus and speak on behalf of the W3C.

The claim of W3C Consensus is irrelevant because the statement by the chairs is justifying an action by the Chairs regarding an output of the WG. It is not about an action of the W3C.

Even if the W3C as a whole did, in fact, have some sort of consensus on this topic, that alone would not restrict the group from having a different consensus. Of course, a working group may reach a different consensus than the W3C as a whole—after all there are two different groups of participants with different opinions, perspectives, and decision making processes. As such, the consensus of the W3C as a whole is necessarily NOT the same as the consensus of the Working Group. Claims of W3C consensus by the chairs is not only outside their remit, such a “W3C Consensus” should not be taken to require that the WG reach the same conclusion.

Claiming anything about a supposed “W3C consensus” that restricts the actions of the WG is erroneous, out of scope, and irrelevant.

This sets a untenable precedent

The W3C is at a crossroads. Built on trust in the benevolence of Sir Tim Berners Lee, the organization is wrestling with adjusting the process and governance bodies away from a strict dependence on the Director to make major decisions. I appreciate the challenge the organization is facing is like changing the engines on an aircraft in flight. It’s hard. We are in uncharted territory as the organization explores improvements to the Process to deal with this inevitable transition. However, confirming deference to staff as justification for the disregard of legitimate dissent is both inconsistent with the tradition and culture of the W3C and incompatible with an organization whose premise relies on technical cooperation and collaboration. From the W3C mission statement https://www.w3.org/Consortium/mission:

Our Identity “We are an open forum where diverse voices from around the world and industries come together, incubate and build consensus for global standards for web technologies.”

Our Strategic Goals

1. Improve efforts on new technology incubation, making it more structured and improving consensus-building among key stake holders.
2. Achieve worldwide participation, diversity and inclusion, establishing W3C as representative of the worldwide community.
3. Further improve the environment for facilitating balance, equity and cooperation among the participants from different industries, user groups and organizational sizes.
4. Increase involvement of under-represented key stakeholders such as end users, content creators, developers etc.

Emphasis mine.

It is our opinion that if the W3C chooses to interpret staff suggestions as mandates that override working group consensus it will fail to achieve the explicit goals of the organization’s mission.

Shutting down conversation and ignoring dissent does not

1. provide an open forum.
2. improve consensus building.
3. achieve participation, diversity and inclusion.
4. facilitate balance, equity and cooperation among participants.
5. increase involvement of under-represented key stakeholders.

From the W3C Process Document

W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on the consensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission.

The W3C Process promotes the goals of quality and fairness in technical decisions by encouraging consensus, soliciting reviews (by both Members and public), incorporating implementation and interoperability experience, and requiring Membership-wide approval as part of the technical report development process.

https://www.w3.org/2021/Process-20211102

The W3C Process Document lays out the principles and the practices that enable the W3C to legitimately develop standards based on the consensus of its contributors.

If the Director confirms the Chair decision to ignore dissent on this matter, it will set the precedent that Working Group chairs are free to ignore the W3C process should their own opinion coincide with a suggestion from staff. This will transform the organization into a politically driven autocracy that lacks the moral authority of legitimate consensus.

Instead of assisting the W3C in its transition away from a top-down autocratic governance based on the moral authority of Sir Tim Berners Lee to something more meritocratic, confirming the Chairs decision would establish that decisions at the W3C flow from staff down and not from the collaborative, technical discourse of its members.

Proposals with the weakest objections should be favored

The process document states:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

https://www.w3.org/2021/Process-20211102/#managing-dissent

By this metric, PR#29 or #30 should have prevailed. If you exclude the staff liaison from the tally, you have an equal measure of preference and opposition to #27, including 3 intentions to formally object, plus my express intention to fight this decision with every lawful and ethical means at my disposal to oppose the inclusion of DID methods in the DID WG charter.

PR#27 didn’t even get support by a majority of the group and it absolutely caused strong objections from several of us. Even if you include @pchampin’s position, we barely have a majority in support of #27 with strong objections against. A bare majority and several strong objections from a few people does not meet the standard of Process.

Although I read the Chairs statement several times, I do not see how they could legitimately argue that the favored proposal has the weakest objections from participants in the working group.

Summary

I am asking the Director to reconsider and overturn the DID WG chairs decision to ignore dissent and force DID methods to be in scope for the next WG charter proposed by the Working Group.

Since the chairs are claiming a mandate from the Director as the justification for their decision, I am directly asking the Director if what is happening is, in fact, what the Director required.

I have shown that the chairs, in this case, have failed to pursue all available means to find the proposal with the weakest objections. They have instead imposed their own political agenda over considerable technically-grounded dissent.

To recap:

1. The Chair decision in question lacks consensus.
2. Consensus was not legitimately sought, contrary to W3C Process.
3. Chairs claims of an overriding “W3C Consensus” are erroneous, out of scope, and irrelevant.
4. Deferring to staff sets an untenable precedent for a group that prides itself on diversity and consensus-based decision making.
5. The proposal with the weakest objections should be favored.

I hope that the Director will appreciate these arguments and provide guidance that will remove this unfortunate notion that a Working Group’s chairs must defer to mere suggestions by staff. All Working Groups deserve the ability to manage their own work and find their own consensus without imposition from staff.

In particular, I’d like to see the following remedy from the Director:

1. Clarification: does the Director’s response to the Formal Objections to DID Core 1.0 constitute a direct requirement that the Working Group MUST explicitly charter a subsequent DID WG with DID Methods in scope?
2. Clarification: does the Director’s response to the Formal Objections to DID Core 1.0 constitute a direct requirement that the Working Group MUST NOT charter a DID Resolution WG instead of a DID WG?
3. Clarification: What is the role of technical versus political objections when seeking consensus, especially what constitutes a technical objection?
4. Clarification: What are the requirements of the chairs to seek proposals with the weakest objections?
5. Direction for the DID WG chairs to facilitate a conversation to find better alternatives to including DID methods in the next WG charter, specifically to advance either a true maintenance mode DID WG charter (without license for new specifications) or advance a DID Resolution WG charter instead (focusing new specifications on resolution).

When I got involved with this work, I shared many of my colleagues’ concerns about whether or not the W3C has the cultural and institutional wherewithal to stand as a steward for decentralized technologies. Given the organization’s history with many of the largest companies in the world, significant concerns have been voiced about whether or not the keeper of the Web can handle innovations that challenge the corporate dominance of web standards.  

After the Verifiable Credentials specification was approved as a Recommendation, many of us were hopeful. Then, the DID Core specification took an unprecedented fight before it eventually became a W3C Recommendation. The fight was disheartening, but the ultimate approval gave us cautious hope.

Unfortunately, with @BrentZundel’s unwavering demand that the WG advance a charter that overrides consensus to placate a suggestion from staff, I am again given cause to wonder if the W3C is capable of advancing collaborative work based on true consensus rather than political deference. This appeal puts that notion to the test. It is my sincere hope that the W3C will prove true to its mission and its process and recognize the unfortunate error of the chairs, restoring consensus to the heart of our collective work.

Finally, I want to apologize again to the chairs, Brent Zundel and Dan Burnett, as I have already done personally and in our related Github discussion. Both Brent and Dan are great guys, two of the nicest people you’ll meet in standards development. I consider both of them friends and I’m deeply saddened that this matter has become a public conflict with its inevitable consequences for all of us.

Unfortunately, I find myself in an existential disagreement with a decision they have made collectively in their role as chairs of the WG. As outlined above, I believe the path the chairs have chosen fundamentally undermines the work to which I have dedicated my professional life.

It’s not just that this is an unfortunate decision. It is a decision that I am compelled to oppose with all of the lawful and ethical means at my disposal. This opposition is not personal. I know Brent and Dan are doing their best. Unfortunately, in this case, I find their best falls short of the requirements of their role. I sincerely wish the path to resolve this matter didn’t take us to a nasty public fight. I made eighteen separate comments on the PRs in question trying to convince the chairs of the merit of my argument before escalating. I tried. I’m sorry I wasn’t able to resolve this without calling for intervention.

Thank you for your time and attention. I know this is a lot of material to digest and I appreciate the effort that everyone has made to advance this conversation in a civil and professional manner.

Sincerely,

-j

Joe Andrieu
joe@legreq.com
Legendary Requirements