Deliverables #27
Deliverables #27
Conversation
Signed-off-by: Brent Zundel <[email protected]>
Signed-off-by: Brent Zundel <[email protected]>
index.html
Outdated
| The <a href="https://www.w3.org/TR/did-spec-registries/#did-methods">DID Specification Registries</a> contains many links to examples of DID Method Specifications, some of which may be selected by the working group for development into a Recommendation. The group might also choose a similar starting document not listed in the Registry. | ||
| </p> | ||
| <p> | ||
| It is not intended that any DID Method Specification adopted by the working group will advance beyond <a href="https://www.w3.org/2021/Process-20211102/#RecsWD">Working Draft status</a>. |
There was a problem hiding this comment.
Suggest "developed" instead of "adopted".
There was a problem hiding this comment.
Your recommended changes have been made. Could you re-review?
|
As I argued in a different PR #20 (comment), this is an innappropriate adjustment to the charter, which does not have consensus support of the current working group. I'll repeat my comment here, as neither of the individuals I flagged for engagement responded:
Yes. There was not a consensus on the call, as acknowledged by @brentzundel:
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 [explicitly] 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 close this PR without merging. It does not represent the consensus of the group, nor is it a good idea. @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 [change to the charter] does not represent consensus. As such, I expect multiple contributors to this discussion WILL formally object should this be the language actually proposed. |
index.html
Outdated
| <p class="draft-status"> | ||
| The <a href="https://w3c-ccg.github.io/did-resolution/">Draft Community Group Report</a> | ||
| </p> |
There was a problem hiding this comment.
I am not sure what the intention is here for this. Do we want to say that this is the starting document that the WG will use (I presume that is the case). Then this should be spelled out.
|
@jandrieu I do not want to interfere with the internals of the WG. I was not part of the discussions (not being on the WG any more), and it would be inappropriate for me to take sides. I can, however, comment on the current charter proposal. 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. The (by now overruled) FO on the DID PR was around methods, more exactly the existence or not, eventually, of some basic, standard methods to ensure/prove interoperability. I think that if a WG charter is submitted to the AC for approval without even referring to this problem, it will be formally rejected by the same parties on whether agreements/consensus have been broken or not. That is the reality we have to face. At present, the text does say, in relations to the methods:
which means, in practice, that either this WG has to be rechartered to handle those, or a separate WG has to be formed for it. Which is very close to what you say in your comment:
Maybe the text has to be more explicit along these lines: the WG's job would merely be to start the W3C process by publishing a WG Draft for such methods, and hand it over to a W3C AC vote via a new (or revised) charter. I believe, however, that something like that should be part of the charter. |
Co-authored-by: Pierre-Antoine Champin <[email protected]>
|
Folks are welcome to review the W3C Process for creating a charter here: https://www.w3.org/2021/Process-20211102/#WGCharter There are no WG consensus requirements in establishing the text of the charter. Even so, feedback from WG members has been invaluable in shaping this charter, and has resulted in a significant softening of some proposed deliverables and the introduction of others. If approved, the WG working under this charter will still not be able to publish any DID Method Specification as a recommendation. This charter gives participants the flexibility to begin developing an end to end interoperable solution for DIDs, whether that path is DID Method specifications, DID Resolution, or both. Flexibility in the charter does not require a group to perform any work. Consensus must be found by the WG for any items developed in the WG, regardless of what the charter allows. 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. For this reason, this charter enables that conversation and development to occur in the WG. The time and place to have the conversation about whether the charter meets the needs of the W3C is during AC review. |
|
@brentzundel states that members of the WG do not have consensus on the charter as worded, and that no DID Methods are at risk to be standardized if that remains the case after further discussion. There is absolutely no harm whatsoever in respecting that result through continuing the current discussion and changing the charter to remove the inevitable contention. This forum is appropriate. Removing the inevitable contention is possible under @iherman's constraint to not cause another [unaddressed] formal objection, because there is a technical route to 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. Although a push to get the standard approved based on specific DID Methods being standardized (in a currently non-normative manner) would meet the exact wording of the formal objectors' requests, it is not the only way to meet the spirit of their request to deliver further implementation guidance. If that narrow vision were technically necessary to proceed, then this would be a technical argument instead of an argument about whether consensus is needed at this point in the process. There is a cost to fulfilling the letter of the prior formal objectors' requests. The cost comes in how others understand the specification, and what they think it means to implement it. This confusion persists within the WG, and by standardizing DID Methods (currently non-normatively) in this WG to speedily address that and other concerns in a bundle that keeps things moving forward, it will enshrine the confusion, resulting in a weaker specification when its intent is violated. Further, in no small part due to the proposed enshrinement of blessed DID Methods, those will not be the only two DID Methods chosen for special treatment. On the one hand, there is a reputational cost to unpopular DID Methods, whereas on the other hand, there is a free reputational handout to those DID Methods scheduled for the group's consideration. That will be not for any technical reason of competence or incompetence, but instead for reasons of the work schedules and willingness of planners on this working group to take on that DID Method's specification under its name. That is politics, and it will inevitably turn toxic. You are seeing a symptom that it already has, learned by this respondant when participants lined up in meeting after meeting to make supporting and disparaging comments about DID Methods, as if reassuring each other about the pecking order. My request to not take on this DID Method specification role respects that politics is typical human behavior emergent from the default process, and is grounded in a believe that a charter we can agree on will keep the process more professional, more capable of achieving its decentralized intent, and thus more respecting of human rights around the world. DIDs will fulfill their mission of decentralization better by this DID-WG not taking on the task of developing DID Methods. My understanding is that there would be enormous pressure to further a Working Draft in its current WG. I am responding to that inevitable pressure now, by suggesting we move the contemplated DID Methods now. Thank you for your thoughtful comments here and on pull 20. To everyone, in conclusion: 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. |
|
I have to say I have some sympathies for @jandrieu 's and @rxgrant 's concerns about elevating certain DID methods above others, and adding an element of centralization. We don't want to give the impression that some DID methods are more "important" or "required" than others. What about @iherman 's comment:
Perhaps this would be an acceptable compromise? If the DID WG were allowed to work only on WG drafts (not recommendations) for DID methods, then perhaps that could address the FO's concerns by demonstrating interoperability with a few example methods, while at the same time not elevating them too much? The DID WG would only be yet another place where DID method specs can be developed, along with the CCG, DIF, or anywhere else. In any case, we must never have any language in DID WG documents that certain DID methods are required to implement and others are not. |
Not surprisingly, I come to a different conclusion reading that W3C Process document. The new charter is work of the working group, as recently and explicitly stated by Xueyuan Jia in their email December 15. https://lists.w3.org/Archives/Public/public-did-wg/2022Dec/0000.html As such, it is subject to consensus. You could, of course, propose a charter that is NOT the output of the working group, but that is not what is happening here. Per section 5.2.1 https://www.w3.org/2021/Process-20211102/#Consensus
and
and this gem
This last one is important, because I believe you have gone on record acknowledging a lack of consensus. It is important to note that multiple, independent parties opposed this language from its initial proposal. These objections were raised in the appropriate manner in the appropriate time and you, as chair, have chosen to ignore the dissent. In #20 (comment) you said
And then, in this PR thread, you said
Taken together, it's clear that you acknowledge there was not consensus on this issue and that, in your opinion, consensus has no role in this charter development. This is not the first time that when asked directly about consensus you have failed to reaffirm the fundamental role consensus plays in the W3C. Instead, it appears that you are, in fact, violating process by disregarding the legitimate objections of multiple participants in the work of the working group. The process document also gives you rather broad power: https://www.w3.org/2021/Process-20211102/#managing-dissent
However, that is leavened by the following paragraph:
and further in discussing how to respond to objections https://www.w3.org/2021/Process-20211102/#formal-address
To date, there have been ZERO technical arguments for why this charter needs this language. The arguments have all been allusions to off-the-record statements by individuals involved with the formal objections to the DID Core specification. You yourself said:
No documentation about these conversations is provided. No emails, no github issues. Further, the justification given is not a technical reason and therefore is not an valid rationale for ignoring the express dissent of multiple participants in the work. Nothing in your comments to date meets the definition of a substantive response. You also said (in this thread):
Interesting comment. Certainly, if it makes it that far with this language, there are multiple members who will be objecting formally. However, I take exception to the notion that this working group, in this repo, in this PR, is somehow NOT the time and place to have this conversation. Seems to me the development of a follow on charter by the prequel working group is EXACTLY where we, as a working group, use W3C processes to forge a consensus for the work ahead. In fact, I agree that the larger chartering conversation--starting with the working group and continuing into the AC once a call for review is made by the director--is where we should be setting the scope of work. The idea that we are not committing the group to developing any specific method (because we don't really think that any particular method will achieve consensus once the WG gets into discussion) is on its face, preposterous. The place we should NOT be debating whether or not to produce a deliverable is during the working group. The group should be producing the deliverable, not debating whether or not to do so. Yes, the group can always decide not to do stuff, but the decision about the scope of the group is the fundamental role of the charter. And the place to have the chartering conversation is, IMO, during the drafting of the charter. Which is now. @brentzundel I believe you have consistently refused to remove this language from the charter, despite acknowledging a lack of consensus. Your reference to the process document suggests that I should turn there for remedy. Personally, I'd rather avoid the operational and optical quagmire of a formal objection to this language in the output of the working group. Is that really what you are suggesting? I find it particularly challenging that as a W3C chair, you are actively choosing to ignore consensus in our work. That really is the fundamental role of the chair. Unfortunately, instead of constructively integrating the objections when raised, and re-raised, you assert that because you're the chair, (with privileged access to secret communications) you don't need to respond, that we don't need consensus. That doesn't seem appropriate to me. If it turns out that the director and the AC, in the fullness of time, agree that we should not charter a DID WG without including scope to muddle around in a non-standard track DRAFT DID methods, I would accept that on its face, and propose instead that we charter a DID Resolution WG with the authority to publish an updated DID Core specification. There have been no objections to a DID Resolution WG at all, and no semantic reason to expect that such a group would itself develop DID Methods. This really is the cleaner option: separate groups for resolution and specific methods. If changing the name of the proposed group helps, we should do it. It was clear to me at TPAC that while there was contention about developing DID methods--and zero agreement on any specific DID method--we had exceptional agreement on the value of DID Resolution as the next big step towards interoperable methods and that interoperability was the fundamental concern of objectors. The suggestion (from either the director or an objector) that a future did method might help was a suggestion for how to address interoperability, not a specific technical concern. That was a well meant suggestion, but one that was an mistaken idea based, frankly, on legacy centralized thinking. I don't recall if it was explicitly put in these words, but the sense that I had coming out of those meetings is that interoperability between methods is not going to be advanced by promoting any particular method, but rather by standardizing the interface for resolving DIDs that any method can (and maybe MUST) support. The work of a building a decentralized architecture isn't to champion particular substitutable design choices (that's the hallmark of centralization and monolithic walled gardens). Rather the proven pattern is to define the interfaces that enable any client to access any method that supports those interfaces. This is how the Internet and the Web enabled anyone anywhere to build any application and STILL have interoperability when different browsers visit different sites. We will have succeeded in realizing the dream of Decentralized Identifiers when any wallet can use any VDR to secure any kind of cryptographic method for verifying interactions related to a DID, just as any browser can visit any website. That is decentralized interoperability. We'll get there by defining protocols and interfaces that everyone can implement. We won't get there by focusing on the isolated work of any specific method. Subordinating the work of resolution to prioritize specific methods over others is a horrible centralization that undermines the entire point of this work. We have a really amazing operationally distributed, but organizationally hierarchical system for identifiers. If you're good with centrally controlled governance in your identifier system, JUST USE DNS. We are here to create an alternative to that for use in scenarios not currently supported by the Web, thereby extending the Web into fully decentralizable applications (instead of the hybrids currently in use by Web3 and Web5). Frankly, until we have DID Resolution addressed, we have no business standardizing specific DID methods, as made evident by the lack of methods suitable at this stage. When TBL created the Web, the standard was the data model and protocols, NOT the personnel directory application he built at CERN. It is the intersection of the myriad of DID methods that we should be standardizing, not any particular method. Not at this time. IMO, the work of figuring out resolution should be the focus of the group. This is the consensus I wish you would shepherd as chair. |
|
Here are my 2¢, as team contact and relatively recent member of this group:
(additional edit: remove capital M in "DID Methods", as this might look like the title of a possible specification, which is not the intended meaning here) |
|
Pierre-Antoine, I like the final sentence you suggest very much.
=Drummond
From: Pierre-Antoine Champin ***@***.***>
Date: Wednesday, January 11, 2023 at 9:41 AM
To: w3c/did-wg-charter ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [EXT] Re: [w3c/did-wg-charter] Deliverables (PR #27)
Here are my 2¢, as team contact and relatively recent member of this group:
· we clearly didn't manage to reach consensus here. In this situation, the process allows chairs to record dissent and move forward. This is a last resort, this is hard on everybody, but this is where we are now.
· There is documented evidence that we were requested, or at least strongly encouraged ("should"), to include DID methods in the next charter: see the last paragraph of the Director's decisions to overrule the FOs: https://lists.w3.org/Archives/Member/member-did-wg/2022Jun/0001.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FMember%2Fmember-did-wg%2F2022Jun%2F0001.html&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C888f27058f7047fc61fe08daf3fb159a%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638090556965138595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aYag8SYiGEyCXxwlM6Kkj5qHY2D%2BpR3srALNny6wRzk%3D&reserved=0>
· Considering the two points above, the chairs' decision is in fact quite balanced. It does not blindly follows the directors and the objectors recommendation, but defers the decision (of specifying or not DID methods) to the future WG. And it still limits its ability to do so by restricting such specifications to WD level.
· In order to make things even clearer, I would suggest to rephrase the last sentence of the intro, from
The WG will also seek consensus around the specification of DID Methods and DID Resolution.
to
The WG will also seek consensus around the best way to achieve effective interoperability, through the specification of DID Resolution or DID Methods.
—
Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdid-wg-charter%2Fpull%2F27%23issuecomment-1379253408&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C888f27058f7047fc61fe08daf3fb159a%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638090556965138595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z2IJYD%2BzTmemZetju%2BS%2FzpmMX5PP0U2Vm3%2FiYbYPCGw%3D&reserved=0>, or unsubscribe<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAZOITKTFGHU3OD5C2N4GKTWR3WE5ANCNFSM6AAAAAAS7DCN3Q&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C888f27058f7047fc61fe08daf3fb159a%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638090556965294852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j0ztCdjgRrWp8xw8dJaKqJ%2BDw5VghGiaBAS9Ykt1Gf0%3D&reserved=0>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
The process of international standardization requires active participation and collaboration from all stakeholders, including those who may have objections to the proposed changes. In the case of this pull request, 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. Furthermore, the fact that the objections are secret (I do not have access to them as I am an "invited expert") makes it difficult for the community to understand and address them fully. It is important for all stakeholders to have transparent access to the objections and concerns that may impact the standardization process in order to have a fair and inclusive discussion and make informed decisions. Finally, standardization is a continuous process — it's important to consider if standardizing any DID methods today will have the ability to evolve and adapt to the changing needs of the future. In light of these concerns, it would be wise for the working group to deny the mandate for including DID methods in the charter until the parties mandating their inclusion actively and supportively participate in the standardization process. Additionally, rephrasing the language in the pull request to reflect that the working group "will seek consensus around the best way to achieve effective interoperability, whether through the specification of DID Resolution or DID Methods" is technically premature. There is a serious risk this would elevate certain methods over others and thus actually hurt interoperability for those methods that don't tow the dominant line. Thus I support chartering of a DID-Resolution working group first, rather than continuing to work on a DID 2.0 WG charter. |
|
I might suggest adding "possibly" to @pchampin's, i.e. —
@ChristopherA — I think your suggestion of "chartering ... a DID-Resolution working group first, rather than continuing to work on a DID 2.0 WG charter" along with your other concerns as stated here would be better raised as one or more independent issues, as they are not just about Deliverables (as this issue is), but rather about the entirety of this draft DID 2.0 WG charter. |
@pchampin For the sake of this discussion, can you please quote the relevant section of that document? It is not available to everyone in the discussion. |
|
The concluding paragraph of the Director's decision start with
My understanding is that there is consensus in the group that interoperable implementations can be demonstrated without standardizing DID methods (but focusing on DID resolution instead). That is the spirit of the amendment I proposed for the charter introduction. But I consider (and I believe that others in the group do as well) that plainly ignoring this recommendation from the director amounts to painting a target on our back. |
|
@pchampin Thank you for providing the relevant quote. Also, thanks for acknowledging that this matter is subject to consensus. I also appreciate the nuance that chairs have wide flexibility to respond to dissent, as we both have pointed out. However, I remain unconvinced that what has happened here meets the intention of the W3C process. Quoting from the process document:
This was not done. The proposal that had the weakest objections within the group was to focus on DID resolution in the next chartered group. And
There has been no technical discussion of this matter, only political. Not a single technical reason was offered as to how a DID Method specification would advance interoperability or improve the work in any way other than deferring to objectors. Then, later in The Process, in the language that will no doubt become relevant after my anticipated Formal Objection is made:
Again, no technical arguments have been made for the decision made by the chair. IMO, there has been nothing offered that a W3C reviewer would generally consider to be technically sound. In particular, I note that HTML and HTTP were standardized without the bottleneck of standardizing any particular kind of website. There never has been a technical basis for this demand from anyone, including formal objectors to the previous specification. I'll note that I have not yet made a Formal Objection, so these last two points don't directly apply. However, I believe they speak to the intent of the process: to resolve disagreement through technical discussion. And my last quote from process:
This has not happened, at least in public, and not with respect to seeking clarification from The Director if he actually intended to force the WG on a particular path, binding the future work of the group to his specific mandate of developing a DID Method. Even his own language uses the term "SHOULD" not "MUST" and yet, current leadership continues to treat is a a requirement without even engaging in technical discussions that could yield a much better result for the entire body of work. One member's official objection was simply quoted as
https://www.w3.org/2022/06/DIDRecommendationDecision.html (the full objection is still not available to the public and therefore not suitable for inclusion in this GitHub discussion). This simple assertion is echoed in the Director's comments you quote, @pchampin, but no technical argument has been proffered about how that will improve the work. Simply that it would be politically expedient to do so. @pchampin you said
It is this unquestionable deference to authorities and individuals not engaged in the work that undermines the W3C's moral authority as a standards organization. There was no call for consensus on any alternatives to the proposed inclusion of DID methods in the charter. The leadership presented the modifications to the charter as a fait-accompli, without engaging the group in a technical discussion about other alternatives. After the informal objections were raised at TPAC, the group had no further conversations about it other than here in Github. We've had no calls, no face to face meetings. Nothing. In fact, earlier in this thread, the chair explicitly asserted that consensus has no bearing on this charter and attempted to shut down the conversation by claiming it is the purview of the AC and not this WG:
Finally, I'd like to address the specific argument that has been repeatedly made to dismiss my concerns:
and @pchampin said
To summarize, the future WG will adhere to consensus, so I shouldn't worry about it. I do worry about it. Not only is the leadership dragging me into unnecessary future investment to prevent this technically flawed suggestion, it is going to embroil the working group in unnecessary argumentation and debate. Since there is no suitable DID method known to the WG, we should make the choice now to remove that red herring from the scope of the charter instead of planting a nuclear landmine that WILL consume precious group resources on a proposal that many of us recognize as a bad idea. Not a single specific DID Method proposal achieved anything nearing consensus at TPAC, and yet, we want to push the group into premature work that will only distract all of us. When the DID WG was first chartered, we kept Resolution out of scope precisely because we were not ready for it. I believe we are ready for it now. THAT's the work we should be focused on rather than running pell-mell into work of DID Method specification that we simply are not ready for. Just as we were not ready for Resolution in the first DID WG. Perhaps more salient than my technical objection is my problem with your presumption that the same leadership that today overrides dissent is going to suddenly behave differently in the future--despite the exact same political dynamics being in play. There is no reason to believe that The Director's statement will change. And no indication it will have any less bearing on the decision of the future chairs in whether or not they respect the consensus--or lack thereof--in the group. What is going to change between now and this future WG? The Formal Objections to the DID Core spec, the letter from The Director on those objections, and the DID WG leadership will be the same then as it is now. If leadership won't respect dissent now because of deference to The Director and those Formal Objections, why should any of us believe the promises that they will respect dissent in the future? The only difference I can see might come from my own pursuit of a Formal Objection, which I have been avoiding as it will undoubtedly be a much bigger and more public battle than this discussion here on this PR. I asked @brentzundel earlier if his comment should be interpreted to mean that I should file a Formal Objection, since the process document he suggested I read says exactly that. He has not explicitly responded to the question, but after voicing both my technical and procedural objections informally in this forum, it is clear that 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. I have done my best to resolve this impasse without that step, but at this point I see no alternative. I've sent a personal email to Brent apologizing for the inevitable disruption that will cause and I want to apologize here as well. We didn't have to go down this path. I still have some slim hope that we might see the merits of a more technically grounded decision, but I respect @brentzundel and @pchampin enough to accept that they believe in the correctness of their position and I don't expect that to change. The W3C is at a cross-roads about how it will manage itself as we transition beyond blind deference to The Director. If the W3C is going to continue to be a relevant technical standards organization, we must find a way to avoid politically driven mandates from both leadership and uninvolved members. If we can't, we will become nothing more than a political organization driven by political mandates instead of technical relevance. If escalating this issue is the only means available to me to address these issues, then I can see no other option but to do so. |
Signed-off-by: Brent Zundel <[email protected]>
|
From what you have written I can only infer that you believe I have knowingly violated process for nefarious means while acting as a power-mad despot. In spite of all of the statements I have made to the contrary, the actions I have taken in the best interest of this work, and the years that I have spent alongside you in this effort, it appears that I am now not to be trusted and that you have lost any confidence in me as chair. I admit the possibility that your understanding of W3C Process is better than mine, though I sincerely do not believe that to be the case. This charter is not a DID WG deliverable. It is not on the standards track, nor is it a WG Note, nor is it a registry. Thus, the strong demands of WG consensus on its contents do not apply. Consensus comes into play somewhat as it is drafted, but primarily when it is presented to the AC for its consideration. It may be that I am mistaken. If that is the case I welcome being educated. The changes to the charter to bring DID Method Specifications into scope were made in response to Issues #1 #13 #14 #15 #16 #17 and #23 It is clear that there is interest among current members of the DID WG to explore the standardization of DID Methods in the next DID WG. It is clear that there is an expectation after the Director's response to the formal objections to the DID Specification that the next WG would explore the standardization of DID Methods. It is also clear that it is completely unacceptable to a a number of current DID WG members that the next charter make the merest mention of standardizing any DID Methods. DID Resolution was introduced to the charter as a response to #24 It is clear that there is interest among current members of the DID WG to explore the standardization of DID Resolution. There is no consensus at this stage, nor do I believe it is possible to achieve it. I have tried, as skillfully as I am able, to weave these utterly contradictory demands into a charter that leaves the ultimate decision of where to take the work up to the next DID WG. Which is where the decision belongs, in my opinion. In light of highly likely formal objections from either side, I had hoped to construct a charter whose text is least likely to be objected to, one that would be broad enough in scope to satisfy detractors while remaining loose enough in requirement to allow the next DID WG to have the choices it needs to properly steer this work. It may be that I have failed. The time may come when the charter is presented to the AC to see if there is consensus for the W3C to accept the it and re-charter the DID WG working group. That is where the process of W3C comes into play regarding charters. So yes, if the text of the charter is not acceptable to you when it is presented to the AC for a vote, I expect you to formally object. Just as I expect others to formally object if the charter text is not acceptable to them. |
|
To be clear, I am considering a formal objection (as a member of this WG and prior to any future AC deliberation about the charter itself) should there be a chair decision to merge this PR. If merged, it would have been merged for political reasons, driven by perceived and unattributed fears of non-members of this group. The AC, once they have received our WG draft charter can choose to override us to add this requirement back in after their own deliberation (and clear attribution of who is saying what). However, as is, this PR does not represent our LOCAL working group consensus nor is it a reasonable compromise. Overriding that lack of consensus is the core of process violation that I will object to. |
On the contrary, Brent, I know you are acting in what you believe is the best interest of the work. I just disagree with you, and I'm exercising my rights as a participant in this group to register my objection informally in this forum, and will do so formally only after having exhausted all possible options of open discourse. I've gone to great lengths to explain my position in the most respectful manner possible, taking my time to think through language that would clarify without attacking. I knew that was going to be a nearly impossible task, and clearly I've failed, despite my heart-felt email apologizing for the path we're headed down. I was asked at TPAC if I would formally object. I've done my best to avoid that, but my arguments have not been convincing. I can accept that. We are a collaborative working group. My opinion is not the only one to shape group decisions. I have found myself in the minority more than once and I stand by what I've said every time its clear I may be speaking contrary to the general sense of the group: If I'm the only voice, I have no problem yielding to the consensus. In this case, however, I was not a lone voice. Even in your most recent reply, you continue to hold positions I find in error. First, that this work is not subject to consensus. Please re-read @pchampin's comments. This entire repo and the WG meetings we've had to shape the charter make it the work of this working group and subject to consensus. This is not work that you (or your allies) have developed in isolation for proposal to the W3C. It is the output of this group. Second, that the politics of prior Formal Objections preclude even having a technical discussion in this forum. That's not a path for technical collaboration, certainly not one aligned with the culture and ethos of the W3C. The complete lack of technical debate, entirely due to political concerns, is contrary to the very point of the W3C. Third, that an interpretation of a suggestion made in The Director's response should override the consensus of the working group as it shapes its own future. I don't believe this was the intention of The Director and even if it was, he should be voicing that opinion here, in the group itself, so that we can debate the technical merits of different approaches. Blindly following what we believe he may have meant is not an appropriate way to develop technical standards. At least one of the benefits of the Formal Objection process is that it will include bringing The Director into the conversation so we can, in fact, present the technical case. I would like to clarify one additional thing, however. My formal objection will be to the Chair Decision on overriding dissent. Please read the process document you referred me to earlier for details. Should I fail to prevail in that effort, I will take my case to the AC, as you surmise. I may not succeed, but I will use the avenues provided for me within the W3C's process to oppose the decision to include DID Methods in scope of the next WG. I've tried everything I can to avoid making a formal objection because I believe the required inclusion of that Formal Objection in the AC's consideration will make it even harder to overcome the objections of those organizations who, frankly, are going to oppose this work no matter what we do. Unfortunately, I think it would be far worse to empower the next WG to waste its time on work we simply aren't ready to undertake and which risks the very decentralization we are trying to achieve. I don't think there is much more to talk about in this forum, but I wanted to tell you this isn't personal, Brent. I don't believe you are "a power-mad despot". You're a good guy trying to resolve what to you seems unresolvable. I also hoped to correct your misunderstanding that the formal objection I'm talking about will be part of the AC process of considering the charter. Please do take a look at the process document. I believe the details of Formal Objections to Chair Decisions are well outlined. |
The idea does not address the pressures cited to @iherman. Also, are these DID Methods going to achieve anything in unfinished state? Don't the examples already exist in unfinished state?
This proposed "consensus" does not remove the non-consensus part about DID Methods. It does not carry the spirit of consensus given the objections that are being raised here. You excuse this in your next point:
The Director is plainly knowledgeable about the needs of implementers and would like this WG to address their concerns, while affording this WG the benefit of the doubt on the historical plan to define the data model before the network layer. However, if the Director has said "how" to resolve the prior-FOs then I believe they have made a technical overstep; since their distant relationship to the issues should only have them suggest "what" this group should address. Because of this, the Director's recommendation should be interpreted through this group's consensus-seeking understanding of the relevant issues, taking into account the spirit of the "what" to address. At present, that may only be achieved without new formal objections by focusing the charter on DID Resolution and removing the need to fight the selection of preferred DID Methods in the WG. For those who technically disagree that a completed DID Resolution specification can assist implementers as recommended by the Director, state your reasons!
Now that this is obvious, the solution is also obvious: heed these current FO warnings and schedule DID-WG meetings to seek consensus on the charter, in a way that satisfies the members interested in decentralization and the spirit of the Director's request, thus affording the prior-FOs no merit in subsequent objections. Lastly, I am against further enabling arguments opaque to the public, which includes reports of what the prior-FOs are thinking as delivered by go-betweens. Lack of transparency is contributing significantly to the failure of this WG to achieve consensus. I notice how little some of the prior-FOs engage with the group and offer that their direct engagement, putting forth their technical arguments, would be a much (much) more respectful way to reach understanding. Thinking the issues through while directly addressing other humans is special. |
brentzundel
requested review from
pchampin,
philarcher,
selfissued,
shigeya and
TallTed
|
Thank you @brentzundel I appreciate the opportunity to have a technical discussion about the merits of the two approaches. I'll chime in over there. |
|
While I'm not actively invested in this discussion I figured I'd weigh in on this topic based on my current understanding. Personally, I prefer this approach of including DID Methods and DID resolution as the main focus in the upcoming WG. As it stands today even with a perfect DID resolution and dereferencing protocol established we'd still likely end up with a non-interoperable solution because DID Methods as it stands today are too extensible. Say for example we only defined an HTTP method for DID resolution and DID dereferencing (for the sake of the argument) we'd still end up with a problem around interoperability because the caller is unlikely to be able to parse the results returned by resolution or dereferencing algorithms because the methods are too wildly different. Let's put the argument of content types aside for a second and compare just did:schema, did:indy, and did:key on the following 3 features: key resolution with verification methods, arbitrary JSON resources resolution, and time of resolution. Key resolution with verification methods:
arbitrary JSON resources resolution
time of resolution
The point here is to bring out that even if did resolution and did dereferencing was perfect and simple because of the vast differences between methods you'll still end up with non-interoperable solutions unless the caller of the resolver/deferencer is doing content sniffing of the actual object returned. I find it hard to believe that you'll be able to constrain this enough if you only define resolution and dereferencing and believe you'll be required to shrink the "big tent" in order to make this actually work interoperably. For this reason I'd be a +1 to including both in the charter so that further method constraints can inform further resolution and dereferencing constraints in order to get closer to an interoperable solution. I would be a -1 to only defining the resolution and dereferencing constraints because I believe that it would be setting this WG up to producing a half solution and further reduce the possibility that this spec becomes widely adopted. |
There was a problem hiding this comment.
It seems to me that the prior VCWG DID WG did not do any work on any DID methods only because such work was declared explicitly out of scope by the charter. We did a great deal of work based on hand-waves of "we hope DID methods will work the way we think they will" which (I think) would have been easier and far more complete had we been able to try some things out, even just as basis of a NOTE from that WG, but such trials were forbidden.
(No, WGs cannot disregard what's in their Charter, neither what is labeled "out of scope" nor what are listed as deliverables, even if there is 100% acclamation for taking such a tack. There is some flexibility with failing to produce all deliverables, because WGs always bite off more than they can chew, and it is sometimes possible to re-charter before the WG's end-date, to bring "out of scope" into scope — but neither of these is a free-for-all.)
The sentence which underlies this HUGE thread is simple:
The WG will also seek consensus around the best way to achieve effective
interoperability, possibly through the specification of DID Resolution
or DID methods.
(and I've suggested changing that last line to and/or DID methods ... but I approve of this PR, with or without that change)
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 that's currently discussing this "PROPOSED Decentralized Identifier Working Group Charter" have talked about as both desirable and likely to be needed.
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.
I seem to recall that several of us put a lot of work into a thing, what was it called... Oh, yes! The DID Method Rubric v1.0. That thing should be able to help guide prospective users, deployers, and others, toward choosing the best available DID method for their needs, as well as designing and implementing a bigger, better, faster, more DID method, should they have partially or fully unmet wishes.
In case it's not clear, I'm in favor of keeping the option to work on DID Method Specifications in scope. I've tried to understand why we should explicitly put that option out of scope, but I just can't see it. Doing that was problematic from start to finish of DID-WG-1. I don't see how it would be any less problematic for DID-WG-2.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
That is such an false assertion as to be deceitful. There was no work on DID methods because there was never any consensus to do so. Full stop. This is also the case today.
This is also not true. I can't speak to a definitive count at the chartering of the working group (Sep 2019), but To say that we were hand-waving and unable to "try some things out" is an unfortunate restatement of historical fact. We had multiple independent implementations of working DID methods from the very beginning of the working group. The group has no need so specify a method because the entire goal was to support any and all methods that the various contributors to the work HAD ALREADY DEVELOPED and continued to develop throughout the process. Real implementations guided the work, where people were, in fact, trying things out.
And several of us have talked about it being undesirable and unlikely to be needed. The lack of consensus is not in question. Both sides have talked.
That's a strawman restatement of the problem of the WG working on DID methods. The problems is that the ability for anyone to create their own DID method is key to how DIDs are decentralized. If the group itself takes up the task of building a specific method, it will, by shear consequence of attention, unduly influence the development of the core specification itself. As @OR13 put it in a comment in the BBS2020 repo:
It is not possible for the WG to equally consider all current DID Methods, despite that being a worthwhile goal. Necessarily, the core spec will reflect the interests of those parties who can actively participate in discussions. This is an unavoidable bias in the space. Putting any specific DID method in scope for the WG will necessarily increase the bias the group has, simply by needing to understand how that DID method does things. To support the fundamental goal of decentralization in Decentralized Identifiers, it is imperative that we accept the input from all legitimate implementations equally, whether those methods are developed by the W3C or not.
Yes. I created that. I'm one of its editors. I also run a podcast where we interview DID method creators and implementers (https://rubric.cc). I know the breadth and scope of DID Methods better than most (with a polite hat-tip to @peacekeeper and his team on the Universal Resolver who certainly know more). The myriad of approaches to DID methods is a core strength of the architecture. Giving authority to the DID WG to pick a winner amongst that set will inevitably reduce both diversity and interoperability.
I appreciate that you have a different opinion. Do you have technical reasons to oppose pull #29? Do you find it so objectionable that you anticipate filing your own Formal Objection should it prevail? Because that is the question. According to the W3C process document,
If you have such a strong objection, it would be useful to state that for the record. |
| @@ -80,7 +80,8 @@ <h1 id="title"><i class="todo">PROPOSED</i> Decentralized Identifier Working Gro | |||
| <a href="https://www.w3.org/2019/did-wg/">Decentralized Identifier Working Group</a> | |||
| is to maintain the <a href="https://www.w3.org/TR/did-core/">Decentralized Identifiers (DIDs)</a> | |||
| specification and related Working Group Notes. The WG will also seek consensus | |||
| around the specification of DID Methods and DID Resolution. | |||
| around the best way to achieve effective interoperability, possibly through the | |||
| specification of DID Resolution and/or DID methods. | |||
There was a problem hiding this comment.
This language seems correct to me, based on the experience of managing the did spec registries, and having written many of the did core test suites.
There was a problem hiding this comment.
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.
For a similar specification that is doing well without defining a specific "instance / node / network" see https://www.w3.org/TR/activitystreams-core/
I'm not even going to read the rest of your comment. Regarding the specific of my assertion (where I did accidentally name the VCWG, which I've now corrected to the DID WG), I suggest you reread the charter of the soon-to-expire after multiple extensions DID WG, where you will find the following:
I'll thank you to never again call me a liar, and to reread and try to live by the CEPC. |
|
Would it be possible to be kinder and more respectful to each other? I understand that people care about the topic, and I think that's is wonderful but strong language and disrespect really demotivates some of us from engaging in the discussion. Thank you |
|
To respect @Sakurann's call for civility, I shall do my utmost to be polite in responding to your statements, @TallTed
If you choose not to even engage in a conversation by intentionally refusing to even read my comments, I would suggest that it is you who are not treating me and my contributions with respect.
Yes. I looked that up before I made my comment. Your presumption that I should re-read it is disrespectful of the work I have put into this issue. Believe me, I read the charter. What you said is:
For simplicity, I will refer to the phrase "only because such work was declared explicitly out of scope by the charter" as the assertion in question, or simply the assertion. To be fair, your literal words may be a true statement: that it "seems to [you]" that the assertion is true. But what seems to you to be true does not make it true. In fact, the assertion is not true. The reason that method specifications were out of scope was because there was no consensus that we should develop any specific DID methods. That reason existed before it was formalized in the charter. It existed during the lifetime of the group. It exists now. There is no consensus that we should develop DID methods in the DID WG. To say that the only reason is because it was in the charter intentionally denies the very existence of the actual reasons WHY that language was in the charter. That is why my reply started with "That is such a false assertion" Your language choice, the hyperbolic "only because", and the italicized emphasis of the assertion itself is why I added "as to be deceitful". I stand by that evaluation. The assertion was not true on its face and your contextual language placed such emphasis and gravity on the weight of that assertion as to meet my sense of deception. I can appreciate that you might make an error. However, when the presentation of a false statement gets elevated to a strident call as justification for your own position, I consider that a willful misrepresentation of facts to advance your own interests. In other words, a deceit. You are not the first person in one of my W3C collaborations to intentionally rewrite history to favor your argument. I'm sure you won't be the last. I only hope that I will continue to have the patience and wherewithal to challenge those future manipulations as I have yours.
I would encourage you to spend some time with the CEPC as well. I did not call you a liar. I called your statement so false as to be deceitful. I did not call you any names. I commented on the outrageousness of the words you chose to use. Words I believe were chosen to establish a falsehood as a fact. In particular, I want to call you attention to this section of the CEPC:
You made two false statements in your comment, which I called out as such. Without calling you a liar. Without attacking or disrespecting you personally. Your statements were false. If others calling out your false statements offends you, please refrain from making false statements. Those of us who do remember our shared history will call you out on them. I do apologize for not finding words that might have landed my comments more gently. My passion for the truth sometimes leads me to speak roughly. However, I stand by the factual accuracy of my comments and I ask you to be more attentive to the truth in your future conversations in W3C forums. |
|
Difficult situation. I think I slightly prefer this PR over #29, because
Even though I really understand and share concerns about "picking favorites", I feel that the flexibility to potentially have DID methods in scope could be helpful. Perhaps during the WG's lifetime someone will magically come up with a new DID method that nobody has thought of before and that everybody supports enthusiastically. Remember that since we started working on DIDs years ago, we have again and again been surprised by innovative new DID methods. Or perhaps the WG will just write a trivial example/dummy DID method, solely for the purpose of demonstrating interoperability. This PR would make it possible, the other one wouldn't. I also support @kdenhartog 's comment #27 (comment) insofar as "standardizing DID Resolution" may not be the "solution to everthing" by itself, even though this step seems to have broad support and is definitly valuable. |
|
@peacekeeper I love your comment.
This seems like a good idea, but it actually raises the difficulty level for the WG... because it allows for us to "split" our focus, and part of where that focus might go, will only benefit a "specific" did method. It leads to solving for (parts of or all of) interoperability, by conforming to a single method... which promotes that method, above all other methods. |
|
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. Now, regarding the other open PRs, #29 and #30:
|
|
I am preparing an appeal to this decision. I have notified @pchampin of this fact and asked for the right party at the W3C for me to work with. |
|
I have filed an appeal to this Chair Decision. @pchampin and @brentzundel have been informed of the appeal via email. |
|
While I'm a little late to this PR, I wanted to make a couple of comments. Although I was initially in favor this PR based on my original understanding, now I'm thinking that I object to it. Here's why: The initial comment says, "Adds DID Methods and DID Resolution to the deliverables section of the charter." On the surface, that seems reasonable, because what good is a DID without a way to resolve it and get the associated DID doc? My initial interpretation was that we would be discussing how to generically access a variety of DID Method types / implementations without standardizing a particular DID Method or implementation. After all, there are many DID Methods listed in the DID Spec Registry (https://www.w3.org/TR/did-spec-registries/#did-methods). Incidently, just the other day, I saw a request to remove the DID Methods section from that document and not have any registry / list at all. However, after reading some of the preceding comments and emailed commentary, it seems like the changes made by this PR could be interpreted to imply that the working group would be standardizing on a particular DID Method(s) and prioritizing it (intentionally or by default) over others. It seems inevitable that if a particular DID Method is described in detail within a standard or repeatedly cited as "an example", then it would become the default one that most implementers would believe that they should support. This would, in effect, elevate one DID Method over competing DID Methods. While it is very useful to describe to implementers that DID Methods have common properties (e.g., addressability, request protocols), I would expect that this would be done generically without implying a particular method, implementation, or provider. Other deliverable efforts could be held to describe specific methods and that would also be useful. So, am I for or against? Given that the text and commentary leave me with uncertainty about what is being proposed, I would need to object until there is further clarification and decide then. Since the PR has been merged and an appeal filed, it seems that the charter is still in a bit of uncertainty. |
Adds DID Methods and DID Resolution to the deliverables section of the charter.
Preview | Diff