New section on environmental impacts

mprorock commented 3 years ago

Preview | Diff

OR13 commented 3 years ago

@mprorock we might want to consider referencing https://www.w3.org/2001/tag/doc/ethical-web-principles/ directly.

cc @peacekeeper thanks for the suggestion.

mprorock commented 3 years ago

cc @peacekeeper thanks for the suggestion.

Excellent suggestion. References added

csuwildcat commented 3 years ago

I'm taking time off for Labor Day, and would ask that this not be merged until more of the community (including me) has an opportunity to suggest changes and submit content. It's important to give this time, because a hasty inclusion of something that lends credence to a fundamentally false narrative backed by spurious arguments and dubious claims could harm the community, implementers, and, by extension, the use of systems that are designed to deliver maximum protection of digital human rights.

mprorock commented 3 years ago

@csuwildcat Completely agree. This is definitely something that we will want to make sure is cleanly included, and also emphasizes the strengths of DIDs in enabling further protection of human rights and other concerns that have broad ethical impacts.

edit to note: I believe that clarifying the goals, technology, and actual capabilities enabled via DIDs should hopefully make clear that the authors and actors in the DID space are acting with GOOD intention and that we wish to continue down that path. Some concerns I have seen raised around DIDs makes it clear that individuals that have not been engaged with or closely tracking the work progress might have missed some of the nuance of a reasonably complex set of capabilities, or have missed the fact that much of the motivation of the community is to promote positive and ethical use of technology.

As well stated by @csuwildcat a foremost consideration in design and use of DIDs for almost every party I have engaged with in the space is to promote "the use of systems that are designed to deliver maximum protection for digital human rights." Further many of us have leveraged the tech to bridge not just protection of digital human rights, but to aid in the prevention of real world human rights abuses such as forced labor, etc.

brentzundel commented 3 years ago

Perhaps out of scope for this PR, but if mention is being made to the Ethical web principles, it may be good to also emphasize the principles that DIDs strongly support, specifically:

The web must make it possible for people to verify the information they see
The web must enhance individuals' control and power
Security and privacy are essential

mprorock commented 3 years ago

@jandrieu Do the changes made in 78abe49 help with your concern?

jandrieu commented 3 years ago

@jandrieu Do the changes made in 78abe49 help with your concern?

In the right direction, although I think it still reads as an attack on PoW by any name. I think the general strategy should be to communicate that there are any number of criteria that both implementers and users should consider. See the rubric for more details.

I'm not convinced that language that is specifically designed to target a particular class of blockchains with armchair economic arguments will be able to achieve consensus, largely because for many of us in this community, PoW is the only solution that actually solves the centralization problem with a truly peer-to-peer solution. I appreciate that others have different opinions about whether or not PoW is innately evil and prefer other approaches. But I won't support the DID WG taking a position on the PoS v PoW v something else debate.

This is the whole point of the rubric.

I believe our best position wrt politically or ideologically charged differences between methods is to offer good questions--those that highlight the differences--rather than amplifying answers from any particular contingent.

mprorock commented 3 years ago

I believe our best position wrt politically or ideologically charged differences between methods is to offer good questions--those that highlight the differences--rather than amplifying answers from any particular contingent.

+1

going to chew on this and suggest some new language. I think the key thing that we need to emphasize is that there are tradeoffs always, and we should be aware of these trade offs, but encourage developers to make sure they are asking the right questions going in.

mprorock commented 3 years ago

@jandrieu I made a few more tweaks and removed some language that might be unclear. Also added some language to clarify that there are multiple high priority items to be considered. Happy to take language suggestions if you have thoughts on further refinement.

OR13 commented 3 years ago

I believe our best position wrt politically or ideologically charged differences between methods is to offer good questions--those that highlight the differences--rather than amplifying answers from any particular contingent.

@jandrieu +1 !

Are there any sections of the rubric you think we should cross link to directly?

Maybe the questions regarding relationship to crypto currencies?

Having worked on both PoW and non PoW based DID methods, I think it is essential for us to unpack why PoW is a better starting point for decentralization, implementers who agree with that rational should be motivated to build on top of PoW systems, folks who don't agree should see that both perspectives have been identified as design choices which implementers will have to make, at least to the best of the ability of working group participants.

Strong decentralization is not free, and the cost is not one dimensional.

Sometimes that cost is 100% necessary due to a threat environment, and sometimes that cost can lead to a method becoming politically unacceptable to some parties, implementers should be warned of this directly, just as we warn implementers of building methods on disputed cryptography (FIPs vs Safe Curves) or of allowing method representations to become different enough to cause interoperability issues (JSON vs JSON-LD).

mprorock commented 3 years ago

note - keeping all conversations other than purely editorial open and not "resolved" for the time being, as this is important and nuanced stuff that we need to make sure we get right.

OR13 commented 3 years ago

@rxgrant

When technical folks don't agree on recommendations for implementers, we have a few options:

Remove the minority perspective.
Include both perspectives and let implementers decide.

We have seen a number of contentions issues in did core, and so far we (WG participants) have tended to prefer option 2, whenever possible.

You appear to be advocating for option 1, in that you are advocating for removing content that you deem extraneous or confusing / harmful that other folks want to see.

