we should not exclude the possibility to be able to talk about DID method standardization

We had a lively conversation on this topic during our F2F meeting in Vancouver last week. The reaction to this PR was positive for all but a couple of folks, who were concerned that introducing this language to the charter, and putting in scope specifying any DID Method, would at best be a distraction from more productive efforts toward demonstrating interoperability such as DID Resolution.
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.

For the record, I do not believe this language about DID Method Specifications had consensus. Multiple parties opposed it.

Please undo this merge until we can establish a consensus on this change.

@jandrieu Hmm this doesn't say that the WG will work on DID methods, only that it will seek consensus around this topic and that it may produce "related documents". Are you saying this was opposed?

Would the alternative be to explicitly prohibit the WG from working on DID methods? Or something else?

Would the alternative be to explicitly prohibit the WG from working on DID methods? Or something else?

Yes.

There was not a consensus on the call, as acknowledged by @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.

There is no DID method in existence that is ready for standardization, as evidenced by the conversations in the working group that attempted, and failed, to identify such a method.

When, and if, there is a method that exemplifies all the goodness of DIDs and has multiple implementations then it would be appropriate to form a working group specifically for standardizing that particular method.

There is no point at which I would support the DID WG working directly on a method specification, precisely because doing so would unfairly elevate that particular method above all others. It's the job of the DID WG to figure out DIDs, not to play favorites among different valid methods. This is an unacceptable centralization of an innately decentralized technology.

Perhaps more importantly, without a specific method that is complete and suitable, the working group will be distracted by design-level arguments about how to build out that method. Not only would this be a complete waste of time (design by committee is not what WG do well), it would inevitably give that method unfair influence over the spec relative to all other methods.

This is a rathole we should not go down.

We have a data model specification. Call that our "HTML". What we need is our "HTTP", which, to my analysis is the DID Resolution specification: an API for how you retrieve DID Documents, just like HTTP is a specification for how you retrieve HTML pages (in its origin).

Standardizing methods is like standardizing websites built on HTML and HTTP. Yes, in some cases, I can acknowledge the suitability of application level standards (of apps built on HTML/HTTP). But the W3C has, to my knowledge, NEVER standardized websites in that manner. Please correct me if I'm wrong.

Even if I am, then the appropriate place for standardizing Methods is after we have the data model and protocol specs done AND we have multiple implementations of a method that satisfies the primary design considerations for DIDs.

In addition to these concerns, which were raised in the working group call, @brentzundel, I believe this editorial override of objections does NOT represent consensus of the working group and is, as such, a violation of process.

Again, please revert this merge. It was inappropriate.

@rxgrant Also expressed his concerns in that meeting, so I'm tagging him here to solicit his input.

@iherman Perhaps you can comment on the W3C process and how much discretion the chairs have to override the objections of multiple parties when there is a clear lack of consensus. The argument that "it could be vital" is, to my mind, not a legitimate justification and a rather slippery slope giving the chairs an open hand to dismiss legitimate concerns expressed in an appropriate and timely manner. Perhaps I misunderstand the W3C process and Brent is free to ignore consensus, but I'd appreciate clarification from staff as this is not the first time that I've had a different interpretation than Brent of the role of consensus within W3C working groups.

What is clear to me is that this merge does not represent consensus. As such, I expect multiple contributors to this discussion WILL formally object should this be the language actually proposed.