DID WG Telco — Minutes

Date: 2021-09-14

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Daniel Burnett, Charles Lehner, Ivan Herman, Justin Richer, Markus Sabadello, Ryan Grant, Orie Steele, Cihan Saglam, Drummond Reed, Michael Prorock, Adrian Gropper, Joe Andrieu, Ted Thibodeau Jr., Dmitri Zagidulin, Kaliya Young, Pamela Dingle, Daniel Buchner, Geun-Hyung Kim

Regrets: Manu Sporny

Guests:

Chair: Brent Zundel

Scribe(s): Daniel Burnett

Content:

1. Agenda Review, Introductions

Cihan Saglam: software engineer at DanubeTech

Ryan Grant: Ryan Grant, with Digital Contract Design, co-editor of did:btrc method

Michael Prorock: Mike Prorock, founder/CTO mesur.io, co-chair of CCG, co-editor of Implementation Guide

2. WG Extension

3. TPAC Meeting

Brent Zundel: notice to the group. we are addressing formal objections to core spec. W3C has informed us that we have been granted an administrative extension beyond our original end of september charter end
… scheduled October 28, 11 am ET for TPAC meeting

Charles Lehner: meeting listed here: https://www.w3.org/wiki/TPAC/2021/GroupMeetings#WG.2FIG.2FBG_Group_Meetings_details

4. DID Spec status update

Brent Zundel: remaining editorial PRs have been merged, spec is ready to have final fixed version generated for Recommendation. Working with Team Contact and others at W3C to address formal objections
… have heard from Philippe who is discussing with Objectors.
… this is normal process. We still expect our doc to be published because we have followed the process properly.
… Process is slow but is moving forward

5. Initial draft of proposed Registry process (pr did-rubric#49)

See github pull request did-rubric#49.

Brent Zundel: PR 49 has been open for a while
… good discussion so far. Summary is that PR adds text necessary to convert doc into a registry where new criteria can be added over time
… feedback received, responded to, etc.

Joe Andrieu: Would be good to get a formal approval to accept this. Still some editorial to do.
… Just got in the last Echidna fix. Let’s agree to move forward with this.

Proposed resolution: The DID WG will convert the DID Rubric into a registry for DID Method evaluation criteria. (Brent Zundel)

Ted Thibodeau Jr.: +1

Drummond Reed: +1

Charles Lehner: +1

Dmitri Zagidulin: +1

Joe Andrieu: +1

Orie Steele: +1

Brent Zundel: +!

Daniel Burnett: +1

Michael Prorock: +1

Brent Zundel: +1

Markus Sabadello: +1

Ivan Herman: +1

Ryan Grant: +1

Resolution #1: The DID WG will convert the DID Rubric into a registry for DID Method evaluation criteria.

Justin Richer: +0 (don’t think it’s helpful but whatever)

Brent Zundel: as soon as the PR gets editorial cleanups we can merge. Thanks all!

Drummond Reed: Yes, it’s a major step forward. Thanks Joe!

Joe Andrieu: thanks for your support!

Ivan Herman: to be clear, we expect new DID charter will change after formal objection is resolved. Once your PR is merged I can take out the caveat we have in the charter text, right?

Brent Zundel: yes

6. New section on environmental impacts (pr did-imp-guide#27)

See github pull request did-imp-guide#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

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 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 (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
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.

7. Explanation on the DID Methods in the registries’ document (issue did-spec-registries#83)

See github issue did-spec-registries#83.

Brent Zundel: issue has been around a while. DID method section has a status column. 99% says provisional for status.
… what do we want that column to say? Do we want to explain provisional, etc.?

Drummond Reed: Added a reference to where I had put another comment. Original suggestion was to create a new table that li-sts methods where authors have upgraded their methods to match the Recommendation.
… old table stays as is, but provisional changes to “upgraded” for such methods and people should look at new table.
… it will help us call out name squatting
… quality of the did method specs varies. This will leave us with methods that meet our now higher bar in the main table.

Joe Andrieu: worried about how you proposed it. Worried about new name squatting.
… we do need consensus on the legitimate values for status and how they’re determined.
… when we first added provisional, it was to deal with methods that might not be consistent with current spec draft.
… need to figure out states, what they mean, and how they are assigned.

Ted Thibodeau Jr.: it seems that members of the new list should either be removed from the old (which is thus not static), or included on both with current status shown (and the old is again not static)

Ivan Herman: since we want this to become a formal registry, the doc itself has a registration process and that process says nothing about registering a new method. There is just a table, but no registration process. We need a clear policy for how things get into the table.
… we made a decision it would become a registry, but many details remain

Drummond Reed: Agreed, Ted. The proposal I made is that the only change to any methods listed in the Old table is that their status column value is changed if that method becomes listed in the New table.

Brent Zundel: we should use provisional (written before there was a spec), v1.0 compliant (submitted after the Recommendation), and deactivated (for no longer in use).

Justin Richer: what if the states are “Pre-1.0”, “1.0”, and “Deprecated”?
Justin Richer: basically what Brent Said
Justin Richer: or burn. Somebody said it.
Justin Richer: but basically call it “version” instead of “status” might help, too – but that’s a different argument

Ted Thibodeau Jr.: implementations submitted before DID Core 1.0 CR/PR could be listed as such, or de-listed for registry purposes

Drummond Reed: if we keep the current table, prefer what justin typed above
… no matter how we do it, need a clear policy on how to get the status changed.

Brent Zundel: next step should be a pull request proposing new language

Joe Andrieu: whoever the owner is of an entry, they should be able to self-assert which version of spec they claim to be compliant with
… since these will live for years and we need to plan for the future

Drummond Reed: +1 to being able to continuous upgrade the status values for future versions

Brent Zundel: any volunteers to write a PR?

Ryan Grant: I’ll volunteer

Brent Zundel: reminder for Imp. Guide PR review and request for other PRs, we will keep you informed of the progress of the spec
… thanks for remaining professional.

8. Resolutions