In order to unblock this PR, we have a couple options:

Optiona 1

Add issues to the PR linking to the disagreement to every paragraph you want removed and merge the PR once those issue links have been added, moving the disagreement to the issue for each paragraph.

Optiona 2

Add an issue to the PR linking the section, then take your patch moving the disagreement to the issue and continue to work for a solution.

Optiona 3

Take your patch, then add a section of Benefits and Drawbacks associated with a robust review of ESG in a DID Method specification, taking the original PR content and adding it to the benefits section, and allowing over WG members to submit an argument for the drawback section.

I suspect Option 3 will see continued objection, but its my preferred solution... I strongly disagree with this entire section: https://w3c.github.io/did-imp-guide/#drawbacks

But it's still in the implementation guide, other folks did the work to write it, and they think they are correct.

From an editorial perspective, Option 2 is probably easier to manage, here is any example:

Of a similar issue we resolved: https://github.com/w3c/did-imp-guide/issues/5#issuecomment-839223719

Can you comment on these proposed options? Which would you prefer?

OR13 commented 3 years ago

LOL, "stop hitting yourself!"

I'm not sure what you mean by this, but it does not come across well.

rxgrant commented 3 years ago

LOL, "stop hitting yourself!"

I'm not sure what you mean by this, but it does not come across well.

It's calling out that my authorship was imputed to a patch that I disagree with. I don't think that action comes across well.

mprorock commented 3 years ago

It's calling out that my authorship was imputed to a patch that I disagree with. I don't think that action comes across well.

Apologies for attempting to credit you with language you authored. I understand you would prefer the other sections be removed. Just as you object to their inclusion, I object to removing details of the kinds of questions developers should ask themselves. Encouraging the asking of questions should not ever be a concern if the data is on your side.

bumblefudge commented 3 years ago

Feel free to ignore me if I'm off-base, but is the patch crediting/attribution in question just an automatic github feature for crediting people who left reviewer comments/suggestions? i am no github wizard by any means but there might be a way to turn that off or rollback the commit and re-apply it without accepting the suggested authorship-squash thingy.

mprorock commented 3 years ago

Feel free to ignore me if I'm off-base, but is the crediting in question just an automatic github feature for crediting people who left reviewer comments/suggestions?

When stuff trues up and we do an author assessment that is normally the case, in this case I word for word lifted language that was suggested, but not the entire diff. Just to make it clear that the added language was appropriately attributed i included the username callout in the commit message. That is the right way to do it to avoid any issues on who wrote what and to assure that appropriate attribution can be assigned (assuming that the cherry pick from the diff was the only content in the commit, as it was in this case). Otherwise it could appear to someone browsing the history that I authored that language, which I do not want to give the impression of, especially since it was good and clear language and appropriate credit should be given for it.

edit: Note the reverts below which address the request

rxgrant commented 3 years ago

When technical folks don't agree on recommendations for implementers, we have a few options:

Remove the minority perspective.

Include both perspectives and let implementers decide.

I'm reading option 1 as "Remove the contentious perspective".

Please correct me if you actually meant "perspective held by the voting majority" and "perspective held by the voting minority". The culture of Internet standards focuses on consensus of technical merit, in no small part to avoid attacks based on vote packing, as best described in RFC7282 "On Consensus and Humming in the IETF".

We have seen a number of contentions issues in did core, and so far we (WG participants) have tended to prefer option 2, whenever possible.

I don't think it's possible for the editors to single out specific Rubric criteria and then balance things out with DID method developers defending their work in their DID method spec. This is important.

I do think that the TAG principles are non contentious and fair game for mentioning for all DID methods. People who dislike particular DID methods should have a way to express themselves. The Rubric Registry is the right place to lodge criteria.

You appear to be advocating for option 1, in that you are advocating for removing content that you deem extraneous or confusing / harmful that other folks want to see.

I've offered a less contentious patch that meets the stated goals of Section 7.2. Some aspects of the perspective are so non-contentious that the words were added to the spec, although in a contentious way.

(Based on this paragraph I do think you mean option 1 to read "Remove the contentious perspective".)

that other folks want to see

I'd like to address this tail of the sentence above separately. "Other folks want to see" extra requirements and discussion around a narrative that they're not defending the technical merits of in this discussion.

The moral authority of the W3C is about interoperable specifications, so that different software from different organizations can work together. It's imperative that W3C editors work to minimize political and ideological bias.

Can you comment on these proposed options?

Yes, I'll do my best. I'd like a little more time to consider your proposal and how to reply.

rxgrant commented 3 years ago

Encouraging the asking of questions should not ever be a concern if the data is on your side.

Some well-known FUD techniques use "just asking questions". They include:

OR13 commented 3 years ago

I'm reading option 1 as "Remove the contentious perspective".

I meant option 1 in terms of numbers, since any perspective can be seen as "contentious", regardless of what the perspective is, contributors will line up on either side, and may view all or only a small part of the other side as "contentious"...

Hence the need to either include both sides or pick a winner... adjusting without consent one side's argument by eliminating what the other side views as contentious, is the same as removing their argument, and is the same as "picking a winner", imo.

I'd rather see both perspectives be given as detailed logical support as possible, even if technical folks are immediately drawn to belief that one of the perspectives is better argued... the size of the argument should not be used to argue against its purpose.

