14:45:47 RRSAgent has joined #did 14:45:47 logging to https://www.w3.org/2021/09/14-did-irc 14:45:49 RRSAgent, make logs Public 14:45:50 please title this meeting ("meeting: ..."), ivan 14:45:53 Meeting: DID WG Telco 14:45:54 Chair: brent 14:45:54 Date: 2021-09-14 14:45:54 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Sep/0019.html 14:45:54 ivan has changed the topic to: Meeting Agenda 2021-09-14: https://lists.w3.org/Archives/Public/public-did-wg/2021Sep/0019.html 14:53:21 burn has joined #did 14:57:25 present+ 14:57:42 present+ 14:57:46 scribe+ 14:58:07 Topic: Agenda Review, Introductions 14:58:35 justin_r has joined #did 15:00:00 markus_sabadello has joined #did 15:00:47 present+ 15:01:00 present+ burn, cle, ivan, justin_r, brent, markus_sabadello 15:01:42 present+ rgrant 15:01:43 TallTed has joined #did 15:01:56 JoeAndrieu has joined #did 15:02:37 dbuc has joined #did 15:03:27 q+ 15:03:28 mprorock has joined #did 15:03:32 Orie has joined #did 15:03:37 ack ivan 15:03:44 present+ 15:04:08 rgrant has joined #did 15:04:18 Cihan: software engineer at DanubeTech 15:04:26 present+ chn 15:04:50 rgrant: With Digital Contract Design, co-editor of did:btrc method 15:04:59 q+ 15:05:00 s/Cihan/chn/ 15:05:06 chn has joined #did 15:05:08 ack mprorock 15:05:12 drummond has joined #did 15:05:17 present+ 15:05:34 mprorock: Mike Prorock, founder/CTO mesur.io, co-chair of CCG, co-editor of Implementation Guide 15:05:37 zakim, who is here? 15:05:37 Present: brent, burn, cel, cle, ivan, justin_r, markus_sabadello, rgrant, Orie, chn, drummond 15:05:40 present+ 15:05:41 On IRC I see drummond, chn, rgrant, Orie, mprorock, dbuc, JoeAndrieu, TallTed, markus_sabadello, justin_r, burn, RRSAgent, Zakim, ivan, tzviya, cypherhippie, Travis, shigeya, 15:05:41 ... dlongley, manu, brent, dlehn4, hadleybeeman, bigbluehat, wayne, asocrt, etropea73101, damian77, cel, rhiaro 15:05:51 present+ 15:05:53 dmitriz has joined #did 15:05:55 Topic: WG Extension 15:05:58 s/With Digital/Ryan Grant, With Digital/ 15:06:00 present+ chn 15:06:03 present+ agropper, JoeAndrieu, TallTed 15:06:08 present+ 15:06:19 present+ identitywoman 15:06:26 present+ pam 15:06:40 Topic: TPAC Meeting 15:06:46 brent: 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 15:06:58 present+ dbuc 15:07:22 ... scheduled October 28, 11 am ET for TPAC meeting 15:07:32 Topic: DID Spec status update 15:07:33 present+ Geunhyung_Kim 15:07:41 Geun-Hyung has joined #did 15:07:49 meeting listed here: https://www.w3.org/wiki/TPAC/2021/GroupMeetings#WG.2FIG.2FBG_Group_Meetings_details 15:07:51 regrets+ manu 15:07:59 present+ 15:08:17 brent: remaining editorial PRs have been merged, spec is ready to have final fixed version generated for Recommendatiotn. working with Team Contact, others at W3C to address formal objections 15:08:35 ... have heard from Philippe who is discussing with Objectors. 15:08:59 ... this is normal process. We still expect our doc to be published because we have followed the process properly. 15:09:13 ... Process is slow but is moving forward 15:09:20 q? 15:09:25 Topic: DID Rubric Status 15:09:25 present+ 15:09:30 brent: 15:09:55 brent: PR 49 has been open for a while 15:10:01 subtopic: @pr did-rubric #49 15:10:02 https://github.com/w3c/did-rubric/pull/49 15:10:34 s/ic #/ic#/ 15:10:35 ... 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 15:10:53 ... feedback received, responded to, etc. 15:11:22 JoeAndrieu: Would be good to get a formal approval to accept this. Still some editorial to do. 15:12:04 ... Just got in the last Echidna fix. Let's agree to move forward with this. 15:12:11 q+ 15:12:21 ack ivan 15:12:27 q+ ivan 15:13:05 PROPOSAL: The DID WG will convert the DID Rubric into a registry for DID Method evaluation criteria. 15:13:09 +1 15:13:09 +1 15:13:10 +1 15:13:11 +1 15:13:11 +1 15:13:12 +1 15:13:13 +! 15:13:14 +1 15:13:16 +1 15:13:17 +1 15:13:21 +1 15:13:22 +1 15:13:23 +1 15:13:55 RESOLVED: The DID WG will convert the DID Rubric into a registry for DID Method evaluation criteria. 15:13:57 +0 (don't think it's helpful but whatever) 15:14:20 brent: as soon as the PR gets editorial cleanups we can merge. Thanks all! 15:14:24 q? 15:14:36 ack ivan 15:14:38 Yes, it's a major step forward. Thanks Joe! 15:14:38 JoeAndrieu: thansk for your support! 15:15:28 ivan: 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. 15:15:30 brent: yes 15:16:05 Topic: Implementation Guide - Environmental impact 15:16:07 q+ 15:16:15 brent: we have more time than expected, so now about 30 minutes to discuss implementation guide. 15:16:31 q+ 15:16:41 ... reminder that WG Note contents do not need to reflect consensus, although we try to get it where we can. 15:17:02 ... we can just reflect multiple viewpoints in the doc if needed. 15:17:07 ... goal is common ground 15:17:08 q+ to request that viewpoints with dissent be labeled as such 15:17:09 q+ 15:17:26 ack ivan 15:17:35 on queue as I authored the PR and think some context could be useful 15:17:55 ivan: i expect that after the formal objection discussion we will have to add something around sustainability to next charter 15:18:09 agropper has joined #did 15:18:23 ... this means we should not necessarily regard formal objections as something we have to solve now in the current DID WG 15:18:29 present+ 15:18:52 ... seems like some people feel we have to solve this issue right now, and personally i don't beleieve that's the case 15:19:01 ... not a W3C opinion, just my personal one 15:19:06 +1 that the formal objections SHOULD NOT affect approval of DID 1.0 15:19:22 only what it tackled in the rechartered WG going forward 15:19:36 ack dbuc 15:19:55 dbuc: only issue is if opinions are stated as more than just one person's opinion. 15:20:16 ... concerned that we might lend credence to incorrect assumptions 15:20:30 q+ 15:20:40 ... i will give mathematical proof for what I say, but let's not put in dubious narratives. 15:20:59 ack rgrant 15:20:59 rgrant, you wanted to request that viewpoints with dissent be labeled as such 15:21:01 ... not sure how we would address in a future charter, but let's not lend credence to it with generalities 15:21:14 q+ to point out that immediate tone is confrontational and slanted 15:21:42 zakim, who is here? 15:21:42 Present: brent, burn, cel, cle, ivan, justin_r, markus_sabadello, rgrant, Orie, chn, drummond, mprorock, agropper, JoeAndrieu, TallTed, dmitriz, identitywoman, pam, dbuc, 15:21:44 Bad: "X is bad, as we know" 15:21:46 ... Geunhyung_Kim, Geun-Hyung, ! 15:21:46 On IRC I see agropper, Geun-Hyung, dmitriz, drummond, chn, rgrant, Orie, mprorock, dbuc, JoeAndrieu, TallTed, markus_sabadello, justin_r, burn, RRSAgent, Zakim, ivan, tzviya, 15:21:46 ... cypherhippie, Travis, shigeya, dlongley, manu, brent, dlehn4, hadleybeeman, bigbluehat, wayne, asocrt, etropea73101, damian77, cel, rhiaro 15:21:54 rgrant: agree. this seems like an attempt to cancel the spec and dispaarge proof of work. I have refuted this mutlitple times in email. 15:22:02 Good: "I have done really no actual computation, but some headlines have said X" 15:22:09 ^ knock yourself out 15:22:31 current text of the PR btw: https://github.com/w3c/did-imp-guide/pull/27/files 15:22:31 ... if this just turns into everyone's opinion, then the Implemenation GUide will not be that. Individuals' thoughts should be labeled as such. 15:22:51 q? 15:22:54 https://www.w3.org/2020/Process-20200915/#managing-dissent 15:22:57 ... if group is not interested in consensus, this could just turn into a list of personal grievances 15:23:02 Pamela has joined #did 15:23:48 ack mprorock 15:23:50 ... 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 15:23:50 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). 15:23:57 We need to be empirical, and clearly some folks are abjectly failing to do that: https://twitter.com/csuwildcat/status/1435753376185139200 15:24:09 identitywoman has joined #did 15:24:18 I need folks to up-level their rigor A LOT 15:24:20 present+ 15:24:39 mprorock: I authored this PR. My background is in environmental science (and other areas). My daily work is environment-related. 15:24:41 present+ 15:24:57 ... agree that many PoW assessments do not look at full picture. 15:25:26 ... this was a red herring tossed at us, but these statements are made fairly often. 15:25:46 ... this is a complex issue, not a simple one. Wanted to call out the objection as written in my language. 15:26:23 ... 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. 15:26:31 q+ to say this PR will likely never get consensus unless it can drop the misinformation about PoW, including veiled attacks on "energy use" 15:26:37 ... the question about how much compute you use is a relevant one. 15:26:54 ... many of our use cases it would be overkill to use DIDs 15:27:07 it is a false assertion to refer to PoW as wasting "extra compute" 15:27:14 ... particularly when you look at data or supply chain items 15:27:35 ... encouraging the implementer of a method to think through this, and many other criteria, is a good thing. 15:28:04 ... langueage in the doc as it is now does call out future possibilities beyond PoW. 15:28:12 q+ 15:28:12 JoeAndrieu - it is disingenuous to interpret all references to wasting "extra compute" as disparaging PoW 15:28:15 q+ to refocus on alternative ways to manage dissent 15:28:19 ... important that our language is future proof and not just PoW-based. 15:28:31 ... hope this helps explain context of PR 15:28:43 ack TallTed 15:28:43 TallTed, you wanted to point out that immediate tone is confrontational and slanted 15:28:50 +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. 15:29:22 q+ to remind us all that the DID spec does not specify "blockchain" at all - that is the province of DID methods 15:29:29 I have literally debunked them with facts, data, and computation 15:29:35 TallTed: iiniatl comments made in this discussion were confrontational, by implying that others' opinions are dubious and spurious. 15:30:03 ... excess compute is not just PoW, it could refer to a number of patterns. 15:30:16 ack JoeAndrieu 15:30:16 JoeAndrieu, you wanted to say this PR will likely never get consensus unless it can drop the misinformation about PoW, including veiled attacks on "energy use" 15:30:20 Excess compute policing is not what we should be tasked with doing or articulating 15:30:28 We should be careful to focus on the language _that we have now_... not what we started with. 15:30:44 ... please do not disaparage the good owrk of those who have been working hard in this group 15:30:49 it's subjective, amorphous, and almost impossible to pin down 15:30:49 +1 to not standing for impugning anyone's integrity or lack of good faith 15:30:53 ... we can behave better 15:31:16 ... there are some elements of the text in the guide that sound like the rubric and should probably just reference the rubric 15:31:27 +1 ted - need to make sure we are citing Rubric appropriately in the right places 15:31:34 +1 to push discussion and input about this topic to the Rubric 15:31:35 ... it is in the best interest of the method writer to be the best according to all the metrics of the rubric 15:31:42 Metrics should be relatively quantifiable 15:31:52 ... not just about any single metric. 15:32:31 ... task of the DID method implementer is to balance their implementaion and maybe increase compute in one place to increase security, and decrease in others. Not a black and white decision. 15:32:47 ... marketplace will make its own choices, let's not force it. 15:33:15 ... improve the performance of the method according to the metrics where it's not. 15:33:21 The wages of losing may literally be human lives, not sure I can say the same for which VCR tech was chosen 15:33:34 ... make the rubric better. better info, better tools for others to make their own decisiions 15:33:48 ... doesn't matter how good you are just on one. 15:34:00 ... someoen will choose based on their impression. 15:34:06 ... provide good tools to measuer 15:34:19 q? 15:34:21 ... may the better performer across many axes win 15:35:01 JoeAndrieu: i agree with most of what you said, but not how you started. 15:35:19 ... if it's bad math or bad science, it is imperative to call it out and get it corrected. 15:35:33 ... the only response to that is that it is spurious 15:35:35 +1 joe, can't refute an argument you refuse to acknowledge exists 15:35:42 YOU THE MVP JOE 15:35:47 ... this is an intentional misinformation campaign. 15:35:48 +1 to going through the work to address actual points of argument 15:35:56 ... we cannot propagate this misinformation 15:36:08 ... we should hold ourselves to a standard that represents consensus 15:36:27 ... any suggestion that energy use is the root problem needs to be cited, and if not, it needs to be removed 15:36:27 q+ 15:36:34 ack agropper 15:36:50 agropper: i don't have a horse in the did method race. 15:38:02 ack rgrant 15:38:02 rgrant, you wanted to refocus on alternative ways to manage dissent 15:38:06 ... from a human rgiths and privacy perspective, want a statement that *currently* PoW is best for self-sovereignty, although that could change 15:38:28 did:horse:isahorseofcourseofcourse 15:38:29 rgrant: might there be consenuss around moving this out of implementation guide and into another doc? 15:38:31 q+ 15:38:57 q- 15:39:00 ... we can move most of the argument to a document that does an analysis. 15:39:28 ... would be a note that is a collection of points of evidence with everyones' name attached. 15:39:45 ack drummond 15:39:45 drummond, you wanted to remind us all that the DID spec does not specify "blockchain" at all - that is the province of DID methods 15:39:46 ... point the Implementation Guide to that and remove anything that doesn't have consensus 15:40:07 drummond: DID spec itself says nothing about the tech used for any specific DID method. 15:40:22 ... many of them won't have anything to do with blockchains 15:40:32 q+ 15:40:36 ... push everything possible towards the rubric, that's the rigth place for this 15:40:38 ack dbuc 15:40:50 dbuc: sorry if anyone took my comments as personal attacks. 15:41:29 ... 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 15:41:41 not only were the assertions "assumed", but the editors explicitly excused their actions because the document is merely a Note not requiring consensus. 15:41:47 ack mprorock 15:41:52 ... the point of contention is statements acting as if "everyone knows xx" 15:42:12 "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. 15:42:26 mprorock: i authored this here rather than in the rubric because developers often design without thinking about all of these considerations. 15:42:39 ... we can encourage them to think the right way and more broadly 15:42:54 ... we do need to find right balance of where we point to rubric, which sections, etc. 15:43:09 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 15:43:13 ... feels odd to have a security considerations seciton but not think about privacy 15:43:29 q? 15:43:33 q+ 15:43:34 ... welcome feedback on eth PR to make sure we point to the right places in the rubric 15:43:39 ack Orie 15:44:03 Orie: we need to focus on the language in the PR, not the formal objection or other comments. 15:44:14 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. 15:44:43 I agree with what Orie just said 15:44:46 ... CCG has had conversations about this. I don't personally thikn PoW systems are evil, also don't think they are necessary ewverywhere. There are tradeoffs in costs, not just power costs. 15:44:48 great distinction 15:44:56 I see no disagreement that the Rubric is a good place to point people 15:44:57 +1 Orie 15:45:15 q+ 15:45:34 ... WG members do have positions on this. Let's not position osmething 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. 15:45:46 ... opposed to argue against argument by refusing to show it. 15:45:47 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 15:46:06 ack brent 15:46:09 mprorock: if you want to refute the argument, people are going to need to respond to my comments in the thread. 15:46:09 ... let's not shy away from having the conversation. Make clear that some believe we should consider it and others don't. 15:46:39 +1 to PRs on the Rubric 15:47:07 +1 to a method implementation guide that points to discussions in the Rubric 15:47:16 brent: seems that there are enough pepole 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. 15:47:44 ... thanks all for the discussion. Everyone please review the CURRENT version of the PR. 15:47:48 Topic: DID Registries - Issue 83 - Status Column 15:48:22 https://github.com/w3c/did-spec-registries/issues/83 15:48:55 brent: issue has been around a while. DID method section has a status column. 99% says provisional for status. 15:49:12 ... what do we want that column to say? Do we want to explain provisional, etc.? 15:49:16 q+ 15:49:22 ack drummond 15:50:21 drummond: 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. 15:50:42 q+ to say getting explicit with possible status states 15:50:55 ... old table stays as is, but provisional changes to "upgraded" for such methods and people should look at new table. 15:51:11 ... it will help us call out name squatting 15:51:31 ack JoeAndrieu 15:51:31 JoeAndrieu, you wanted to say getting explicit with possible status states 15:51:38 ... quality of the did method specs varies. This will leave us with methods that meet our now higher bar in the main table. 15:52:04 JoeAndrieu: worried about how you proposed it. Worried about new name squatting. 15:52:20 q+ 15:52:33 ... we do need consensus on the legitimate values for status and how they're determined. 15:52:56 ... when we first added provisional, it was to deal with methods that might not be consistent with current spec draft. 15:53:04 ack ivan 15:53:08 ... need to figure out states, what they mean, and how they are assigned. 15:53:12 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) 15:53:58 ivan: 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 lcear policy for how things get into the table. 15:54:05 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. 15:54:11 q+ to suggest some possible states 15:54:17 ... we made a decision it would become a registry, but many details remain 15:54:49 q+ 15:54:59 ack brent 15:54:59 brent, you wanted to suggest some possible states 15:55:00 ack brent 15:55:12 brent: we should use provisional (written before there was a spec), v1.0 compliant (submitted after the Recommendation), and deactivated (for no longer in use). 15:55:12 what if the states are "Pre-1.0", "1.0", and "Deprecated"? 15:55:16 ack drummond 15:55:22 basically what Brent Said 15:55:29 implementations submitted before DID Core 1.0 CR/PR could be listed as such, or de-listed for registry purposes 15:55:29 drummond: if we hkeep the current table, prefer what justin typed 15:55:30 or burn. Somebody said it. 15:55:53 ... no matter how we do it, need a clear policy on how to get the status changed. 15:55:57 but basically call it "version" instead of "status" might help, too -- but that's a different argument 15:56:20 brent: next step should be a pull request proposing new language 15:57:08 JoeAndrieu: whoever the owner is of an entyr, they should be able to self-assert which version of spec they claim to be compliant with 15:57:28 ... since these will live for years and we need to plan for the future 15:57:43 s/entyr/entry/ 15:57:48 +1 to being able to continuous upgrade the status values for future versions 15:57:49 brent: any volunteers to write a PR? 15:58:09 I'll volunteer 15:59:11 brent: reminder for Imp. Guide PR review and request for other PRs, we will keep you informed of the progress of the spec 15:59:22 rrsagent, draft minutes 15:59:22 I have made the request to generate https://www.w3.org/2021/09/14-did-minutes.html ivan 15:59:25 ... thanks for remaining professional. 15:59:39 zakim, end meeting 15:59:39 As of this point the attendees have been brent, burn, cel, cle, ivan, justin_r, markus_sabadello, rgrant, Orie, chn, drummond, mprorock, agropper, JoeAndrieu, TallTed, dmitriz, 15:59:41 rrsagent, draft minutes 15:59:41 I have made the request to generate https://www.w3.org/2021/09/14-did-minutes.html burn 15:59:43 ... identitywoman, pam, dbuc, Geunhyung_Kim, Geun-Hyung, ! 15:59:43 RRSAgent, please draft minutes 15:59:44 I have made the request to generate https://www.w3.org/2021/09/14-did-minutes.html Zakim 15:59:44 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 15:59:48 Zakim has left #did 15:59:55 present+ 15:59:58 (in case I forgot that) 16:00:38 rrsagent, bye 16:00:38 I see no action items