14:50:58 RRSAgent has joined #did 14:50:58 logging to https://www.w3.org/2020/09/01-did-irc 14:51:00 RRSAgent, make logs Public 14:51:01 please title this meeting ("meeting: ..."), ivan 14:51:09 Meeting: DID WG Telco 14:51:09 Chair: burn 14:51:09 Date: 2020-09-01 14:51:09 Agenda: https://www.w3.org/mid/00000000000005d70b05adf3e34c@google.com 14:51:29 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Aug/0032.html 14:59:17 present+ 14:59:18 present+ 15:00:04 markus_sabadello has joined #did 15:01:46 present+ 15:01:48 present+ markus_sabadello 15:02:00 present+ dlongley 15:02:06 present+ brent 15:02:17 present+ identitywoman 15:02:20 justin_r has joined #did 15:02:21 scribe+ dlongley 15:02:21 Topic: Agenda Review, Introductions, Re-introductions 15:02:23 present+ 15:02:32 JamesQU has joined #did 15:02:39 selfissued has joined #did 15:02:42 present+ james 15:02:42 present+ rhiaro 15:02:45 present+ 15:02:47 jonathan_holt has joined #did 15:02:52 burn: Agenda for today is talking about the next topic call, talk briefly about the virtual F2F TPAC. 15:03:00 present+ jonathan_holt 15:03:14 burn: Then we'll have a status report on service endpoints and there's a bit more time on that and see where we can get with 20 minutes. Then move onto our regular status check. 15:03:32 +1 15:03:51 manu: It may be useful to review the process of proposals that are made on the special topic call and when those are viewed as effectively consensus from the group. Jonathan asked for some clarification there and I'd like that as well, perhaps not remembering the process. 15:03:55 present+ orie 15:03:57 burn: That's fine, right after the F2F reminder. 15:04:01 burn: Please remind me if I skip that. 15:04:04 burn: Anything else? 15:04:17 burn: Ok. Is there anyone who hasn't reintroduced themselves in a long time and would like to? 15:04:22 q+ 15:04:26 burn: How about Ivan? 15:04:34 burn: I'm sorry, go ahead Mike. 15:04:36 ack selfissued 15:04:42 brent has joined #did 15:04:50 present+ 15:05:22 selfissued: I'm Mike Jones. I work on identity standards at Microsoft. I've tried to built a JSON/REST stack to solve identity on the Web including Oauth, JOSE, WebAuthn, FIDO2 specs. I try to keep things simple enough that devs will use them and secure enough that they're worth deploying. 15:05:31 burn: Ok, thank you. 15:05:40 Topic: Next Topic Call 15:05:41 present+ dbuc 15:05:42 Orie has joined #did 15:05:44 agropper has joined #did 15:05:46 present+ 15:05:56 identitywoman has joined #did 15:05:59 present+ 15:06:02 present+ 15:06:10 q+ 15:06:20 burn: The next topic call will be in approximately 7 hours from now and will be on the test suite. Although it is not required to have a test suite before CR, it is highly recommended since you can't exit CR until you have sufficient implementations which requires a test suite. 15:06:20 present+ 15:06:25 ack manu 15:06:35 https://github.com/w3c/did-core/issues/384 15:06:35 burn: It's also good practice and a lot of the work you do has to do with what you discover when you build tests. 15:06:40 present+ pam 15:06:59 I made this thing based on the last conversations we had regarding test suite... https://github.com/OR13/did-core-tests .... and I am cowering in fear of amy's list.... 15:07:07 Topic: TPAC FF2F 15:07:08 manu: Amy has put together a fantastic review of every normative statement in the spec, whether or not its testable, proposed changes, so on. If you have a chance to look at that today before the special topic call please do, it's a great set of work. 15:07:16 present+ dmitriz 15:07:21 https://github.com/w3c/did-core/issues/384 15:08:04 q+ 15:08:05 burn: F2F meeting will be virtual for TPAC. We had announced a week. It turns out that IIW was that week. We didn't know that and we forgot to check that. In the doodle poll no one marked themselves as not being available and we had a laugh with Kaliya about that. The meeting will be now Nov 2nd-5th. Same times. We will send an email out. 15:08:09 burn: There's a link in the agenda. 15:08:11 https://www.w3.org/2019/did-wg/Meetings/F2F/2020.11.VirtualTPAC.html 15:08:23 ack identitywoman 15:08:27 burn: You can see the dates and times on there, please reserve them. 15:08:39 identitywoman: Note on IIW, early bird pricing ends next week, if you're coming, go buy your ticket. 15:08:46 burn: Ok, thank you. Any questions about the timing of our TPAC meeting? 15:08:49 http://www.internetidentityworkshop.com 15:09:05 Topic: special topic calls and how normative they are 15:09:08 burn: Ok. The next topic is the one that we added. Special topic calls and how normative they are, essentially. 15:09:11 q+ 15:09:32 JoeAndrieu has joined #did 15:09:51 burn: Brent and I have been very careful to try and draw a line between meetings that are essentially official -- decisions are made at them but there's a time for confirmations. This meeting slot is the official slot. The special calls are extra and we don't want people to feel like they have to attend those. 15:10:20 burn: You can come up with tentative resolutions, but they don't matter until you bring them to the group. You can bring them up on a call but our favorite is via the issues. 15:11:04 q+ 15:11:04 ack brent 15:11:05 burn: Those resolutions from the special calls are non-binding but they need to be reflected in an issue or as a pull request. If there's a disagreement on the PR and you were on the call we might ask "What changed your mind?". If you weren't, your input can be considered new. 15:11:15 https://www.w3.org/2019/did-wg/WorkMode/#communications 15:11:16 brent: I'd like to bring everyone's attention to our official work mode document. 15:12:02 brent: This is the communications section, it talks about rules and guidelines around teleconferences. Though we differentiate between our weekly official time and the special topic calls -- the rules around resolutions made in both are really the same. The reason I say that is because even the resolutions in our official call still requires 7 days with a call for consensus. 15:12:20 brent: According to the group -- we have to do that for our regular calls anyway. We feel very strongly that we need those 7 days. 15:12:37 present+ 15:12:43 present+ wayne 15:12:48 present+ drummond 15:13:05 burn: The difference I was trying to draw between the two: If you don't attend a special topic call and don't read the minutes, it's still not a binding decision, the special topic calls weren't intended to create binding decisions. Whereas, the official call, if you don't attend it and you don't follow the minutes, a decision could be made that you didn't see. 15:13:10 drummond has joined #did 15:13:24 present+ 15:13:35 ack ivan 15:13:36 brent: An example of a differences is that in our regular call we might come to consensus that we want a set of PRs to be merged immediately. On a special topic call we wouldn't do that, we'd say raise a PR so we can continue the discussion. 15:14:05 q+ 15:14:17 ivan: This is a coincidence, but I will deploy a separate page soon on the website that lists all of the resolutions that we've made on the calls, strictly separating the ones made on the official calls vs. the special topic calls. The list itself will update itself. 15:14:18 ack manu 15:14:19 present+ 15:14:36 manu: Yeah, I just wanted to see -- if, given those definitions, if jonathan_holt thinks there was a process violation. 15:15:24 q+ to note one issue in this process. 15:15:28 jonathan_holt: No. I agree that those were non-binding. And important to get work done, and I just want to make sure that if people were on vacation or missed the 7 days, I want to make sure that we give people enough time to object. We bring things back to the group to ensure we have consensus. I want to make sure we have a broader discussion of such an important topic. 15:15:30 ack manu 15:15:30 manu, you wanted to note one issue in this process. 15:15:41 dbuc has joined #did 15:15:45 present+ 15:16:18 manu: Just to go into that a bit more. I have one concern with the process. The resolutions that we made were to write a PR. That was the outcome of the special topic call -- once the PR is written you have another 7 days. In this particular case I don't think there's any issue. I am concerned about people thinking that the special topic calls... that it's possible to completely ignore them. 15:16:54 manu: And if the resolutions aren't brought up on the main call then that's grounds to object at some point in the future. You can always object on the PR. I think that's our gating factor. The proposals and resolutions on the special topic calls are there to make steady progress. The minutes are posted on the mailing list. 15:17:46 manu: A fairly negative read of what the chairs have said is that "Oh, I don't have to pay attention to those special calls and it will be raised on the main call." That's not always going to be true. If the editors create a PR based on something from the special topic call and someone comes and says "but that doesn't matter, I wasn't there", I think that's a problem. 15:18:00 manu: I want to make sure we're not opening ourselves up to "It happened on a special topic call, it doesn't count." 15:18:52 burn: I hear you, Manu. We were trying to keep the process as light as we could get away with. There is an ability for someone to be disruptive in that manner. At the time that we discussed this we also said things like "Don't be a jerk." And that means, "Don't actively ignore other discussions going on on a topic you care about just to complain later." The chairs will not look favorably on that. 15:19:21 burn: If it turns out that someone who really cares about something was on vacation for 2 weeks and missed the 7 days -- and wants a chance to look at a decision that was made, we can make a call there. 15:19:36 burn: We can get really specific about process here but I think people won't like it. Just don't be a jerk and it applies in both directions. 15:19:39 That feels clear to me :) 15:19:57 brent: I would like to second "nobody be a jerk". 15:20:03 +1 to that 15:20:04 burn: Any other questions/comments? 15:20:05 +1 15:20:09 Topic: Service Endpoints Status Report 15:20:20 burn: I don't know who was going to do this -- go ahead Manu. 15:20:55 manu: The last special topic call was on service endpoints. We had a good discussion starting off. The thing that was effectively raised toward the end was whether or not we need to be able to express service endpoints in DID documents at all. 15:20:58 https://github.com/w3c/did-core/issues/382 15:21:06 manu: As a follow up to the discussion, we raised an issue, #382. 15:21:24 manu: It was raised as a suggestion that we didn't need to express them in DID documents and discussion continued from there. 15:21:41 manu: On the special topic call, we did seem to agree that we should talk about service endpoints and their privacy characteristics in a non-normative appendix in DID core. 15:21:55 -> Minutes of the latest topic call on service endpoints https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-08-27-did-topic 15:22:02 manu: If you do service endpoints wrong, you can violate privacy, it can be a GDPR/etc problem. We can talk about it more. 15:22:42 manu: The second resolution was that we should have an abstract data model in the DID spec for service endpoints (and we already do). During the conversation it sounded like some people thought we didn't have that or shouldn't or whatever. The other resolution that we would have an abstract data model in the spec in normative language effectively like we've done with verification methods. 15:23:11 manu: The third resolution had to do with service endpoint extensions. How do you express them, how do you talk about types of them, etc. The resolution is that we should describe how you extend service endpoints in the DID specs registries. 15:24:05 manu: 382 follows it up asking whether or not we need to express service endpoints in DID documents at all. The discussion is not about eliminating service endpoints, no one is proposing that there. The proposal is -- should we suggest that people put them in DID documents or through some other mechanism like a VC or a DID Auth protocol or DIDComm, etc. 15:24:31 manu: There are lots of comments there and every variation of what could possibly happen. It's a good thread to catch up with where people are. If you're interested in the topic, please put input into that issue. 15:24:38 q+ 15:24:38 q? 15:24:42 ack markus_sabadello 15:24:45 manu: I don't know if anyone else would like to add anything with respect to where we are with service endpoints. 15:24:58 q+ 15:25:23 ack agropper 15:25:25 markus_sabadello: I wanted to add that during the special topic call -- I made a comment that we didn't have that much time to discuss. It was about registering service endpoints types in the registries. It was related to extending the service endpoint data model. It was about whether service endpoint types should be registered, I have some opinions on that. 15:26:13 agropper: A quick note, I think we need ... from the glossary project we put a comment in there, I think we are to have the concept that some service endpoints are not normatively described in the spec, they are option but if you do the data model is normatively described. The others are just the others. I think we have some potential to get to consensus if that's a good way to think about it. 15:26:22 q+ 15:26:25 ack manu 15:26:32 agropper: Did I say something beyond the resolutions as described beyond what was described by Manu. 15:27:24 manu: I said on the call, yes, that's one way you can think about it. I think it would be challenging to get consensus around a specific number of service endpoints. I don't think the discussion isn't around that or the number of them, right now it's more about how you communicate service endpoints. Again, I don't think anyone wants to eliminate them entirely, it's about how to communicate them, whatever they may be. 15:27:40 manu: I don't think we could pick up your thing and get consensus on it because I think we have to get the first discussion out of the way first. 15:27:54 agropper: But the sense is that some service endpoints will eventually be normatively described in the spec? 15:28:04 q+ 15:28:20 q+ 15:28:22 ack markus_sabadello 15:28:23 manu: At present, it looks like nothing will be, we will describe an abstract data model but not put any specific ones in DID core. But we'll have an extension mechanism that will allow people to add them. They can be normatively described outside of the DID core spec. 15:28:30 ack drummond 15:28:59 drummond: Adrian shouldn't feel that even if there are none described in DID core, there may be descriptions and examples in the implementation guide. It's a subject we should pay attention to. 15:29:12 burn: We're reaching the end of our time for this topic. 15:29:59 manu: What are the next steps here? We're collecting data on that issue, please put information there. The editors will act on the last special topic call. We'll create a non-normative appendix PR and talk about extensions and privacy. 15:30:19 manu: We will make sure to keep the abstract data model for service endpoints in the specification and create a PR to talk about how to extend via the registries. 15:30:29 manu: Noting that Markus has some concerns around that. 15:30:45 burn: I answered Dave Longley -- he had asked informally if there will be another special topic call on service endpoints. 15:31:02 manu: Yes, if the topic doesn't terminate. Dan Buchner has called for another special call. 15:31:12 dbuc: Yes, apps and services, the 99% of identity that isn't VCs, etc. 15:31:27 manu: Yes, there may be a special call around that which is related. 15:31:33 burn: Ok, anything else? Ok, thanks. 15:31:34 Topic: Core issue status check 15:31:50 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 15:32:09 https://github.com/w3c/did-core/issues/119 15:32:43 burn: We finished an explainer. We offered a document for the group to review, Ivan gave us comments, we're working through it and we're close. Brent are we close, done? 15:33:05 brent: There was some additional text we might throw into the OID section. 15:33:30 burn: We might start the TAG review without the privacy and security review -- we can always add that later. We want to make sure we can get this started. It can take them a month or two before they even look at it. 15:33:36 https://github.com/w3c/did-core/issues/104 15:33:56 burn: We are leaving this open just to make the transition easier. 15:34:03 https://github.com/w3c/did-core/issues/105 15:34:19 burn: This is similar, same thing. Left open for the same reason. 15:34:28 https://github.com/w3c/did-core/issues/205 15:34:39 burn: Justin, unknown properties. 15:35:10 justin_r: There is a PR #362 that relates to this. Once again, I am not enough of a JSON-LD expert to really understand what's going on here. At least I think #362 relates to it. 15:35:18 burn: I'm scrolling up to look for that link and I don't see a reference to it. 15:35:20 362 has merge conflict and not response from pr author... 15:35:35 justin_r: Yeah. I just opened up the PR to see what might be addressing this. This is not addressed. 15:36:10 burn: Can you take a look at this and write some kind of status on it? Whatever you understand the status to be on a status in the issue? Whether it needs a PR or that PR is not good enough for X reason. I know this is a big topic and there are disagreements about this too. 15:36:14 q? 15:36:36 justin_r: Fundamentally the group needs to land on a solution across representations that makes sense. It's my view that we should take the loose JSON extendability by fiat model. But if we don't do that, we need to be explicit about that one way or another. 15:36:38 q+ 15:36:56 justin_r: Orie is saying in the issue tracker about addressing it with mimetype, etc. 15:37:06 ack selfissued 15:37:12 burn: I'm thrilled that you're intrigued because it means you can ask that in the issue. 15:37:35 selfissued: I support Justin's position to just allow not understood properties should be ignored, we already say that in the JSON section. We should say that in the abstract data model section. 15:37:51 burn: Just be prepared for a discussion if the unknown property is "@context". 15:37:55 https://github.com/w3c/did-core/issues/202 15:38:17 justin_r: I think this is fine. 15:38:29 scribe+ 15:38:35 scribe+ 15:39:21 manu: I don't know what dave is trying to say in two of the sentences, just asked for clarification 15:39:29 dlongley: I will take a look at 362 and see if that can get resolved 15:39:32 dlongley: Looks like Manu commented and I need to take a look at 362. 15:39:48 https://github.com/w3c/did-core/issues/324 15:40:09 agropper: I think we need to hold off until we make more progress on 324. 15:40:25 agropper: #382 also relates to this. I think we have to go further with 382 before we can revisit the privacy issues. 15:40:39 https://github.com/w3c/did-core/issues/266 15:41:23 burn: So, this is where it gets interesting. You asked the submitter for feedback on July 28th. It's been more than a month. 15:41:57 burn: This is a case where, as a chair in the WG, I suggest that you change your comment to not say waiting for feedback but give a deadline and what will happen at the end of that deadline if you don't hear back from that commenter. 15:42:17 q? 15:42:19 manu: We decided it's a no-op for us and we'll close in 7 days unless there's an objection. 15:42:24 burn: Yes, thank you. 15:42:34 https://github.com/w3c/did-core/issues/174 15:43:35 burn: There's a PR that's been merged, that was referenced -- can you please take a look at this, Mike? 15:43:42 selfissued: ok. 15:43:54 burn: It looks like some work has been done to address your initial issue. 15:43:56 selfissued: Ok. 15:43:57 burn: Thank you. 15:44:06 https://github.com/w3c/did-core/issues/341 15:44:35 burn: Assigned to Christopher. Manu -- you had the most recent comment. I assume Christopher's not on the call. 15:44:40 manu: Christopher is not on the call. 15:44:57 burn: Right, so your final comment is that we need more specificity to move forward. 15:45:05 manu: I can say still waiting, I doubt we're going to do anything about this. 15:45:29 burn: I think that's the right comment to put. Just be more explicit that unless we hear from him -- it's not a 7 day close because he's a group member. But this issue is on track to being closed with no action without more details. 15:45:30 q+ 15:45:34 manu: Ok, writing that. 15:45:36 q+ 15:45:40 ack ivan 15:46:07 ivan: My question/comment, the whole CBOR issue is still unclear to me. We don't have agreement on how we will use CBOR as far as I know. Until that is solved, this issue should probably be left open because we don't know. 15:46:13 q+ to note we hav eother CBOR issues 15:46:16 ack selfissued 15:46:40 selfissued: I put this in the issue, but to be clear, the WG doesn't have to be involved to register tags at all. The IANA policy just needs a stable document that can be anywhere. 15:46:51 q- 15:46:58 q+ CBOR issues exist 15:47:01 q+ to note CBOR issues exist 15:47:22 burn: Chair level comment -- you're right, Mike. Anyone can request to register a tag, if the tag is related to something we're doing, then there might be a desire/request for the WG to be ok with it. That's the only caveat. But you don't have to wait for anybody to do it. 15:47:38 ack manu 15:47:38 manu, you wanted to note CBOR issues exist 15:47:41 selfissued: Yeah, I agree. To the extent that he proposed specifics to the WG we should look at it, but we needn't block on this. I'll say that in the issue. 15:48:17 manu: Agree with everything that's been said. I will say that there are other CBOR issues that are more specific and actionable. I'm going to say that we're going to close this one because we have specific suggestions in other issues -- and we should close as a duplicate unless he says otherwise. 15:48:23 https://github.com/w3c/did-core/issues/340 15:49:15 jonathan_holt: I was going to remove the section in the CBOR ... where keys must be byte strings -- to open the doors for CBOR-LD in the future. I want to make sure I have a valid representation of a signature. 15:49:16 q? 15:49:21 burn: Please summarize that in the issue itself? 15:49:25 jonathan_holt: Yes. 15:49:26 https://github.com/w3c/did-core/issues/338 15:49:27 burn: Thank you. 15:49:47 jonathan_holt: I was going to remove the service endpoint based on our previous discussion and the proof section mostly because the CDDL is not necessarily conformant because we're in flux. I can close this. 15:49:52 burn: Any objections to closing/ 15:50:05 s/closing\/closing?/ 15:50:07 burn: Go for it. 15:50:11 https://github.com/w3c/did-core/issues/185 15:50:32 s/closing\//closing?/ 15:50:39 q+ 15:50:48 burn: Any comment on this, Orie? 15:50:51 ack Orie 15:51:25 Orie: I think we have pretty much eliminated the need for this ticket. The consensus appears to have been that the verification method type defines supported algorithms both for signatures and key agreement. And that's up to the verification method author that creates the it to decide to allow/disallow a particular set of encryption/signature algorithms. 15:51:45 Orie: I think when we merged JSONWebKey we added support for the algorithms in IANA and we can close this. 15:52:03 burn: I suggest you say that in the issue and do a 7 day close... actually, no, I leave it up to the core spec editors to say if it's ready for a 7 day close. 15:52:12 burn: But go ahead and make your arguments for closing in the issue, I think you're probably right. 15:52:24 https://github.com/w3c/did-core/issues/367 15:52:31 burn: This is administrative. 15:52:40 burn: Did this already happen, Orie? 15:52:44 manu: No, it should be assigned to me. 15:52:53 q+ 15:52:59 q- 15:53:05 manu: There are issues in DID spec registries that should be in DID core and I took an action to move them and haven't done it yet. 15:53:33 https://github.com/w3c/did-core/issues/359 15:53:43 burn: Daniel? 15:54:02 This one is deep into the service endpoint discussion. 15:54:41 in a world where every json property can be a string, array or object.... type concious developers cry tears of sadness. 15:54:50 dbuc: So, right now the service endpoint property is polymorphic, it could be a string or an object of stuff. Originally, I wanted it to be an array ... and then Orie said it should be object period. I don't know what the next move is without getting more commentary and then everyone makes another property underneath and it's non-standard. 15:54:56 q+ to suggest a PR as a concrete conversation starter 15:54:59 burn: So is there any consensus around any particular approach here or not? 15:55:08 dbuc: I don't know think people know or they don't care. 15:55:22 ack brent 15:55:22 brent, you wanted to suggest a PR as a concrete conversation starter 15:55:26 burn: Yeah, you should raise awareness and maybe do a poll. You may only get the two of you still. 15:55:44 brent: PRs are really good conversation starters. That may bring people out of the woodwork to say "Noooo" 15:56:03 burn: Good idea, create a PR if you want instead of a poll since that's where you'll end up anyway. Anyone can do that, not just Daniel. 15:56:07 burn, I updated the issue - we have about converged in a PR so this should be closed soon 15:56:08 https://github.com/w3c/did-core/issues/122 15:56:42 burn: Status is that this will be closed when another PR is merged. Oh, Amy just put that comment in, thank you. 15:56:46 https://github.com/w3c/did-core/issues/368 15:57:11 dbuc: So, I think that this is resolved. 15:57:20 burn: If you think it's resolved and you're the submitter you can close it. 15:57:28 burn: Let me just ask quickly -- would anyone object to closing this? 15:57:39 burn: No objections, just make sure to leave a comment of why you think it's closed. 15:57:45 burn: Or why you think it can be closed before you close it. 15:57:47 dbuc: Done. 15:57:48 burn: Cool. 15:57:59 https://github.com/w3c/did-core/issues/339 15:58:52 jonathan_holt: That's mine. It seems that people still have reservations about CBOR but they seem to understand how important it would be in the future state. And the emerging support for CBOR-LD. Other than the byte string should be extensible ... using the framework Manu presented at the F2F, I don't see why it should be marked as at risk. 15:58:55 burn: Ok, we can leave it for now. 15:59:01 is it still marked as "at risk?" I'm not finding that in the spec. 15:59:04 burn: I am going to do a very important thing before we end today's call. 15:59:10 burn: Anything else from anyone? 15:59:27 manu: orie: https://github.com/w3c/did-core/issues/359#issuecomment-684960017 15:59:31 burn: The important thing is to thank our scribe. I had a round of several weeks where I forgot to do that. 15:59:38 Thank you Dave!!! 15:59:39 burn: Thank you, Dave and Amy and Manu for stepping in. 15:59:58 burn: Thank you, Thank you, Thank you, wish you all a good 6 hours before our topic call. 16:00:07 zakim, end meeting 16:00:07 As of this point the attendees have been ivan, burn, manu, markus_sabadello, dlongley, brent, identitywoman, justin_r, james, rhiaro, selfissued, jonathan_holt, orie, dbuc, 16:00:10 ... agropper, JamesQU, pam, dmitriz, wayne, drummond, JoeAndrieu 16:00:10 RRSAgent, please draft minutes 16:00:10 I have made the request to generate https://www.w3.org/2020/09/01-did-minutes.html Zakim 16:00:12 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:00:16 Zakim has left #did 16:01:01 rrsagent, draft minutes 16:01:01 I have made the request to generate https://www.w3.org/2020/09/01-did-minutes.html ivan 16:04:25 Orie_ has joined #did 17:03:05 dlehn has joined #did