Some folks think PoW is "worth it" others don't...

We should do our best to highlight that we have considered it, direct folks to the best resources to understand it, and link to the rubric wherever possible, but it's still a consideration implementers ought to have.

I'm personally of the opinion that PoW is worth it... for the right threat environment... but that threat environment is not present everywhere, and there is a cost to securing against a threat environment that a use case does not need to secure against, we should avoid taking the perspective that the "the strongest decentralization" is the only consideration... perhaps hidden in this debate is one of the best arguments in favor of PoW, that should be made clear to implementers... When your use case can't compromise on decentralization / censorship resistance... your implementation should not... your implementation should apply defense in depth and pick the strongest technical solutions for each layer of the stack, signatures, storage, consensus, etc... If technical leaders end with different answers for these layers, implementers should have a guide for considering them.

The obvious next question is: What consensus mechanism is better than PoW for decentralization?

Advocates against PoW should have to answer... one answer might be "downgrade what we mean by decentralized", another answer might be appealing to PoS as having better trade offs...

This is a W3C WG Note, it's not normative, we can take our time to get this right :)

msporny commented 3 years ago

I wanted to take a second to highlight @OR13's entire response above, as it's excellent.

We should do our best to highlight that we have considered it, direct folks to the best resources to understand it, and link to the rubric wherever possible, but it's still a consideration implementers ought to have.

Yes, this is exactly what we should be doing.

csuwildcat commented 3 years ago

I tried to recenter all the sections around the topic of security and more empirical aspects of that issue, as other things logically flow from it. I don't think we should talk about any particular consensus mechanisms, we should just point out the most important aspects of the empirical factors and note that you should consider the security level/budget/strength you feel is required to achieve the protections you seek.

mprorock commented 3 years ago

I don't think we should talk about any particular consensus mechanisms +1

I included the mention of proof of work in the original state to reflect broader criticisms that had been made by the community at large, but feel that focus on POW or POS is a distraction in many way. This is especially true as, if we do our jobs right, get things to a state where this standard lives on as new tech is developed that we might not yet forsee. Even under new tech or approaches for consensus the same tradeoffs will exist. The real question is are we as developers asking the right questions about impacts to privacy, control, environmental, cost, etc and picking the right tool for the job at hand. obviously some cases are going to merit a "throw all the compute we can possibly afford and have the time for" at the problem, for other cases that will be overkill or detrimental for cost reasons alone.

TallTed commented 3 years ago

[@brentzundel] * The web must make it possible for people to verify the information they see

This comes perilously close to suggesting, once again, that VCs somehow provide a means by which to Verify the veracity of the Assertions contained therein, rather than stating clearly that VCs merely provide a means by which to confirm that the Issuer did indeed Issue that VC and that the Assertions contained therein are as the Issuer Asserted them.

TallTed commented 3 years ago

[@csuwildcat] I tried to recenter all the sections around the topic of security and more empirical aspects of that issue, as other things logically flow from it.

"There are more things in heaven and Earth, Horatio, / Than are dreamt of in your philosophy."

You start from security. That's fine. For you!

Others may start from ubiquity, usable on any "computer" sold as such, where your preferred security is unachievable because your string length exceeds available RAM+storage. That's also fine. For them!

rxgrant commented 3 years ago

@OR13

in answer to:

In order to unblock this PR, we have a couple options:

Formal objections to the DID spec have been filed on TAG/EWP grounds, and this pull request was initiated as a reaction to the formal objections. It was also clearly initiated as a way to "throw under the bus" methods relying on proof-of-work as their ground truth, in order to most expediently appease deciders enough to move the DID spec forward.

Not only was this pull request conceived in harm to certain DID methods, but, despite textual changes so far, the process options currently offered by this guide's editors (regarding majority vote on various paragraph changes - see [background1], [background2]) are still designed to guarantee a result that states to developers that:

the consensus of the community represented by this guide is that the allegedly offending DID methods are "second class" due to their alleged issues; and that
developers should set aside prioritizing interoperability and instead consider these warnings while judging which users they want to leave out of "first class" participation on the Internet.

This guide is not now - and will never be - the right place to either address the stated concerns of W3C formal objectors, or offer guidance to foundational DID methods that have already been designed to take advantage of proof-of-work consensus. Separately, it is not now and never was a guide meant to explain to users which DID method they should choose. If you think the concerns in the prior paragraph are overstated, but you also admit that this pull request doesn't inform either eventual end users or developers of already existing DID methods anchored on Bitcoin's massive proof-of-work network, then you may be left agreeing that - whether intended or not - the pull request is laying the groundwork in order to disparage existing Bitcoin DID methods, should someone want to avoid interoperability requirements.

Disassociation from DID methods that allegedly violate the TAG/EWP sustainability principle is not even a good way to convince the W3C's voting members that DIDs are ready to go, because appeasement does not address the critical cognitive dissonance:

formal objectors want more centralized control over this decentralized architecture.

