22:00:25 RRSAgent has joined #did 22:00:25 logging to https://www.w3.org/2021/03/30-did-irc 22:00:54 rrsagent, make logs public 22:01:02 rrsagent, draft minutes 22:01:02 I have made the request to generate https://www.w3.org/2021/03/30-did-minutes.html brent 22:01:04 present+ 22:01:08 zakim, this is did 22:01:08 got it, brent 22:01:23 present+ 22:01:53 kdenhartog has joined #did 22:02:00 present+ 22:02:18 brent has changed the topic to: DID WG Agenda 2021-03-30 https://lists.w3.org/Archives/Public/public-did-wg/2021Mar/0025.html 22:02:35 Meeting: Decentralized Identifier Working Group 22:02:42 Chair: Brent Zundel 22:04:14 KelseyRhoda has joined #did 22:04:30 markus_sabadello has joined #did 22:04:33 present+ 22:04:35 present+ 22:04:39 present+ 22:05:23 scribe+ 22:05:27 present+ 22:05:30 rrsagent, draft minutes 22:05:30 I have made the request to generate https://www.w3.org/2021/03/30-did-minutes.html manu 22:05:43 Topic: Agenda Review, Introductions, Re-introductions 22:06:44 brent: Going to announce the special topic. breif conversation about DID method implementations. slightly longer conversation about process moving forward. Then will run through the DID Core issues, speak briefly about untested features, then finish with talking about test suite issues. Suggestions for agenda changes? 22:06:59 brent: Intros and reintros. Asking KelseyRhoda 22:07:09 KelseyRhoda: I work with Spruce, working on some applications adjacent to the space 22:07:22 ... coming into try to understand the goals of the committee, the different specifications as it's going 22:07:26 brent: Excellent, welcome. 22:07:32 brent: Next topic: 22:07:32 Topic: Special Topic Call 22:08:03 brent: One of these days, I will send a special topic call agenda email that is perfect. That day was not to be this week. I still said it was Tuesday April first - there is no such time this year. April fools day? 22:08:12 ... Thursday April 1st special topic call. Test suites. 22:08:32 Topic: DID Method Implementations 22:08:51 brent: We are nearly ready for DID Method implementors to submit their DID method implementations to the test suite. 22:09:08 ... We are not yet ready. So this is a call for DID Method implementations to be prepared: be ready. Very very soon the test suite will be ready. 22:09:15 ... Not quite ready yet, so don't submit yet. 22:09:22 q+ 22:09:26 ... Any quesitons, comments? 22:09:29 ack kdenhartog 22:09:49 kdenhartog: 2+ for production-ready status - are we in alignment with that in the group? 22:09:52 brent: Can you clarify? 22:09:55 GeunHyung_Kim has joined #did 22:10:11 Present+ 22:10:19 kdenhartog: When we were discussing what are the requirements for different levels - provisional, implementation, production. impl requires only one, but Production requires 2+ independent. 22:10:23 q+ 22:10:25 ... is what we were thinking 22:10:29 q+ 22:10:39 ack markus_sabadello 22:10:43 brent: Excellent question. Assuming on thread ... in DID Spec Registries? 22:11:09 ack manu 22:11:12 markus_sabadello: I don't understand the question. Said to require 2+ implementations of a feature in the DID Core specification, but what does this have to do with Provisional status 22:11:18 For reference looking at this issue: https://github.com/w3c/did-spec-registries/issues/266 22:11:27 Orie_ has joined #did 22:11:29 manu: I think you are talking abouthe did-spec-registries, the Provisional field 22:11:32 present+ 22:11:51 ... Drummond and Kyle you are proposing we have different words other then provision? Specification, Implementation and Production. That is the proposal? 22:12:01 kdenhartog: Yeah. Happy to bikeshed the names as well. 22:12:11 I believe we are discussing https://github.com/w3c/did-spec-registries/issues/266 22:12:18 zakim, who is here? 22:12:18 Present: shigeya, cel, TallTed, kdenhartog, markus_sabadello, manu, KelseyRhoda, GeunHyung_Kim, Orie_ 22:12:21 On IRC I see Orie_, GeunHyung_Kim, markus_sabadello, KelseyRhoda, kdenhartog, RRSAgent, Zakim, TallTed, dmitriz, brent, faceface, shigeya, cel, bigbluehat, dlehn, hadleybeeman, 22:12:21 ... dlongley, manu, ChristopherA, wayne, Travis_, rhiaro 22:12:31 manu: Not concerned with names but with having the editors have to go out and verify the implementation. Hard enough working on the registry without making a determination on 85 DID methods 22:12:36 present+ 22:12:44 ... having arguments about what an implementation is. 22:12:55 ... "I've got two implementations: my brother and I did one" 22:13:07 ... I am wondering if we could go the other way, and remove that field altogether 22:13:12 q+ 22:13:17 ack Orie_ 22:13:26 ... I am hesitant about the classifications putting burdens on the people in registry. Would like to hear from Orie 22:13:40 Orie_: I agree with the concerns. Registry needs more people in the pool to do these reviews. 22:13:58 ... Need to make requirements clear for the reviewers. Not obviously wrong -> Approve. 22:14:07 ... Have to be careful about making the burden for registration too high. Need to make it easy. 22:14:22 q+ 22:14:32 ... I agree with what you are saying, manu. I don't know if the proposal can be beaten into a shape where the pull request template would be enough. 22:14:36 ack kdenhartog 22:14:44 kdenhartog: I understand your concerns, think they make sense. 22:14:51 ... I probably wouldn't go sa far as to say let's completely remove it 22:15:01 ... but was thinking what if... when you submit the original spec, we have some sort of template 22:15:13 q+ 22:15:30 ... where as part of that template, if you have a registered test suite connected with that method, and the test results come back positive, we could change it to "tested". Have effectively two statuses ... 22:15:42 ... Concerned we have a bunch of DID methods I've never seen code for. 22:15:46 q- 22:15:51 brent: would like to continue. Best place in issues. 22:15:58 Topic: Process moving forward 22:15:59 manu: Agree we should continue to discuss this. 22:16:06 +1 thanks, let's discuss over there. Thanks for taking a look at it 22:16:09 brent: We are in CR. 22:16:13 ... We want to get out of CR. 22:16:48 ... Previously, when pull requests were merged, it was consensus of the group and then we would merge the PR and continue moving forward. We recorded consensus through the GitHub Issues. There wasn't a lot of formality around merging PRs. 22:17:10 ... Moving forward, in order to safely exit CR, we need to have a distribution of comments (?), especially around substantive issues. 22:17:29 ... what this means is any issue raises, we must ... record what changes were made 22:17:39 ... so that folks can tell what changed from one version to another 22:18:01 ... We have introduced a couple new labels: comment-resolved-implicit, comment-resolved-explicit. 22:18:10 ... Asking manu to explain the difference. 22:18:30 manu: IIRC... CR is a very special time. When we get a comment in during CR, we are required to say whether or not we resolved it. 22:18:46 ... And we have to check with the person who filed it (the comment), if they are okay with change we made. 22:19:01 ... Need to say whether it was addressed, confirm with the commenter. 22:19:15 ... Explicit means yes they responded: they respond yes okay with change 22:19:43 ... Implicit means we asked, they don't respond, and we say "we will assume you are okay with this if you do not respond". In 7 days. 22:19:53 ... At end of 7 days, we would mark as comment-resolved-implicit. 22:20:03 ... Does anyone have any questions about this? 22:20:18 brent: That is what I was hoping you would say. It clarified things for me and hopefully for the group. 22:20:27 ... Any questions for process moving forward? 22:20:36 ... Primarily the burden of this will fall to the editors. 22:20:52 ... What it means in general is if there was an issue raised, don't close it, unless we have the appropriate disposition of comments. 22:21:05 Topic: DID core issues 22:21:17 ... Issue processing. 22:21:24 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Adefer-v2 22:21:42 ... These are all the issues that have not been marked defered. 22:21:51 ... The current set of issues we are required to address and resolve before we can leave CR. 22:21:52 drummond has joined #did 22:21:57 ... We are going to go through them one at a time. 22:22:03 present+ 22:22:15 brent: Ivan has asked us to be careful with the notes in this 22:22:22 ... so we can properly attribute folks to the right issues. 22:22:33 subtopic: Diagrams need SVG and detailed description @issue 625 22:22:40 https://github.com/w3c/did-core/issues/625 22:23:05 markus_sabadello: I created this issue when I was working on some of the diagrams for DID Core, especially those for the Data model and DID resolution section 22:23:18 ... I did not create SVG versions yet, which Ivan suggested and I agree with that 22:23:36 ... So I don't forget. I will do that for the ones I created. Not sure if there are other non-SVG diagrams 22:23:41 q+ 22:23:41 ... but if there are then we should also convert those 22:23:49 brent: Are you looking for assistance with that? 22:24:07 markus_sabadello: I will do it for the ones I created 22:24:23 subtopic: CR Feedback: Support of publicKeyMultibase @issue 707 22:24:25 q- 22:24:29 brent: if you identify some other ones, please mention them 22:24:37 if somebody needs help on diagram, I can (after finishing test spec, of course) 22:24:40 https://github.com/w3c/did-core/issues/707 22:24:52 q+ 22:25:22 ack Orie_ 22:25:37 Orie_: I'm one of the folks who commented on this. I'm very supportive of this issue. 22:25:49 q+ 22:25:51 ... Generally, everyone should read the issue. Whatever I can do to move this ball forward, sign me up 22:26:03 brent: I am adding you as an assignee to the issue. 22:26:04 ack manu 22:26:29 manu: +1 to what Orie_ said. I believe on purpose we put language in the spec that would allow us to make this substantitive change during CR. 22:26:43 ... Digital Bazaar to provide two multibase encodings to the test suite. 22:26:53 ... The reason for multibase is to make it easier to compress in things like CBOR-LD. 22:27:15 ... Comes up for vaccination certificates and anything to put in a QR code. If you have a multibase encoding, you can in some case save a significant number of bytes. 22:27:15 q+ 22:27:21 ... Also a good future-proofing mechanism. 22:27:24 ack kdenhartog 22:27:40 q+ 22:27:45 ack manu 22:27:49 kdenhartog: Maybe venturing into "take it into the comments" ... but does it make sense for us to define it here, or better in the linked data suites work? 22:28:15 manu: good question, it should have been done years ago in that work. But because it did not go standards track first, we are in the awkward position of having to define this stuff. 22:28:39 ... We wanted to keep it out of the spec like we did with vc-data-model. But now we have publicKeyBase58 in there. Want to either add publicKeyMultibase, or replace it. 22:28:52 ... Because it's in there, let's try to do the right thing this time around. 22:29:19 subtopic: verification method IDs MUST contain a fragment @issue 708 22:29:29 https://github.com/w3c/did-core/issues/708 22:29:45 brent: manu you are assigned; do you have an update for us? 22:29:53 manu: I do not, have not been tracking updates. Need to read. Charles... 22:30:07 cel: I don't have anything to add right now. 22:30:19 brent: Last activity was nearly three weeks ago. We will come back to it another time 22:30:35 subtopic: Explain verification suite definition and explain reuse of verification method type/material @issue 712 22:30:39 Manu, I'm good with that. If we plan to put something in here than I agree publicKeyMultibase makes more sense. 22:30:59 brent: raised by Oliver, currently assinged to manu. 22:31:09 manu: just assigned 8 minutes ago. Orie_ ? 22:31:27 brent: https://github.com/w3c/did-core/issues/712 22:31:49 Orie_: It's very related to the previous issue, regarding VM suites and VM material. 22:32:13 ... Essentially, Oliver is surprised we are not discussing VM suites in DID Core. We have discussed this at length. 22:32:21 ... I don't think there is a need to describe verification methods in DID Core. 22:32:22 subtopic: Proving Control sections are wrong @issue 583 22:32:28 https://github.com/w3c/did-core/issues/583 22:32:52 brent: Assigned to Amie, but I don't see her her. manu or markus_sabadello? 22:33:01 manu: Amy is going to do it 22:33:15 subtopic: Can DID methods be semantically versioned? @issue 715 22:33:22 https://github.com/w3c/did-core/issues/715 22:33:39 q+ 22:33:42 manu: The answer is yes; we don't really need to say anything about it. I'll take it 22:34:01 q- 22:34:36 kdenhartog: Easy way to answer that: reference the did:peer stuff. They have built in a way to semantically version the different DID stuff. I'm happy to answer that if that would help. 22:34:38 manu: Yes, please 22:34:45 subtopic: FAQ Question: Can the DID Controller of a DID Document be updated/changed after the DID Document has been registered? @issue 719 22:35:02 brent: Currently unassigned, and has one comment. 22:35:19 ... I don't know that more needs to happen 22:35:30 manu: There is a request to add a FAQ for it. 22:35:41 manu: drummond, are you refactoring the end of the document to be a FAQ? 22:35:50 drummond: I thought the goal was to refactor it to not be a FAQ 22:35:56 manu: My bad, the other way then 22:36:03 ... Never mind 22:36:10 ... I was going to say... can you speak to it ... 22:36:20 drummond: Definitely. Feels like one of the things to discuss 22:36:30 ... If you want me to cover it, I'm happy to do that 22:36:37 q? 22:36:39 q+ 22:36:48 ... All the update will do is change the questions into headings. It wasn't a FAQ originally ... 22:36:48 ack manu 22:36:53 ... I'll take that action item. 22:37:01 subtopic: FAQ Question: Can the DID Subject of a DID Document be updated/changed after the DID Document has been registered? @issue 718 22:37:15 https://github.com/w3c/did-core/issues/718 22:37:29 brent: This would be another thing if drummond can in his refactoring, make sure this question ends up query 22:37:42 ... I think it's clear from the rest of the document... but making it clear would be valuable 22:37:49 drummond: OK, I will take that one too. 22:38:00 q+ 22:38:07 ... ALthough the answer to earlier one seems obvious, I think there may be different answers for this one, depending on who you ask. 22:38:08 ack manu 22:38:13 ... Do we have a well-documented reply to answer? 22:38:27 manu: This is not explicitly mentioned anywhere I think. It's really DID Method specific. 22:38:39 ... I don't know of any DID method that allows you do change the DID Subject. 22:38:54 ... Could imagine ... tombstoning... to make it seem like that happened. 22:38:56 q+ 22:39:10 drummond: It might be theoretically possible to that, but we don't know of any. Or we could flat out say no. 22:39:20 ack kdenhartog 22:39:22 brent: Or you could say whether or not it is possible is DID Method-specific. 22:39:35 kdenhartog: Advocating for no. Huge can of worms 22:39:41 ... we did a good job avoiding. 22:39:43 q+ to not ssay no 22:39:45 markus_sabadello has joined #did 22:40:02 ack Orie_ 22:40:02 Orie_, you wanted to not ssay no 22:40:05 brent: I know of at least one working group particant who would say yes. If we say DID method-specific, we could avoid that 22:40:11 Orie_: I agree with what you just said, brent. 22:40:15 q+ 22:40:22 ... Example is DID subject is human owner at house. It changes over time. Does the subject change? I don't think so. 22:40:30 ack markus_sabadello 22:40:32 ... But depending on how you read English, you might come up with different ways of answering ti. 22:40:33 q+ 22:40:59 ack drummond 22:41:08 markus_sabadello: I think we have a normative statement somewhere that when you resolve the DID, the id property of the resolved DID document must match what was resolved. If change the DID, feels like this would break. Maybe misunderstanding the question? 22:41:25 drummond: Tricky question. It feels like two questions: one is is it the same DID document if you change the value of the id property. 22:41:32 ... That's one thing the question could be asking 22:42:19 ... The other, that I thought it was asking, is we said the DID controller controls what the DID identifies. I thought it was asking if that DID controller could make the DID identify something different. That is the one there was a WG participant who would say yes. ... Could be DID method specific 22:42:34 brent: I recommend answering as best you can in the PR and then allowing the conversation to continue. 22:42:42 drummond: I'll make it a separate PR so we can have a discussion just about that. 22:42:42 subtopic: equivalentId and canonicalId should be optional @issue 717 22:42:49 https://github.com/w3c/did-core/issues/717 22:42:54 q+ 22:42:56 brent: Final issue. Assigned to Markus. 22:43:23 markus_sabadello: I came across this while I was working on my part of the test suite, implementing the resolution sections. I noticed that these two properties 22:43:33 ... unlike all the others, don't say whether they are optional or required. 22:43:52 ... Maybe me just misunderstanding ... It specifies what the values must be, but not if they are required or optional. 22:44:02 ... I'm sure the intention of the WG is to make them optional; raised a PR to clarify it. 22:44:12 ack manu 22:44:13 ... Since sections marked at-risk, hope it does not cause complications. 22:44:27 manu: Reading the spec right now, I think it is a problem. 22:44:39 ... Trying to figure out if it pushes us into another CR phase to fix it. 22:44:47 ... It would be a normative change. 22:45:04 ... Could argue it was unclear whether optional or not. It didn't say you have to specify it. 22:45:06 It's a change to a normative section, but I don't think it should force changed behavior 22:45:19 ... We didn't do that, therefore it was optional. All we are doing is clarifying it is optional. 22:45:22 q+ 22:45:23 q+ 22:45:36 brent: Comment said they are optional for methods to leverage. 22:45:40 q+ 22:45:49 brent: Meaning the one implementer is intending them to be optional. 22:45:54 ack drummond 22:46:16 ack markus_sabadello 22:46:19 drummond: I collaborated with Daniel on that text. It absolutely... I swear it has always been the intention. 22:46:25 ... I have a stack of bibles off-screen 22:46:43 markus_sabadello: Reading the actual text, it wasn't clear... The section marked at-risk: doesn't that mean we can make these changes? 22:46:45 ack manu 22:47:02 manu: We didn't mark it at-risk in that way. We basically said we are seeking implementer feedback. If not enough, might remove ... not modify. 22:47:16 ... Grey area... As long as no one objections ... we just forgot to put the language there. 22:47:56 ... Unfortunately, intent doesn't matter. If it is possible someone looked at the specification and implemented it using just the words... If we are going to make a change to it, would it affect that person's implementation? I think good argument for no, since we didn't say you must have either of these properties. 22:48:03 +1 to that interpretation 22:48:07 brent: Agree 22:48:10 Topic: A Note about untested features 22:48:50 ... Untested features may need to be removed from the specification. This means if there is a normative statement and no way to test whether or not it has two or more independent implementations, we may be forced to remove that untested feature from the spec. 22:48:59 ... Just as we will be required to remove insufficiently implemented features. 22:49:02 q+ to clarify that the normative statement may not be machine testable 22:49:18 ack drummond 22:49:18 drummond, you wanted to clarify that the normative statement may not be machine testable 22:49:22 ... That needed to be clarified I believe. Hopefully that will encourage those folks who care about specific features to contribute to the test suite. 22:49:34 q+ 22:49:44 ack manu 22:49:51 drummond: Want to make clear we have some normative statements not machine testable. Let's not discriminate ... but anything machine-testable, shuld test. 22:50:08 manu: Just because human-testable, still need to demonstrate at least two have done it. 22:50:20 Topic: Test Suite Issues 22:50:25 manu: strike ^ from record 22:50:31 https://github.com/w3c/did-test-suite/issues 22:50:32 s/manu: Just because human-testable, still need to demonstrate at least two have done it.// 22:50:38 s/manu: strike ^ from record// 22:51:01 subtopic: Use of better jest matchers @issue 36 22:51:07 brent: https://github.com/w3c/did-test-suite/issues/36 22:51:16 brent: shigeya, can you talk about it? 22:51:40 shigeya: There are several ways to write tests, mentioned in this ... whether the specific string in a variable is actually a string or not, and so on. 22:52:01 s/@issue 36/@issue did-test-suite#36/ 22:52:10 ... After filing this issue, I found that there are variations of the test against, for example, if a variable is a string or not, there is variation on how to write the test. 22:52:29 ... I think it is better to use the same pattern in the test. Not necessarily as matchers as I stated here, but at least should use the same pattern for the entire test. 22:52:46 ... If we use matchers, we can simplify both the expressions and the test. 22:52:54 ... So I think it is better to use matchers. 22:52:54 q+ 22:52:59 +1 22:53:02 ack manu 22:53:12 manu: I agree with shigeya. 22:53:28 ... There is a certain amount of cleanup ... I agree we should use the matchers shigeya is mentioning. +1 22:53:49 brent: Is anyone willing to be assigned to this issue? 22:53:53 shigeya: I can work on it. 22:53:58 brent: Thank you 22:54:20 Next issue raised by me... 22:54:24 subtopic: need clear instructions for implementers @issue did-test-suite#33 22:54:35 ... https://github.com/w3c/did-test-suite/issues/33 22:54:52 ... When an implementer goes to the test suite, there needs to be a clear set of instructions for submitting tests. 22:54:56 q+ 22:55:05 ack markus_sabadello 22:55:05 ... Last time I looked, I didn't see ... guidance on submitting an implementation report. 22:55:08 +1 definitely ran the tests saw they passed and went "Huh, I didn't connect any of my code though" 22:55:29 markus_sabadello: I agree with what Manu said earlier. Test suite needs to be restructured. Not entirely clear what an implementor would submit. 22:55:44 ... There are a number of PRs using different formats ... needs to be reconciliated a bit. 22:56:12 brent: Will someone take this issue 22:56:22 Orie_: I will ... assuming ... 22:56:29 brent: I have no problem with that 22:56:48 subtopic: We need to refactor fixtures for implementers @issue did-test-suite#32 22:56:49 q+ 22:57:00 ack Orie_ 22:57:12 Orie_: Same point Markus and others have raised. Essentiall, the structure of the test suites is not set in stone or finalized or working. 22:57:27 ... This issue is raised at a time of great frustration, but since then we have got many more people contributing to this. 22:57:44 ... I don't think we have finished refactoring the test fixtures, as evidenced by Markus's comments, but I think we are on our way. 22:58:01 q+ 22:58:10 ack manu 22:58:12 brent: This one is unassigned 22:58:16 manu: I will take it 22:58:31 ... Critical path... I don't want to put myself in the critical path... I will make an attempt. 22:58:47 ... There is an order of operations here. One is we figure out details of testing all this stuff. Once we figure it out, it will be a bit of a mess 22:59:03 ... We will need to refactor it. Then we expect the DID method implementers to come in and fill it out. 22:59:09 Please review my PR about DID Resolution tests.. https://github.com/w3c/did-test-suite/pull/43 22:59:12 ... Concerned about order of operations... 22:59:22 ... If anyone gets to it before I do, please take a shot at it. 22:59:27 subtopic: Need tests for Metadata Structure @issue did-test-suite#31 22:59:52 https://github.com/w3c/did-test-suite/issues/31 23:00:04 shigeya: I almost finished writing tests besides one issue, related to the DID registry, as I commented in the issue. 23:00:21 ... Please look at the last comment I made. 23:00:38 ... The spec says all metadata property definitions registered in the registry must define a variable type. 23:00:50 ... I need a way to find this. Option 1: refer to did-spec-registries 23:01:04 ... Or we can assume that properties other than the core properties are registered. 23:01:11 ... I need some way to determine the list of types for this test. 23:01:27 brent: Thank you for the overview 23:01:37 Thank you all for your work. 23:01:48 brent: Special Topic call this Thursday 23:02:43 zakim, end the meeting 23:02:43 As of this point the attendees have been shigeya, cel, TallTed, kdenhartog, markus_sabadello, manu, KelseyRhoda, GeunHyung_Kim, Orie_, brent, drummond 23:02:45 RRSAgent, please draft minutes 23:02:45 I have made the request to generate https://www.w3.org/2021/03/30-did-minutes.html Zakim 23:02:48 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 23:02:52 Zakim has left #did 23:02:57 rrsagent, bye 23:02:57 I see no action items