21:46:03 RRSAgent has joined #did 21:46:03 logging to https://www.w3.org/2021/08/24-did-irc 21:46:22 rrsagent, draft minutes 21:46:22 I have made the request to generate https://www.w3.org/2021/08/24-did-minutes.html brent 21:46:31 rrsagent, make logs public 21:46:56 Meeting: Decentralized Identifier Working Group 21:47:14 Chair: Dan Burnett 21:47:28 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Aug/0019.html 21:53:04 present+ 21:55:23 present+ 22:00:18 justin_r has joined #did 22:00:24 present+ 22:00:43 present+ 22:00:45 markus_sabadello has joined #did 22:01:15 present+ markus_sabadello 22:01:41 present+ TallTed 22:02:46 present+ 22:03:02 scribe+ 22:03:05 Topic: Agenda Review, Introductions 22:03:36 burn: Moving into administrative-type discussions. Just about done with the spec. Talking about press release briefly, the upcoming SRI report on DID Core 22:03:42 ... errata management on the DID spec, 22:03:52 ... then give Joe some time to talk about the Rubric and something he would like to propose. 22:04:04 ... Then going to the Implementation Guide, and DID Spec registries 22:04:12 ... Modifications? 22:04:21 Drummond: Sounds good 22:04:22 Topic: Press Release 22:04:27 present+ 22:04:30 drummond has joined #did 22:04:36 present+ 22:04:44 brent: We are holding off collecting testimonials and evidence of wide usage until we get a draft. 22:05:04 ... Ivan has been working with Coralie, who is in the W3 Public Relations Group. She is drafting the press release. 22:05:28 ... As soon as we have that, we will send it around, for anyone who is using DIDs or even VCs. The scope seems to be SSI in general. 22:05:35 drummond: Does it actually use the term SSI? 22:05:37 kdenhartog has joined #did 22:05:41 present+ 22:05:51 brent: Most likely not, I'm using it as am umbrella term. 22:06:26 drummond: Question: timing. It will help to know - I repeat this - Some folks will want to know so they can do their own promotion or tack onto it. Do we know when the actual announcement will be? 22:06:46 brent: The best direction for an estimate that we have is that the W3C wants to, as best as they can, synchronize the DID Spec becoming a recommendation and the press release. 22:07:11 zakim, who is here? 22:07:12 Present: burn, brent, cel, justin_r, markus_sabadello, TallTed, shigeya, manu, drummond, kdenhartog 22:07:14 ... We are expecting that the DID Spec will become a recommendation the 23rd of September (?) - That's the date I've heard mentioned. Approximately around there. 22:07:14 On IRC I see kdenhartog, drummond, markus_sabadello, justin_r, RRSAgent, Zakim, burn, brent, TallTed, tzviya, ChristopherA, dlongley, manu, dlehn4, faceface, Travis, hadleybeeman, 22:07:14 ... bigbluehat, wayne, asocrt, etropea73101, damian77, shigeya, cel, rhiaro 22:07:23 agropper has joined #did 22:07:32 present+ agropper 22:07:40 drummond: Let me suggest... ToIP, DIF, various groups that may plan events, announcements... At what point do we think we will have a definitive date? 22:07:56 brent: The data by which we will know the date for publishing a recommendation is probably the 7th of September. 22:08:17 ... In anticipation of that... There's a narrow window in September for actually publishing things. So Thursday the 23rd is most likely. 22:08:30 drummond: Very helpful for folks to make plans, thanks 22:08:30 Topic: Upcoming SRI Report on DID Core 22:08:37 burn: Reminder to +1 in IRC 22:09:04 manu: DHS effectively hired SRI to do an independent review on the DID spec and DID methods and things like that. 22:09:15 ... So you can think of it as kindof a third-party audit on the type of ecosystem we've created. 22:09:26 ... They did a pretty in-depth look, but it's not exhaustive. 22:09:40 ... They would like to present their findings. Question: what would we like to hear about? 22:09:54 q+ 22:09:57 ... There's enough content for 2 or 3 calls. If we had a choice on what they could present, what would we want them to talk about? 22:09:58 ack drummond 22:10:20 drummond: I haven't looked through the content yet, but want to go to the heart of it, Manu, what do you want to hear about. 22:10:28 manu: It's been enough time that I've forgotten the presentation. 22:10:37 ... I think the first blush view they had of the ecosystem was interesting. 22:10:46 ... There was a lot of pointing to places as deep topics that they could not get into. 22:11:09 ... I think the things they may feel are very difficult to provide input for... There would be so much variation they might not be able to tell us anything... 22:11:36 ... There were parts about... NIST, the standardization story... 22:11:40 ... It could take years... 22:11:54 ... So there were things like "If you're creating a DID method", please pay attention to X, Y, and Z. 22:12:13 ... We basically told them we would give the content to the WG, and they will look through it, and then have questions for them. 22:12:24 ... It is their expectation that we will have read the material and have detailed questions. 22:12:33 q+ 22:12:34 q+ 22:12:41 ... It's not going to be good if they show up and we haven't reviewed it. So please take a look, before the 7th when they present. 22:12:42 ack brent 22:12:47 ... I'll send a reminder 22:12:54 drummond: I was going to suggest exactly that. 22:12:56 q- 22:13:02 brent: Is there a link? PDF files? 22:13:09 manu: They are PDF files, we will send them... 22:13:22 ... Orie was thinking of checking them into the Implementation Guide. 22:13:26 Topic: Errata management for DID Spec 22:13:46 q+ 22:13:53 ack brent 22:13:57 burn: So, hat do we want to do? brent or manu, would you talk about what that means? 22:14:25 brent: In spite of our best efforts, the DID Spec will not be perfect. In order to address the unfortunately inevitable errors that people will find, we need some way to manage them - The errata need to be managed. 22:14:36 ... The suggestion to the group is to set up the same process that the VCWG set up. 22:14:50 ... In issues or PRs that identify errata, they can be labeled as such by the WG. 22:15:01 q+ 22:15:10 q+ to note it works well 22:15:12 ... After that, they will automatically be incorporated into a page that's linked to from the specification that says here are the errata that have been discovered. 22:15:14 ack burn 22:15:28 burn: One additional comment: this is really for mistakes. It's not for new features or anything like that. 22:15:33 ack manu 22:15:33 manu, you wanted to note it works well 22:15:36 ... It's often used for things like immediately obvious typos. 22:16:12 manu: +1 to that. The other thing to mention is... it works very well. It's the cleanest way of managing errata that I've seen for specs. It just depends on GitHub. The documentation generation is automatic, as far as I can tell. 22:16:18 q+ 22:16:20 ... It's a really simple, low-key automated process. 22:16:23 +1, sounds good. 22:16:24 ack kdenhartog 22:16:34 q+ 22:16:37 ack brent 22:16:45 kdenhartog: I presume we're going to keep it to non-normative changes for now. Or are we allowing normative changes as well? Not new features but fixes to normative statements. 22:17:12 brent: Errata refers to any bug or mistake. It doesn't necessarily imply it's been fixed. In some, in the VCWG we're working on addressing many of them. 22:17:29 ... It's difficult to imagine an errata that would require new features to address. That would be out of scope for the charter. 22:17:48 burn: I think Kyle was asking about not new features but substantive changes - affecting normative behavior. 22:17:51 Sweet thanks for clarifying 22:17:54 brent: Those are on the table for errata. 22:18:07 q+ 22:18:08 q? 22:18:09 burn: Just to point out, Kyle, it is just for bugs. If there is doubt, it likely will not go in as a bug fix. 22:18:10 example of the VC spec errata page: https://w3c.github.io/vc-data-model/errata.html 22:18:14 ack kdenhartog 22:18:31 kdenhartog: Thanks for clarifying that. My expectation is that for new features people will define extensions, as the recommended path. 22:18:43 burn: That's typical. No spec represents the final word. It's just the first version. 22:19:11 Topic: DID Rubric 22:19:13 ... Not only is it recommended to make extensions, but that will be helpful for the next versions, to have implementation experience. 22:19:20 q+ 22:19:25 https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/ 22:19:32 ack manu 22:19:49 manu: Just wanted to draw attention to the two issues on DID Core. 22:20:03 burn: Alrighty. 22:20:10 q+ to talk about did-rubric topic whenever it makes sense to do so 22:20:26 Topic: DID core issues 22:20:26 ... Since we don't have Joe on at the moment... let's just spend a few minutes on that, Manu. 22:20:32 manu: Thanks, apologies I missed that. 22:20:33 https://github.com/w3c/did-core/pulls 22:20:55 ... There are two PRs for DID Core: one of them is the acknowledgement section - I believe that is completely ready to merge... Well, there's one minor thing and then it's ready to merge. 22:20:55 s/Topic: DID Rubric// 22:21:18 ... I'm not hitting the merge button until the votes are in. I think that's the right thing to do? It won't autopublish... 22:21:38 ... The other Pull Request is for... Charles made a representation-specific entries change to the spec. I believe it's largely editorial. 22:21:50 ... I suggest we don't pull that in until after the votes are in and we're cleaning up the recommendation document. 22:22:07 ... Two questions: is that the process the chairs want? And does the group see any issue with pulling in these PRs? 22:22:46 manu: Charles, it's strange to make changes to the specification after putting it to vote. But I think they're totally okay as it's editorial. 22:23:00 q+ 22:23:01 +1 they're editorial 22:23:05 ack brent 22:23:05 brent, you wanted to talk about did-rubric topic whenever it makes sense to do so 22:23:07 ... "mostly editorial" -> I am asserting both of these things are entirely editorial - and would be surprised if anyone said otherwise. 22:23:20 ack drummond 22:23:27 drummond: I've looked at them and agree it's editorial. Not an issue. 22:23:46 burn: I'm not hearing any objections to pulling them in - when the time is right. 22:24:01 I also agree not to pull them into the final until after the vote is done. 22:24:05 ... I guess we could do it in the working copy... but they wouldn't apply until we get to the final specification. 22:24:10 q+ brent to talk about did-rubric topic whenever it makes sense to do so 22:24:29 manu: Editors... are we good to go? 22:24:51 +1 merge when it feels right 22:24:54 brent: To my understanding, he is satisfied. 22:24:58 +1 22:25:25 Topic: DID Rubric 22:25:28 ack brent 22:25:28 brent, you wanted to talk about did-rubric topic whenever it makes sense to do so 22:25:49 brent: This topic was put on the agenda to allow time for the group to discuss issues Joe addressed in the past. 22:26:05 q+ 22:26:14 ... I was hoping Joe would be here to lead it himself. The suggestion was made that it might make sense to turn the rubric into a Registry, rather than a Note. 22:26:18 ack drummond 22:26:26 q+ 22:26:44 ack kdenhartog 22:26:45 drummond: I was going to ask, it's too bad Joe's not here... A discussion about what does it mean for it to be a registry? 22:26:53 burn: I think an email was sent... 22:27:18 kdenhartog: I've been working on it... My understanding is he is looking for a way to register these documents... as a way of seeing who is making the statements. 22:27:34 q+ 22:27:38 ack manu 22:27:41 ... There is obviously some bias about who is making the statements. funding models... 22:27:43 q+ 22:28:04 The last email from Joe that briefly describes the rubric registry idea: https://lists.w3.org/Archives/Public/public-did-wg/2021Aug/0016.html 22:28:10 thanks 22:28:15 manu: I believe where Joe wants to take this is to allow anyone to make an analysis of a DID method. There's a website you go to to look at the rubric you care about. 22:28:31 ... You pick a criteria, then see what comes up, which methods are doing well or not, and see who said that. 22:28:42 ... So it's kindof a big dynamic registry of reviews that have been done using the rubric. 22:28:47 q+ 22:28:50 ack drummond 22:29:07 ... It helps you pick the things you are interested in, and then see how certain DID methods did along those axes. 22:29:24 drummond: I remember the blog post... that does clear it up. Wow, this one could get hairy. 22:29:38 ... The incentives here... I would equate it with the complexity of designing something like Amazon Reviews. 22:29:50 ... The incentives for promoting or demoting a method are controlled by the market. 22:29:53 ack markus_sabadello 22:29:59 ... This is a big deal. Not saying a bad idea, but need to think about it. 22:30:19 markus_sabadello: Besides the political challenges, there are also some practical considerations. We have done, with a research partner, evaluations of 7 different DID methods. 22:30:24 ... There's an issue open on the repo to add that work. 22:31:02 ... On that open issue, there is a question of what it means to add that work. We've published a PDF document that contains the evalations. Converting that to some specific form and then doing the PR to somehow add that would be a lot of work that I don't think we can do, for practical reasons. 22:31:13 ... In some cases people do it their own way and don't follow the registry rules. 22:31:14 q? 22:32:01 burn: Attempting to either remove bias, or to allow people to make their own decision as to whether bias has occurred... By creating a registry we are essentially removing the assumption of expertise of those who made the report. 22:32:21 q+ 22:32:22 ... There are people like Joe and Markus who understood deeply what it was about... If we create the registry, it would be very different from having a rubric document. 22:32:25 ack TallTed 22:32:43 q+ separate note from registry 22:32:44 "Tricky" is the right word for it. It could have great value and it could also be the source of great controversy. 22:33:15 TallTed: Mixed mind. It's a heavy lift to go down the attributes to decide which matter to them. But turning it into a public writable registry of reviews is dangerous in more ways than I can count. 22:33:18 q+ cel to ask about separate note from registry 22:33:23 q? 22:33:30 ... There are some ways in which this has zero value, and some ... national value. 22:33:58 ... Yelp shows reviews... for a restaurant with one hair on a french fry. I could see some getting dinged because someone on 8chan doesn't like it. 22:34:18 ack cel 22:34:18 cel, you wanted to ask about separate note from registry 22:34:19 scribe+ manu 22:34:51 skip 22:35:00 q? 22:35:32 q+ 22:35:36 burn: I don't think we have a particular decision. Without Joe on the call, I think it's going to be challenging to decide how we want to move forward this week. 22:35:37 ack brent 22:35:42 ... Any last comments? 22:36:01 brent: When Joe has spoke about it in the past, he said his plan would be to make the PR with the changes, and that would be where we could talk about it. 22:36:30 ... When we drafted the next charter, we added language that if this group hasn't already established registration requirements, then for the maintenance WG it would not be in scope for them to do so. 22:36:41 [burn reads from the charter] 22:37:31 burn: I'm not hearing people excitedly jumping up and down about having a registry. 22:37:38 ... We'll see when Joe creates the PR. 22:37:53 Topic: Implementation Guide 22:38:04 https://www.w3.org/TR/2021/NOTE-did-imp-guide-20210826/ 22:38:10 burn: We have an implementation guide, which is fabulous. 22:38:24 ... Is there something people would want to discuss. I think one was the SRI report? 22:38:24 q+ 22:38:25 q+ 22:38:28 ack brent 22:38:29 q- 22:38:49 brent: The suggestion was made by Orie that perhaps it would make good sense to include the documents that describe the review as part of the implementation guide linked to from it. 22:38:55 ... I'm curious what the group thinks of that notion. 22:38:59 q+ 22:39:05 ack manu 22:39:08 manu: I think it's a good idea. 22:39:34 ... The whole SRI review is part of an initiative to demonstrate to the world that we've done our due dilligence. We've had NIST look at it, ... CFRG. 22:39:41 ... A much broader review that most W3C specs. 22:39:48 ... We need to ... document it in perpetuity. 22:39:59 ... SRI's PDF - where do we put it? 22:40:13 ... Feel like Implementation Guide is best place. 22:40:28 ... In TR Space, it falls under the Library of Congress agreement. 22:40:40 ... +1 to putting it in the Implementation Guide and saying something that points to it. 22:40:59 burn: It would also be possible to publish it as its own Note - But procedurally I like the idea of putting it in the Implementation Guide 22:41:09 ... which is already a Note and easy to update. 22:41:14 +1 to implementation guide as well. It seems most relevant to that audience as well 22:41:32 +1 to putting it in the Implementation Guide. 22:41:34 ... I think we have support for putting it in the Implementation Guide, and think that will be the most obvious thing to do. 22:41:39 +1 to linking from implementation guide 22:41:56 Topic: DID Spec Registries 22:42:16 https://github.com/w3c/did-spec-registries/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Aneeds-contact-info+ 22:42:21 Need contact info" 22:42:42 q+ 22:42:45 ack manu 22:42:58 burn: Anyone who wants to walk through the issues? 22:43:13 manu: I can. Is there anything specific that folks would like to cover in the list? If not, I can pick 22:43:13 q+ 22:43:18 ack drummond 22:43:33 https://github.com/w3c/did-spec-registries/issues/244 22:43:51 drummond: I have to remind myself what the number is... There is one thing about the resource parameter which needs a spec... I am still working on it. Spec en route. 22:43:54 q+ to suggest #304 22:44:06 ... Probably don't need to discuss that one. 22:44:10 ack TallTed 22:44:10 TallTed, you wanted to suggest #304 22:44:13 TallTed: 22:44:26 ... Allowing multiple registration by the same name... 22:44:40 ... It's entirely likely people will create the same 3 or 4 character name. 22:44:50 https://github.com/w3c/did-spec-registries/issues/304 22:44:51 q+ 22:44:55 ... It seems worthwhile to let them all register, and let the collisions sort out naturally. 22:44:58 ack markus_sabadello 22:45:06 ... It puts things in the open, rather than let collisions happen more later. 22:45:14 markus_sabadello: For DID methods, or properties, or everything? 22:45:18 q+ 22:45:21 q+ 22:45:22 ack manu 22:45:26 TallTed: Initially I was thinking of methods, but I think it's worth it for all of them, really. 22:45:34 manu: I get the philosophy, Ted, of why we would want to do this. 22:45:49 q+ 22:45:49 ... I'm concerned that it allows bad actors to kindof mess with DID methods that they don't like. 22:46:04 q+ 22:46:13 ... First come first serve... Second registration -> Have a discussion, could create problem for community. 22:46:29 ... I'm concerned about saying we can have double registrations without something pushing back on it hard. 22:46:35 ack markus_sabadello 22:46:36 TallTed: I think there will be a lot of those conversations. 22:46:38 if we allow things to be registered twice what's the point of a registry? 22:46:45 agree with justin_r 22:46:46 Exactly 22:47:12 agree with justin 22:47:12 markus_sabadello: For DID methods, I think it's an interesting topic - I'm not sure I have a strong opinion. We did have a case in our Universal Resolver project where there were two different implementations of the same DID method - two implementations of two different DID methods with the same name. 22:47:15 q? 22:47:24 ... I think the argument could be made that there are different communities using the same name. 22:47:33 ack kdenhartog 22:47:41 ... For parameters, I think it would create problems for the data model and defeat the purpose of the registry. 22:47:55 kdenhartog: For methods, +0. As Markus highlighted. 22:48:05 ack drummond 22:48:09 ... For properties... 22:48:25 just consider https://acronyms.thefreedictionary.com/DID 22:48:27 drummond: I think allowing this would completely defeat the point of the registry. If there's contention, we can have a process for handling that. 22:48:44 ... The disambiguation on Wikipedia - which I love - resolves it by actually giving them different names. Is that's what being proposed? 22:48:59 ... But the registry entries need to be unique, or what's the point of having the registry at all. 22:49:16 TallTed: I'm hearing it, strongly disagreeing with all of you. It means a lot of people will not register what they are using. 22:49:17 q+ lets deal with it when it happens. 22:49:21 q+ to say lets deal with it when it happens. 22:49:22 q? 22:49:25 ack manu 22:49:25 manu, you wanted to say lets deal with it when it happens. 22:49:28 if they happen "in the wild" then people aren't using the registry 22:49:32 ... The collisions have likelihood of bad results in a big way. 22:49:55 manu: We're saying it could theoretically happen, and we're disagreeing... I suggest we delay, come back and rethink it. 22:50:20 ... If it's just 2 or 3, we talk to them and they change the name, fine. But if all of the sudden people try to registry, we tell them no and they use it anyway, that's a bigger issue we need to discuss. 22:50:44 TallTed: I'm not so much thinking of people who register before they deploy, but people who try to register a test thing they have already deployed and it will just be that way. 22:50:53 q+ 22:50:59 ... People trying to tell what they are dealing with by looking at the registry... it would be problematic. 22:51:20 burn: IANA has registries. Precisely this situation has occurred. Justin, could you talk about this? 22:51:20 ack justin_r 22:51:49 justin_r: I am not a deep expert on IANA processes. But there is a long-standing formal process. It basically boils down to, if someone shows up with something already registered, IANA is going to say now. 22:51:51 s/now/no 22:51:59 ... Unless they say it's an update to a thing we already know about. 22:52:12 ... For example, HTTP URI now points to the newest HTTP specification rather than the historical ones from the late 90s. 22:52:30 ... Things like that happen all the time. But those are cases where it's not two completely unrelated things trying to use the same name. 22:52:34 q+ 22:52:56 ... In IETF, registry must be consulted. In this WG, not, despite my arguing for it. 22:53:10 ... If people are going to collide in the wild, it means they're not using the registry to communicate. 22:53:25 q- 22:53:35 ... I could write a browser that does something weird with an HTTP URL. I'm allowed to, but it's not compliant and anyone using it will be confused. That's okay, that's supposed to fail - That's the whole point. 22:53:43 burn: Okay. Other comments? 22:54:05 completely disagree w/ted 22:54:06 TallTed: I think the things supposed to fail in that way are different... 22:54:39 burn: I think we are practically at the point, Ted, where if you can garner support for it, great, otherwise may just have to tell us I told you so. 22:54:44 q+ 22:54:47 TallTed: I'll put a bottle in the cellar and wait. 22:54:53 ack kdenhartog 22:55:04 kdenhartog: The date PR... almost done. #143 22:55:06 https://github.com/w3c/did-spec-registries/issues/143 22:55:36 "put a bottle of champagne in the cellar and wait" <== great remark 22:55:36 ... In this case, what I'm looking for is consensus on being able to specify dates, to be able to say we are compliant up to version X. 22:56:02 ... This has been a common issue communicating to our engineering team what features we support... and to external parties... 22:56:08 q? 22:56:12 ... so people could see if a feature is new and not supported 22:56:18 q+ to note compliance is usually to test suites... not to bleeding edge features. 22:56:21 ack manu 22:56:21 manu, you wanted to note compliance is usually to test suites... not to bleeding edge features. 22:56:25 ... Do people agree this is a problem? If so do you have any preferences on how I go about doing that? 22:56:52 manu: Usually, when talking with large organizations that really want you tell them what version you are compliant to, the best you can do is the latest point release 22:56:57 ... i.e. on TR 22:57:22 ... Anything experimental, not having a stable spec (W3C Rec or IETF RFC) - I don't think we can say much about those features. 22:57:33 ... We can say we are compliant to what so-and-so did there. Or to the test suite. 22:57:43 ... Until it's locked down, it's hard to say we're compliant to anything. 22:57:48 q? 22:58:10 q+ 22:58:15 ... For DID spec registries... it could happen at any time. I don't think it's useful, you're not going to implement everything in the registry. 22:58:30 burn: On GitHub, anyone can point to past history of anything. 22:58:34 ack kdenhartog 22:58:35 ... As Manu said, that's not that common. 22:58:55 kdenhartog: That's a good point. I left this open to see... For the large part people don't seem to have an opinion. 22:59:02 ... I'm alright closing this issue. 22:59:07 ... May reopen some day. 22:59:37 [talking about bottles in cellar] 23:00:17 rrsagent, draft minutes 23:00:17 I have made the request to generate https://www.w3.org/2021/08/24-did-minutes.html burn 23:00:24 rrsagent, make logs public 23:01:18 zakim, end the meeting 23:01:18 As of this point the attendees have been burn, brent, cel, justin_r, markus_sabadello, TallTed, shigeya, manu, drummond, kdenhartog, agropper 23:01:20 RRSAgent, please draft minutes 23:01:20 I have made the request to generate https://www.w3.org/2021/08/24-did-minutes.html Zakim 23:01:23 I am happy to have been of service, burn; please remember to excuse RRSAgent. Goodbye 23:01:27 Zakim has left #did 23:01:48 rrsagent, bye 23:01:48 I see no action items