This emergency deviance from the normal technical mission of the W3C - to foster interoperability - is supposed to act as gatekeeping to prevent developers from choosing "the wrong way to be on the Internet" for their users, thus affecting greenhouse gas emissions. The stated reason that the formal objectors feel the need for that control is also under factual dispute (but, strangely, not refuted in this thread when it was claimed that DID method anchoring does not measurably affect the hashrate of Bitcoin at all). Pointing out errors in the assumptions of the formal objections is not a matter that this pull request is - or could be - attuned to address. The argument has deep roots involving motivated attackers as well as deeply planted ignorance from years of dramatic-yet-misinformed news stories, stale statistics (including from Cambridge, which one formal objection indirectly linked to), and fundamental uncertainty due to the global scale and pseudonymous operators. This guide can't reasonably incorporate those details, and that is why those who try to force the task into this guide are by necessity going to do a bad job of it.

The proper action for this community at this point in time is to keep calm, stand by the consensus mechanism for writing good specifications, stand by the decentralization and inclusion that decentralized identifiers are offering, and allow those most affected by the formal objections to pen comprehensive formal replies for review by W3C-CCG and DID-WG.

As a reminder, I have offered a patched section 7.2 that:

does not use fearmongering about how much additional carbon emission a few anchoring transactions will cause;
does not suggest that there is some clear threshold regarding when nation-state-attacker oppression will remain out of scope, thus allowing one to minimize energy consumption;
does not blindly accept calls from formal objectors to apply a centralized data gathering process to a global decentralized method of operation; and that
points out the unresolved tradeoff between the pollution costs of new technology and other TAG/EWP principles like individual control and privacy.

The patched section that I have offered does not address all the formal objections for the reasons that I have given above, primarily that a separate detailed response will be required. (The patch was rejected for reasons explained here, to which I responded here.)

I will persistently appeal to all current readers to support a resolution addressing the formal objections head-on, outside of this guide. I will persistently call out to the powers that be that this pull request, as it is, does not have consensus.

rxgrant commented 3 years ago

I've opened "Formal objections need a separate response #797" over in did-core.

OR13 commented 3 years ago

@csuwildcat

To approve, we would like to see the changes/suggestions requested in this PR accepted.

There are a lot of changes discussed here.... To consider your request I need you to link to specific suggested changes made by you which have not yet been merged, or incorporated.

We should avoid adding text to this document that implicitly affirms narratives related to the topic at bar, as the narratives themselves are highly subjective and often based on questionable assumptions that lack enough empirical, cognitive rigor to grant even tacit validation.

This may be your perspective, but it is clearly not the perspective of all others (including myself).

You will need to do more than suggest deletions, omissions or censorship of constructive attempts at defining how implementers might consider the cost of the verifiable data registry they have chosen.

We can't accept change suggestions that delete content you don't agree with, but we can accept a PR from you that refines a counter proposal or position, similar to how to we resolved issue with did document representations previously.

The PR should be accepted when the language it contains makes it clear that these perspectives are held by some working group members, and that other members hold different perspectives which they may choose to elaborate on in the future.

rxgrant commented 3 years ago

I've opened "Formal objections need a separate response #797" over in did-core.

It was a late-night error to post that in did-core instead of did-wg, and I've closed the issue. It is now available as did-wg issue #50.

rxgrant commented 3 years ago

We can't accept change suggestions that delete content you don't agree with, but we can accept a PR from you that refines a counter proposal or position, similar to how to we resolved issue with did document representations previously.

The PR should be accepted when the language it contains makes it clear that these perspectives are held by some working group members, and that other members hold different perspectives which they may choose to elaborate on in the future.

I'm objecting to this notion of governance.

brentzundel commented 3 years ago

The implementation guide is a working group note. It is not necessary for a working group note to reflect the consensus of the working group.

When consensus cannot be reached, it is appropriate for the multiple points of view to be represented. The course of action recommended by Orie is the correct one.

On Mon, Sep 13, 2021, 16:44 rxgrant @.***> wrote:

We can't accept change suggestions that delete content you don't agree with, but we can accept a PR from you that refines a counter proposal or position, similar to how to we resolved issue with did document representations previously.

The PR should be accepted when the language it contains makes it clear that these perspectives are held by some working group members, and that other members hold different perspectives which they may choose to elaborate on in the future.

I'm objecting to this notion of governance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-imp-guide/pull/27#issuecomment-918637795, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPFKP7QQP4MBTXNCH5EURDUBZ5DZANCNFSM5DJUBW7A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mprorock commented 3 years ago

The PR should be accepted when the language it contains makes it clear that these perspectives are held by some working group members, and that other members hold different perspectives which they may choose to elaborate on in the future.

@OR13 and all - I have added a bit of structure to the PR and cleaned some things up a bit. I have also explicitly noted in the section of contention that the views in the section reflect some working group members.

Welcome additional sections with additional viewpoints.

csuwildcat commented 3 years ago

The implementation guide is a working group note. It is not necessary for a working group note to reflect the consensus of the working group. When consensus cannot be reached, it is appropriate for the multiple points of view to be represented. The course of action recommended by Orie is the correct one.

If the assertion is that neutral language based on a strictly empirical basis for articulation is not the goal, but rather to provide a Festivus-like venue for the airing of subjective (largely dubious) grievances, I can only assume there will be cheerful acceptance of additional text within the scope of this section that counters these cognitively vacuous narratives? I just want to make sure folks understand what this invites and provide a moment to consider it before something like that arrives here like the proverbial Kool-aid Man bursting through one's wall.

mprorock commented 3 years ago

cheerful acceptance of additional text

by all means! might be easier to put it in a separate PR. In hindsight I would have split broad ethical guidelines and the references to TAG from the environmental section. I would just say to include an appropriate header to your new section as we adjusted this one to do. will defer to @brentzundel and @OR13 on appropriate header language - but i have used the following:

<p class="advisement">
  The following section reflects the views of some members of the working group.
  Additional PRs are welcome from the working group with additional points of view.
</p>

iherman commented 3 years ago

The issue was discussed in a meeting on 2021-09-14

no resolutions were taken

View the transcript

### 6. New section on environmental impacts (pr did-imp-guide#27) _See github pull request [did-imp-guide#27](https://github.com/w3c/did-imp-guide/pull/27)._ **Brent Zundel:** we have more time than expected, so now about 30 minutes to discuss implementation guide. … reminder that WG Note contents do not need to reflect consensus, although we try to get it where we can. … we can just reflect multiple viewpoints in the doc if needed. … goal is common ground **Ivan Herman:** i expect that after the formal objection discussion we will have to add something around sustainability to next charter … this means we should not necessarily regard formal objections as something we have to solve _now_, i.e., in the current DID WG … seems like some people feel we have to solve this issue right now, and personally i don't believe that's the case … this is not a formal W3C opinion, just my personal one > *Drummond Reed:* +1 that the formal objections SHOULD NOT affect approval of DID 1.0, only what it tackled in the rechartered WG going forward **Daniel Buchner:** only issue is if opinions are stated as more than just one person's opinion. … concerned that we might lend credence to incorrect assumptions … i will give mathematical proof for what I say, but let's not put in dubious narratives. … not sure how we would address in a future charter, but let's not lend credence to it with generalities > *Daniel Buchner:* Bad: "X is bad, as we know" > *Daniel Buchner:* Good: "I have done really no actual computation, but some headlines have said X" > *Daniel Buchner:* ^ knock yourself out **Ryan Grant:** agree. this seems like an attempt to cancel the spec and disparage proof of work. I have refuted this multiple times in email. > *Michael Prorock:* current text of the PR btw: [https://github.com/w3c/did-imp-guide/pull/27/files](https://github.com/w3c/did-imp-guide/pull/27/files) **Ryan Grant:** if this just turns into everyone's opinion, then the Implementation Guide will not be that. Individuals' thoughts should be labeled as such. … if group is not interested in consensus, this could just turn into a list of personal grievances … [section 3.3.1 of process](https://www.w3.org/2020/Process-20200915/#managing-dissent) discusses how to get agreement and doesn't agree with disparagement of my DID method. I will formally object to that if needed > *Orie Steele:* See [See section in the draft](https://pr-preview.s3.amazonaws.com/mesur-io/did-imp-guide/pull/27.html#environmental-and-ethical-considerations) (no mention of BTCR or Proof of Work). > *Daniel Buchner:* We need to be empirical, and clearly some folks are abjectly failing to do that: [https://twitter.com/csuwildcat/status/1435753376185139200](https://twitter.com/csuwildcat/status/1435753376185139200) > *Daniel Buchner:* I need folks to up-level their rigor A LOT **Michael Prorock:** I authored this PR. My background is in environmental science (and other areas). My daily work is environment-related. … agree that many PoW assessments do not look at full picture. … this was a red herring tossed at us, but these statements are made fairly often. … this is a complex issue, not a simple one. Wanted to call out the objection as written in my language. … in my opinion, if we can we should assess what the potential environmental impacts could be ,but also need to describe human rights and other balancing impacts. … the question about how much compute you use is a relevant one. … many of our use cases it would be overkill to use DIDs > *Joe Andrieu:* it is a false assertion to refer to PoW as wasting "extra compute" **Michael Prorock:** particularly when you look at data or supply chain items … encouraging the implementer of a method to think through this, and many other criteria, is a good thing. … language in the doc as it is now does call out future possibilities beyond PoW. … important that our language is future proof and not just PoW-based. … hope this helps explain context of PR > *Ted Thibodeau Jr.:* JoeAndrieu - it is disingenuous to interpret all references to wasting "extra compute" as disparaging PoW > *Orie Steele:* +1 to not using blockchains for every single verifiable data registry.... its a huge waste... nobody baths in 100% pure water, folks don't use the largest possible key size for encryption and signatures... picking the most decentralized and secure tool for everything, misses the point of good engineering. > *Daniel Buchner:* I have literally debunked them with facts, data, and computation **Ted Thibodeau Jr.:** initial comments made in this discussion were confrontational, by implying that others' opinions are dubious and spurious. … excess compute is not just PoW, it could refer to a number of patterns. > *Daniel Buchner:* Excess compute policing is not what we should be tasked with doing or articulating > *Orie Steele:* We should be careful to focus on the language _that we have now_... not what we started with. **Ted Thibodeau Jr.:** please do not disparage the good work of those who have been working hard in this group > *Daniel Buchner:* it's subjective, amorphous, and almost impossible to pin down **Ted Thibodeau Jr.:** we can behave better … there are some elements of the text in the guide that sound like the rubric and should probably just reference the rubric > *Drummond Reed:* +1 to not standing for impugning anyone's integrity or lack of good faith > *Michael Prorock:* +1 ted - need to make sure we are citing Rubric appropriately in the right places > *Drummond Reed:* +1 to push discussion and input about this topic to the Rubric **Ted Thibodeau Jr.:** it is in the best interest of the method writer to be the best according to all the metrics of the rubric … not just about any single metric. > *Daniel Buchner:* Metrics should be relatively quantifiable **Ted Thibodeau Jr.:** task of the DID method implementer is to balance their implementation and maybe increase compute in one place to increase security, and decrease in others. Not a black and white decision. … marketplace will make its own choices, let's not force it. … improve the performance of the method according to the metrics where it's not. > *Daniel Buchner:* The wages of losing may literally be human lives, not sure I can say the same for which VCR tech was chosen **Ted Thibodeau Jr.:** make the rubric better. better info, better tools for others to make their own decisions … doesn't matter how good you are just on one. … someone will choose based on their impression. … provide good tools to measure … may the better performer across many axes win **Joe Andrieu:** i agree with most of what you said, but not how you started. … if it's bad math or bad science, it is imperative to call it out and get it corrected. … the only response to that is that it is spurious … this is an intentional misinformation campaign. … we cannot propagate this misinformation … we should hold ourselves to a standard that represents consensus … any suggestion that energy use is the root problem needs to be cited, and if not, it needs to be removed > *Orie Steele:* +1 joe, can't refute an argument you refuse to acknowledge exists > *Daniel Buchner:* YOU THE MVP JOE > *Ryan Grant:* +1 to going through the work to address actual points of argument **Adrian Gropper:** i don't have a horse in the did method race. … from a human rights and privacy perspective, want a statement that *currently* PoW is best for self-sovereignty, although that could change **Ryan Grant:** might there be consensus around moving this out of implementation guide and into another doc? … we can move most of the argument to a document that does an analysis. … would be a note that is a collection of points of evidence with everyone's name attached. … point the Implementation Guide to that and remove anything that doesn't have consensus **Drummond Reed:** DID spec itself says nothing about the tech used for any specific DID method. … many of them won't have anything to do with blockchains … push everything possible towards the rubric, that's the right place for this **Daniel Buchner:** sorry if anyone took my comments as personal attacks. … in this case i dislike assertions that imply accuracy. want to make sure that what's in there is marked as an opinion if it is > *Ryan Grant:* not only were the assertions "assumed", but the editors explicitly excused their actions because the document is merely a Note not requiring consensus. **Daniel Buchner:** the point of contention is statements acting as if "everyone knows xx" > *Ted Thibodeau Jr.:* "we can put people's book reports in there" is precisely the kind of offhand impugning of people's work that I'm objecting to. **Michael Prorock:** i authored this here rather than in the rubric because developers often design without thinking about all of these considerations. … we can encourage them to think the right way and more broadly … we do need to find right balance of where we point to rubric, which sections, etc. > *Daniel Buchner:* Ted, I honestly don't know whether it's books, articles, or full evals, because these assertions are coming in without even noting something specific like that **Michael Prorock:** feels odd to have a security considerations section but not think about privacy … welcome feedback on eth PR to make sure we point to the right places in the rubric **Orie Steele:** we need to focus on the language in the PR, not the formal objection or other comments. … CCG has had conversations about this. I don't personally think PoW systems are evil, also don't think they are necessary everywhere. There are tradeoffs in costs, not just power costs. … WG members do have positions on this. Let's not position something as consensus that doesn't have it. But okay to point out that some wanted this section and some have mathematical arguments for why they believe it's not needed. … opposed to argue against argument by refusing to show it. > *Ryan Grant:* regarding what to put in the method implementation guide, it's pretty obvious why security factors might have consensus, because they are more connected with the factual technical expertise that this group brings. > *Ryan Grant:* I see no disagreement that the Rubric is a good place to point people > *Daniel Buchner:* I agree with what Orie just said > *Daniel Buchner:* great distinction > *Brent Zundel:* +1 Orie > *Daniel Buchner:* was my intent in highlighting how security and true need for decentralization are overwhelming factors, so it's tough to compute an empirical offset of something that wraps the empirical, subjective, and moral > *Ryan Grant:* Michael Prorock: if you want to refute the argument, people are going to need to respond to my comments in the thread. **Orie Steele:** let's not shy away from having the conversation. Make clear that some believe we should consider it and others don't. > *Drummond Reed:* +1 to PRs on the Rubric > *Ryan Grant:* +1 to a method implementation guide that points to discussions in the Rubric **Brent Zundel:** seems that there are enough people who think criteria should be added to rubric around this that they should create PRs, also that Imp. Guide is an appropriate place to explain that such criteria exist in the rubric and should be considered. … thanks all for the discussion. Everyone please review the _CURRENT_ version of the PR.

mprorock commented 3 years ago

please review the CURRENT version of the PR.

@jandrieu given the outstanding change request that refers to a prior version - when you get a chance can you re-review current language as well as the explicit call out that the potentially contentious section reflects some views, not all, and see if that helps here?

I would also like to point explicitly at the rubric as the method for performing validations of methods from the implementation guide in a separate PR

peacekeeper commented 3 years ago

I don't know much about the "is PoW worth it?" debate, but I find the language in this PR quite balanced. It doesn't say "PoW is evil", it only really says that environmental concerns must be considered in relation to other objectives, which makes sense to me.

As a side note, I feel like the last 2 paragraphs in this PR (prevent use of conflict minerals, and environmental impacts of supply chains) would fit better into the Use Case document rather than Implementation Guide. I'm not sure if these 2 paragraphs really tell me anything on how to implement DIDs.

TallTed commented 3 years ago

As a side note, I feel like the last 2 paragraphs in this PR (prevent use of conflict minerals, and environmental impacts of supply chains) would fit better into the Use Case document rather than Implementation Guide. I'm not sure if these 2 paragraphs really tell me anything on how to implement DIDs.

I agree they don't belong in an Implementation Guide. As with much of the current ImpGuide content, I think these paragraphs should move to the Rubric, where they would be good exemplars for axes related to scale of use of conflict minerals, and the various environmental impacts of supply chains.

mprorock commented 3 years ago

good call outs - included them as a reference of example implementations used for positive items. not sure on rubric or use case.... open to thoughts and think we should rehome those items

TallTed commented 3 years ago

not sure on rubric or use case

They're not use cases that are solved by DIDs; they're examples of high-points on a couple of axes against which all DID methods should be measurable, over time if not immediately.

It's important to recognize, and probably to state explicitly, that applying the rubric to a DID method will generally result in subjective ratings. There may emerge a "Consumer Reports" of DID methods whose ratings are objective enough for most — but I'm betting even such a hypothetical entity's ratings will not be universally accepted as gospel.

jandrieu commented 3 years ago

It's important to recognize, and probably to state explicitly, that applying the rubric to a DID method will generally result in subjective ratings. There may emerge a "Consumer Reports" of DID methods whose ratings are objective enough for most — but I'm betting even such a hypothetical entity's ratings will not be universally accepted as gospel.

Suggestions for improving this language are welcome: (From section 1.2 How to apply this rubric https://www.w3.org/TR/did-rubric/#how-to-apply-this-rubric)

Many of the criteria are subjective and all of them may evolve. Tracking who made the Evaluation and when they made it will help readers better understand any biases or timeliness issues that may affect the applicability of the Evaluation.

Be selective and acknowledge the subjective. Evaluations do not need to be exhaustive. There is no requirement to answer all the questions. Simply answer the ones most relevant to the use contemplated. Similarly, understand that any recorded Evaluation is going to represent the biases of the Evaluator in the context of their target use. Even the same Evaluator, evaluating the same Method for a different use, may come up with slightly different answers—for example, that which is economically accessible for small businesses might not be cost-effective for refugees, and that could affect how well-suited a given Method is for a specific use.

TallTed commented 3 years ago

Thanks, @jandrieu. I'm sure I've read those words before. I should have gone back and reread the Rubric, instead of talking about it based on what was misplaced here in the ImpGuide.

mprorock commented 3 years ago

@TallTed @OR13 I am wondering about adding a section, perhaps titled "Applied Use Cases" or similar to home those two items that gives developers examples of how DIDs have been applied to date, that can be added to, and then points back to the use case docs? that or just adding criteria for "societal impact" to the rubric section on "possible additional criteria" around those types of use cases, and then move these two items to the use cases?

ChristopherA commented 3 years ago

I am strongly against ANY LANGUAGE in the implementation guide recommending or discouraging any particular consensus algorithm or anti-Sybil mechanism, whether it be Proof of Work (PoW), Proof of Stake (PoS), any specific PBFT approach, or even a non-blockchain based solution for decentralization (I'm still surprised no one is working on a Kademlia DHT method). These are decisions of the method creators and in particular, those who choose to support those methods, based on their own security requirements.

Their choice of algorithm must be entirely determined by their needs, which only they can decide on how best to balance the competing requirements of those needs. There are parties whose requirements can not be satisfied by anything but the properties of global strong censorship-resistance PoW — others do have that requirement and can use another solution. No one solution is necessarily better than another — the question is more if a particular solution meets their requirements.

The ability to make your own choice based on your own security requirements is the core of why we chose in the early days of the DID design to use methods in our architecture.

I regard this PR as a commercial/political move to push for specific methods rather than offering actual technical implementation advice, and thus it doesn't belong here. I'm fine with social & environmental criteria (of which there are many more) being in the DID Rubric, but not here.

Strong -1 on this PR.

mprorock commented 3 years ago

I am strongly against ANY LANGUAGE in the implementation guide recommending or discouraging any particular consensus algorithm or anti-Sybil mechanism, whether it be Proof of Work (PoW), Proof of Stake (PoS), any specific PBFT approach, or even a non-blockchain based solution for decentralization (I'm still surprised no one is working on a Kademlia DHT method). These are decisions of the method creators and in particular, those who choose to support those methods, based on their own security requirements.

Which is why the language does not do so. As stated in the PR, some members of the working group feel strongly that developers should attempt to measure various strengths and weaknesses (using the Rubric as a quide) of their DID method, including asking questions around possible environmental impacts, while not forgetting other key principles such as privacy and control.

Similarly, as there are obviously other options from some members of the working group, a similar section, noted as the perspective of some to the working group is welcome.

@brentzundel Thoughts on this - seems like some of the comments in on this PR might be better as a PR themselves with an alternative viewpoint within the working group?

brentzundel commented 3 years ago

I do not believe that it is appropriate for this working group to publish. Nor do I feel the editors and chairs are actively seeking a consensus approach.

If we weren't aiming for consensus, this PR would have already been merged.

Arguments by both @OR13 and @brentzundel that consensus doesn't apply because it is a group note are particularly concerning.

Ultimately, a Working Group Note does not need to reflect the consensus of the group. This is a fact. This does not mean that we have not striven for consensus, nor does it mean that this PR will be merged over the objections of WG members. It may mean that this PR will be merged in conjunction with another PR that adds an opposing viewpoint. In situations (such as this one), when consensus seems unlikely to be achieved, the chairs and editors reserve the option to encourage both sides of the conversation to add their perspectives.

I'd suggest finding an alternative way to address the meritorious concerns about environmental sustainability, because this PR doesn't do it.

As WG chair, I encourage all those who feel that this PR does not reflect their perspective to submit alternative language in the form of additional PRs.

The continued push from WG leadership to publish it without appropriate management of dissent per W3C process calls the entire oversight mechanisms into question.

There has not been a push to publish. The PR remains un-merged, and conversation has continued. W3C Process has been strictly followed here. Resistance to remove viewpoints that some WG members do not agree with does not equal a "push to publish" those viewpoints and is a reflection of adherence to process rather than an indication that we are straying from it.

Whether the abandonment of consensus is itself a process violation is unclear to me.

Consensus has not been abandoned and characterizing the process we are following as such is inappropriate. To quote from the W3C Process Document "If questions or disagreements arise, the final determination of consensus remains with the chair." I have pointed out that including multiple viewpoints in the implementation guide when consensus cannot be reached on a single viewpoint is an option that may allow the group to move forward. This action does not violate process, it is the process.

The chairs take process very seriously. If you would like to pursue assertions of a process violation, please reach out to the chairs. I am happy to recuse myself from acting as a chair during that meeting if you deem that to be necessary.

As such, I advocate for dropping this PR and seeking to address sustainability in a separate note.

That is certainly an option. In my opinion, it would not be the best one.

TallTed commented 3 years ago

Environmental impacts of various DID methods are only worth considering in comparison to other DID methods and/or historical, technological, or other means of accomplishing the goals targeted with the deployment of any DID method.

All such comparisons are appropriate IN THE RUBRIC and do not belong in other documents except when guiding evaluators TO THE RUBRIC.

There should be no "section on environmental impacts" in this Implementation Guide. There might be a few sentences which might recur in various sections, which mention environmental impacts along with other comparative axes, such as deployer-security, user-security, ease of implementation, ease of end-use, ease of administration, etc. -- all of which axes are discussed in detail IN THE RUBRIC but not in this Implementation Guide. The current wording of #31 seems sufficient for this.

I think that retargeting this "new section on environmental impacts" AT THE RUBRIC -- i.e., transferring this PR #27 (numbered against the Implementation Guide) to the Rubric repo -- would address most of the concerns raised here. There would remain some appropriate and necessary changes to the presentation of several axes under consideration, which roughly amount to describing the expected tradeoffs as objectively as possible (e.g., "more xyz necessarily means less mno, more fgh, and possibly much more _abc"), rather than making value judgements in those descriptions, rather than telling users of the Rubric how to rank the criteria under consideration for their specific deployment.

mprorock commented 3 years ago

There should be no "section on environmental impacts" in this Implementation Guide.

Respectfully disagree. I think that similar to having a "security considerations" section that enumerates concerns with more than just questions to ask or criteria to check (as is the case in the rubric), a developer's guide should reference the RUBRIC for the actual criteria to consider in detail, but that a non-normative, narrative of how to approach different aspects of DID method development is important.

NB: there is a PR up on the rubric related to this, so that the impl guide can point to it directly from this section: Rubric Pull 51

EDIT TO NOTE: I also think we need another PR in after #31 that points each section of the narrative to appropriate sections of the rubric

TallTed commented 3 years ago

Users of, Deployers of, DID methods will use the Rubric to choose among the long list of candidate DID methods.

Implementers of DID methods must therefore keep in mind the various axes, the various DID method characteristics, which those Deployers will consider -- but there is no need to echo the entire Rubric in the Implementation Guide -- which is what must be done if any axis of the Rubric is echoed, because to do otherwise implicitly ranks the axis/es which are echoed higher than those which are not.

ChristopherA commented 3 years ago

@TallTed commented:

All such comparisons are appropriate IN THE RUBRIC and do not belong in other documents except when guiding evaluators TO THE RUBRIC.

There should be no "section on environmental impacts" in this Implementation Guide. There might be a few sentences which might recur in various sections, which mention environmental impacts along with other comparative axes, such as deployer-security, user-security, ease of implementation, ease of end-use, ease of administration, etc. -- all of which axes are discussed in detail IN THE RUBRIC but not in this Implementation Guide.

+1 to IN THE RUBRIC

w3c / did-imp-guide