14:56:26 RRSAgent has joined #did 14:56:26 logging to https://www.w3.org/2020/05/05-did-irc 14:56:30 RRSAgent, make logs Public 14:56:30 please title this meeting ("meeting: ..."), ivan 14:56:56 Meeting: DID Working Group Telco 14:56:56 Chair: burn 14:56:56 Date: 2020-05-05 14:56:56 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020May/0000.html 14:56:56 ivan has changed the topic to: Meeting Agenda 2020-05-05: https://lists.w3.org/Archives/Public/public-did-wg/2020May/0000.html 14:56:57 present+ burn 14:57:55 present+ 14:59:19 phila has joined #did 15:00:05 sumita has joined #did 15:00:44 present+ 15:00:44 present+ 15:00:56 identitiywoman has joined #did 15:01:12 markus_sabadello has joined #did 15:01:27 dezell has joined #did 15:01:38 present+ 15:01:42 present+ 15:01:43 BrettMcDowell has joined #DID 15:01:46 present+ 15:01:50 present+ 15:01:57 present+ 15:02:05 brent has joined #did 15:02:09 present+ 15:02:14 scribe+ dlongley 15:02:15 present+ 15:02:36 eugeniu_jolocom has joined #did 15:02:47 justin_r has joined #did 15:02:58 Topic: Agenda Review, Introductions, Re-introductions 15:02:59 present+ 15:02:59 paulmadsen has joined #did 15:03:00 present+ 15:03:16 present+ 15:03:21 present+ 15:04:14 drummond has joined #did 15:04:20 present+ identitiywoman, manu, drummond, dezell, justin_r, chriswinc 15:04:24 present+ 15:04:25 jonathan: I am a triple board certified physician, been at Stanford/Vanderbilt, and a healthcare/cybersecurity health. Been recruited to a subsidiary of Consensys. They are heavy into consensus and the ethereum platform. I'm deep in the projects for COVID-19. 15:04:49 burn: Next is the review of the agenda for today. Anything anyone wants to bring up on today's call? 15:05:02 manu: Are we going to discuss the next special topic call time/date? 15:05:04 burn: Yes. 15:05:17 burn: After the statuses. 15:05:22 present+ paulmadsen 15:05:31 burn: That will be at the end. In fact, we will make sure that that gets brought up. 15:05:35 Topic: Today's call is a status check 15:05:42 burn: Today's call is a status check. 15:05:45 oliver has joined #did 15:05:53 present+ oliver_terbu 15:06:11 brent: We've been doing a lot of awesome stuff lately. Great conversations about resolution contracts and meta data, what should a DID identify, what should section 6 have, etc. This is a reminder of our timeline. 15:06:13 https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.g60978c4f6c_35_15 15:06:26 present+ jonnycrunch 15:06:27 brent: If you follow the link -- that's our original timeline. The red circle says May 2020 feature freeze. 15:06:48 brent: This is probably not going to happen. But, this is a reminder, this is the point at which we wanted to have everything pretty much settled. 15:06:49 dbuc has joined #did 15:06:53 joel has joined #did 15:07:02 present+ 15:07:02 Orie has joined #did 15:07:05 brent: We have a long process yet to go through with CRs and PRs and the whole W3C process. We have a lot of work that is underway that is left to do. 15:07:08 present+ joel 15:07:08 present+ 15:07:13 present+ 15:07:28 dlehn: The point of this call is to figure out what is left for us to do so we can more formally move forward, freezing features, refining the document, getting formal reviews. 15:07:32 present+ oliver 15:07:40 burn: I think just a reminder of the pieces of the doc and what's relevant would be good. 15:07:52 burn: When I go to a conference like IIW I think it's good to say what we're talking about again. 15:08:06 brent: We need to get back to main topics, core contract, meta data, what else needs to be settled before we can move the main spec forward? 15:08:13 brent: Also, what's going on with the DID registries. 15:08:19 present+ dmitriz 15:08:37 brent: We also have an implementation guide (who will write it what goes in there?) and a use cases document (pretty much done?). 15:08:45 brent: We have a DID rubric we need to check in on. 15:08:48 Topic: Resolution Contract Conversation Status 15:08:50 brent: This call is about all this. 15:08:56 q+ 15:08:57 q+ 15:08:59 q- 15:09:02 q+ 15:09:11 ack markus_sabadello 15:09:15 jonathan_holt has joined #did 15:09:15 guest+ adrian 15:09:18 Tom_S__-_USAA has joined #did 15:09:19 q- 15:09:21 oliver_ has joined #did 15:09:21 present+ 15:09:26 present+ jonathan_holt 15:09:28 present+ oliver_terbu 15:09:44 markus_sabadello: Status of the resolution contract discussion is basically, I did the original PR about a month ago to add content related to DID resolution which was replaced with a new PR from Justin and others, and then Manu did a great job splitting that up into 4 different PRs. 15:09:57 markus_sabadello: One that adds non-normative stuff to the architecture, that has already been merged. 15:10:21 markus_sabadello: So we have some content on that now in the spec. The 3 remaining PRs that Manu created based on the original content from Justin, myself, and others. 263,264,265. 15:10:22 https://github.com/w3c/did-core/pull/263 15:10:25 https://github.com/w3c/did-core/pull/264 15:10:30 https://github.com/w3c/did-core/pull/265 15:10:46 markus_sabadello: They are all about normative content. The first 263 is normative content about DID resolution. 264 is normative content about DID URL dereferencing. 265 is about normative content about meta data. 15:11:08 q+ to note what the draft PRs are waiting on. 15:11:26 markus_sabadello: They are still marked as draft PRs and personally I think they are going in the right direction. They have normative content about the nature of important outputs of resolving DIDs and derefing DID URLs, they express the abstract interface not the implementation which matches the expectation from the F2F. 15:11:55 markus_sabadello: We have external references to the DID resolution spec without making those normative. Phil Archer has reminded us to be very careful there. Personally I think they are in good shape and may require a bit more review and back and forth. 15:12:07 ack manu 15:12:07 manu, you wanted to note what the draft PRs are waiting on. 15:12:12 identitywoman has joined #did 15:12:17 burn: Ok, I will take Manu next but I wanted to ask next steps. Is there more discussion needed, do we just need to work on PRs, so on? 15:13:15 manu: They are split up in a way that we need to focus on. They are in an order that I think we'd take them in. DID Resolution lays the basis, URL derefing is split from the meta data discussion. It seems there is some disagreement on URL dereferencing and its place on the spec and we'll need to discuss that with Joe because he seems to have the strongest feelings. 15:13:43 manu: For the special topic call we need to figure out how we're testing this stuff. Based on the resolutions the group made about charter interpretation. This allows us to test things more directly which is good. 15:14:09 identitywoman__ has joined #did 15:14:10 manu: Part of the DID resolution call should probably be reviewing the existing test suite we have, how it was architected, and how we'll do DID resolution tests. And once we do that how the language in the spec will support that. 15:14:42 manu: One of the concerns I had was that some of the statements would be difficult to test but some of the language in those PRs may change around the concreteness of what we're testing. 15:14:53 manu: I wanted to take a bit of time and look at Markus's PR because it had some good language. 15:15:08 manu: Understanding what we need to do with the test suite -- and once we do that I think everything will fall into place. 15:15:13 manu: With the other PRs. 15:15:19 Topic: Metadata Conversation Status 15:15:23 q+ 15:15:25 burn: Ok, great. Moving onto next topic. 15:15:31 ack markus_sabadello 15:15:43 q+ to talk about metadata vs. metadata structure 15:16:25 markus_sabadello: Meta data is closely related to resolution and the three PRs we were just talking about. The last one is about meta data. That is covered by this work. I encourage everyone to review and rethink what it was that we took out of the meta data discussion. There was a different understanding of what "created" meant -- DID subject created, DID document created, when it was resolved, so on -- this is how we got to different buckets. 15:16:37 markus_sabadello: That means some things in the spec would now be considered meta data -- like created, updated, proof, etc. 15:16:53 markus_sabadello: We may consider those to be meta data about the DID Document rather than core properties (about the DID subject). 15:16:54 +1, really like what Markus just said. 15:16:57 +1 15:17:07 ack justin_r 15:17:07 justin_r, you wanted to talk about metadata vs. metadata structure 15:17:36 agropper has joined #did 15:17:42 present+ 15:17:45 justin_r: +1 to everything Markus just said. Also to point out PR 265 really doesn't define meta data properties so much as it defines a data structure to contain meta data. The thinking behind this was first we have a structure so that all meta data statements conform to it. 15:17:59 justin_r: Once we agree to it we can figure out which properties are meta data and what their property names and values look like. 15:18:16 burn: That's a good reminder, we haven't agreed on what is meta data or not, we have just been working on structure. 15:18:22 justin_r: Yes, this creates the buckets. 15:18:28 justin_r: Next we must decide what goes in them. 15:18:32 +1 to "creating the buckets" and then deciding what goes into them. 15:18:34 burn: So next steps? 15:18:42 burn: Just the review you asked for? 15:18:51 markus_sabadello: Yes, and review the original issue that was discussed, #65. 15:18:52 burn: Ok. 15:18:56 Topic: Abstract Data Model Status 15:19:09 https://github.com/w3c/did-core/issues/65 15:19:10 burn: Drummond can you give us an update on that? 15:19:11 https://github.com/w3c/did-core/issues/203 15:19:21 drummond: That section is complete now, the PR made it through the Manu-filter. 15:19:33 drummond: I don't know of any outstanding action items directly related to defining and completing that section. 15:19:58 burn: I didn't really ask you this, but could you talk about the front matter, this is the structure of the document and so on, I know a lot is in flux. 15:21:11 drummond: You bet. The one section with several outstanding bits is Section 3. I looked at what is currently in Section 1, the intro, and some things that are now in Section 4 which is conformance, and I recognized that a lot of that very early text that goes back 3.5 years now. We really need a clean approach to all the front matter, there's duplication in some places, there are older things that don't need to be in a mature spec such as positioning 15:21:11 statements. 15:21:24 kimhd has joined #did 15:21:30 Agree with Drummond that we need significant Editorial rework to refactor the spec to make it easier to read... concerned about the timeline for doing so and getting horizontal review. 15:21:31 drummond: My suggestion is to do a clean up since it's all editorial. So that it reads smoothly and as elegantly as we can with the introduction. 15:21:41 s/statements./Drummond: statements./ 15:22:09 q+ to offer to help 15:22:09 drummond: That's the general approach, and it will take time and I know that we want to get ready for horizontal review. I want to get feedback from the editors to see if we can substantially improve the front matter in one pass. 15:22:14 q? 15:22:17 drummond: So we can modernize that section and simplify it. 15:22:20 ack rhiaro 15:22:20 rhiaro, you wanted to offer to help 15:22:33 q+ to agree to and time box the refactoring. 15:22:38 ack manu 15:22:38 manu, you wanted to agree to and time box the refactoring. 15:22:38 rhiaro: I just wanted to say that I've had doing a pass through that whole section as an editorial for a while now so I'm happy to help with this. 15:23:18 manu: Agree with drummond on all of those points, it's the timing of those points that I'm concerned about. If we time box it and you can get through it this week and through next week I'm comfortable with that. If it drags on for 4 weeks that's an issue for horizontal review. 15:23:23 manu: What do you think? 15:24:03 drummond: I can stop writing this email because that's what I'm proposing. I want to get that done, my big chunk of time is over the weekend. I want to get it proposed and get feedback on the PRs next week. It's all non-normative and editorial, it's important, but it's not the final pass just a substantial improvement. I want to be done with it by the end of next week. 15:24:04 +1 to that. 15:24:06 q? 15:24:08 drummond: After review and everything. 15:24:10 burn: Ok. 15:24:14 burn: Do you need anything else, Drummond? 15:24:17 drummond: Nope. 15:24:25 Topic: Status of the spec 15:24:31 burn: The next item is status of the spec. 15:24:56 burn: After we've heard all of these different pieces -- all parts of the spec that have to go in. Can you speak to overall status of the spec, Manu -- horizontal review and next steps? 15:25:32 manu: Yes. The spec is getting into good shape. I feel like a lot of the big big conflicts at least to this point have been resolved. We do still have 70 outstanding issues. I would think about 50 of those we will get to, just based on W3C history/how it goes, 20 we won't. 15:25:42 mnzaki has joined #did 15:26:19 manu: Overall, we're in decent shape but behind schedule. We wanted to start going into CR now and we're not there. Once Drummond gets this rewrite in that's the last bit to get horizontal review. We should be able to get that out with the document in a state that's acceptable for HR, and a way to get responses back before we go into CR. That's good news. 15:27:21 manu: I am a bit concerned about a couple of issues like capability-based stuff that we haven't necessarily talked about. There's some registries stuff that we haven't talked about that do impact the core spec. At a high level we're in pretty decent shape. In the last week I was about to finally make a complete pass all the way through the spec and set down a good base layer. Nitpicky stuff like overflows, section alignments, etc. But the spec is now in a 15:27:21 state where we can parallelize a lot of the changes to the spec. 15:27:45 manu: That should help Drummond and Amy because they have stable foundation, it helps the meta data/resolution stuff for the same reason and editorial processing, etc. 15:28:27 manu: If everyone rolled up their sleeves with the PRs assigned to them we could probably process 10-15 in parallel at this point. My expectation is that it will be 2-3 months before going into CR. That's a significant delay. We still need a test suite, we need to dust that off and prep it for Cr. 15:28:30 s/Cr/CR/ 15:28:34 manu: But it feels doable. 15:28:45 s/state where we can parallelize a lot of the changes to the spec./manu: state where we can parallelize a lot of the changes to the spec./ 15:29:05 burn: Consider Manu's comments a motivation to work not be discouraged. The group has had a number of issues and disagreements to work through and that's normal. 15:29:18 burn: It's normal to work through them and I'm very pleased with the direction I'm seeing and the work that's been done. 15:29:20 q+ registries stuff 15:29:28 burn: The work tends to go faster once the major items are resolved. 15:29:33 burn: Thank you to Manu and the other editors. 15:29:38 burn: Anything to add before we move on? 15:29:40 q clear 15:29:45 q+ Orie 15:29:47 q- registries 15:29:49 q- stuff 15:29:54 s/q clear// 15:30:05 ack Orie 15:30:09 drummond: No, I agree with Manu. We will get over the hump, I'm worried about little land mines in the issues and those may take some time and until we process those we won't know how close we are to the finish line. 15:30:25 Orie: I wanted to give an update on where we are in terms of properties that are documented and not documented. There are a couple of layers to comments on the registries. 15:30:44 Orie: The first layer is on the editors side, we are close to covering most of the properties that have been floating around in DID core in DID core registries. 15:31:18 Orie: Most properties there are documented now. Now the question is did we document them in the right place, what should be in DID core, in DID core extensions, somewhere else, etc. That's worth having a deeper conversation there and how to get the separation of concerns right for interop there. 15:31:26 q+ to mention that registries should be Special Topic call... we need to make some important decisions w/ the group. 15:31:36 Orie: Just as an implementer working on the tests, the process of adding properties to the registries is too heavy and I haven't see any contribution to it. 15:31:45 q+ 15:31:58 present+ dpubc 15:32:07 present+ dbuc 15:32:25 Orie: If we're running late, I think we're setting ourselves up for some pretty significant failure and there's an opportunity to cut around the structure there and reduce the burden for getting things into the DID core registries. From a pragmatic technical note, I've asked around about this, I haven't seen anyone shipping DID Documents that are JSON only or CBOR only. 15:32:43 Orie: I understand the desire there but I worry as a developer we are specing things that no one is using. 15:33:05 Orie: I'm eager to ensure that the DID core spec is usable for DID developers and I want to make sure we can do that. 15:33:13 burn: Now is definitely not the time to discuss that but I recognize your concern. 15:33:26 burn: I'm worried that the queue will grow here. But we do need time to focus on the issues you brought up. 15:33:27 ack manu 15:33:27 manu, you wanted to mention that registries should be Special Topic call... we need to make some important decisions w/ the group. 15:33:55 +1 to special topic call on the registries. 15:34:02 manu: One of the things that we should probably put on the agenda is focusing on the registries stuff because it's very important work. We should have a special call on the registries because Orie has done fantastic job there and there's little engagement from the WG and we need a call on that. 15:34:24 Topic: next topic call 15:34:26 burn: The next item on the agenda is the next topic call. Two parts to that: What should it be on? Is registries the next most pressing item. 15:34:42 burn: For others, btw, we normally have an editors call and we normally discuss this but we didn't have a call because of IIW. 15:34:49 burn: Manu, is it registries? 15:35:00 manu: Totally up to the group to decide. I think we could have a productive discussion around registries. 15:35:00 Perhaps we can focus on registries after we purge all the random props from the Core spec 15:35:03 burn: Ok. 15:35:15 This might just be a newbie question... we just spent the call going over status of various deliverables, their dependencies, and how our roadmap is changing. Is this all documented in a single document somewhere? 15:35:22 ack dbuc 15:36:24 dbuc: Just a general aversion to the registries stuff. I understand extensibility is important to people. There are a bunch of properties in the spec that have zero description. While the doc has absolutely undefined terms it also doesn't define important terms. The capability delegation stuff has no line of definition in the entire spec. There are recommended places for using them. I want to see those defined or purge them. 15:36:33 dbuc: If they can't be defined I don't understand why they are there. 15:36:44 burn: Ok, we don't have time to go into that today, thank you. We need to talk about registries, that's very clear. 15:36:54 Move all undefined props to a registry of pending props 15:36:59 burn: The next special topic call will be on registries, and it will be on Thursday. That's an issue for some of you actually. 15:37:18 burn: The reason we were going to put it on Thursday is that there wouldn't be enough notice to do it today, particularly unfair to those in NZ wouldn't even know that they needed to be awake. 15:37:36 this thursday is rough 15:37:37 burn: Who would not be able to attend on Thursday at 12 ET/9PT/6PM CE? 15:37:39 tha'ts fine for me 15:37:41 can't 15:37:48 -1 to thursday 15:38:00 I postulate that if the chairs wrote this all down in a single document it would have a magical impact on accelerating these deliverables getting done. I could shop that around for resources in my own company, for example. I can't do much with this IRC chat log. 15:38:01 burn: There are a number of people I just happen to know are unavailable this Thursday this week. 15:38:13 burn: Chairs will discuss. It's possible it will be next Tuesday. 15:38:16 the late tuesday one would be less good :s 15:38:30 burn: We know we have to get onto those calls and but we'd be missing important people on Thursday. 15:38:37 Topic: Status of Notes: Imp Guide, Rubric, Use Cases 15:38:44 burn: Next, please be as brief as you can here. Phil? 15:38:55 -> https://www.w3.org/TR/did-use-cases/ latest 15:39:04 phila: Joe and I had been working on the Use Cases document you may/may not be aware that the latest version was actually pushed just at the end of last month. 15:39:14 -> https://github.com/w3c/did-use-cases/issues Issues 15:39:15 phila: We think that the content is pretty much done except for the small matter of all the issues. 15:39:45 gannan has joined #did 15:39:57 phila: Various people have been raising issues, Joe and I admit freely, a long time ago. Now we need to work through the issues, some issues transferred from the CCG. We will be working our way through it. Some we can take care of ourselves but we will ask for time to go through them on some of these calls. 15:40:07 phila: We will race through and try to get those issued knocked off. 15:40:47 burn: So the implementation guide is the last one. That has not been moving. 15:40:48 q+ 15:40:52 burn: I don't know that we have an update on that. 15:40:52 ack manu 15:40:54 https://w3c.github.io/did-imp-guide/ 15:41:18 manu: It has not been moving. That is correct. The implementation guide is where text goes to die right now. We don't want to be in that position. We can say some very useful things about practical implementation considerations. 15:41:30 manu: The only thing it has in it are the JSON-LD extensibility sections from the DID core spec. 15:41:42 manu: There are many other things that we probably want to say in there but we need someone with the time to write those sections. 15:42:17 manu: The idea candidate is probably someone that is an implementer of some kind, has done multiple DID method implementations, what the considerations need to be when implementing. In short, that's Orie, but he's crazy overworked, we shouldn't volunteer him. 15:42:22 I am in favor of deleting things 15:42:40 if it can't be done well, it should not be done. 15:42:44 q+ 15:42:51 manu: Up to him but we should have a fresh person on this. Someone who has time to talk about what people using DIDs should consider or what to consider when implementing a new DID method/what to consider when using DIDs in their architecture. 15:43:08 manu: We're in danger of not shipping the implementation guide at this point. Not enough there and not enough time to fix it. 15:43:26 ack markus_sabadello 15:43:28 burn: The implementation guide is really important for the other things we've done. It's the place for things that don't belong in the spec but you need to know about. 15:43:35 burn: Please let the chairs know if you want to help there. 15:43:54 q+ 15:44:02 markus_sabadello: There are some new things that should actually go into the implementation guide that are being proposed to go into the DID core spec. I've written some comments about that proposing that people contribute to the implementation guide. 15:44:10 markus_sabadello: There are some candidate, concrete topics that should go in there. 15:44:11 ack ivan 15:45:03 ivan: I just want to understand what exactly the scope is or will be for the implementation guide. If I take one of the use cases, any of them, that describes the problem area and where a DID can be used, but if I want to see that not fully implemented but understand how the various features properties, registry items are used together to make an implementation of that use case, where would I find that? 15:45:04 q+ 15:45:06 ack manu 15:45:14 ivan: Is that the implementation guide or for those that want to implement a DID method? 15:45:53 manu: The first thing you said is more correct. If we do it correctly the implementation guide tells you how to use DIDs to handle their use case. Step 1, step 2, step 3 for choosing DID method, choosing a resolver, doing create/update, all that stuff. 15:46:13 q+ 15:46:25 ack ivan 15:46:28 manu: We've called them primers in the past, but it's more than that. If I want to implement by use case using DIDs here's a document that tells me what to do/what other specs to look at. There should also be a section in the guide about what DID method implementers need. 15:46:34 +1 to having a separate section for method implementers. 15:47:00 ivan: All that you said is very useful. But I would expect it to go a bit deeper than that to understand what the spec is talking about. We need one or two examples: You want to prove/check this or that, these are the things you have to do. 15:47:07 ivan: At least you have the feeling that these are the steps you use. 15:47:33 q+ 15:47:36 Filed to start the discussion: https://github.com/w3c/did-core/issues/272 15:47:40 ivan: It's very difficult to understand when you just read the spec .. how these things will work out in practice .. when you're the user and you expect these things to happen. I understand that for the full use case you need to know about VCs or something, but so be it. 15:47:45 ack burn 15:47:47 ivan: We go into details here will probably shut it down. 15:47:49 E.g. this is one DID Core spec issue which in my opinion could be covered by a contribution to the Implementation Guide: https://github.com/w3c/did-core/issues/151 ("Include discussion of eIDAS levels-of-assurance") 15:48:01 burn: There is a opportunity for those that wish to write informative articles, books, whatever to help in that way. 15:48:32 burn: There are things that only our group can do. There are things that others outside of our group can do. The things that only we can do are the things that Manu mentioned. Saying "this spec does not live in isolation, you need to know these other things to understand the spec." 15:48:42 burn: Others can fill in and add value elsewhere. 15:48:54 burn: I see Kim volunteering. 15:48:57 present+ kimhd 15:48:59 ivan: Thinking about volunteering. 15:49:05 +++1 to Kim!!! 15:49:23 kimhd: I'm thinking about it out loud. I've not been as involved in the group until recently, this might be a good forcing function and I've implemented a few DID methods. I'll get back shortly. 15:49:32 burn: Thank you, Kim. 15:49:38 burn: That would be a big help. 15:49:50 burn: Anyone else that would help that would be incredibly valuable. 15:50:15 burn: I rushed us through the agenda. We specifically left off the normal issue review and triage. Are there any other major items that we've missed as far as the summary? 15:50:25 q+ 15:50:26 q+ 15:50:41 q- 15:50:57 burn: I know, Phil, you need regular call time ... if you wanted people to focus on one thing, what would it be? 15:51:57 phila: One of the things, "What does it mean for a DID to be recorded in a registry?" When the original use case document was written, all DIDs were recorded in a registry of some kind and now we're saying, oh they don't have to be. There are some terminology bits like relying party and so on need addressing. Use case docs set out the problem space, not the solution, but we don't want to use a term in the use case doc that means something else in a spec. 15:52:00 -> https://github.com/w3c/did-use-cases/issues/14 15:52:04 phila: Please think about issue 14. 15:52:19 phila: Joe and I can't answer that, we need some input on that. 15:52:27 ack manu 15:53:09 manu: The other thing that we need to start prioritizing is test suite. So we can go into CR fairly comfortably and come out of CR in one piece. We need someone to lead the test suite effort. Andrew Jones is the person that wrote the DID test suite, the previous version 6-8 months ago. 15:53:39 manu: We need to bring that up to date, talk about the architecture, how we are testing resolution, all that stuff. We need to start having dedicated call time for that or special calls for it, something so we can put together a test suite and have implementers see how they do against the test suite. 15:53:53 burn: It sounds like one of these calls should be dedicated to getting the testing effort started. 15:54:13 burn: More than a few seconds of detail. That will be our opportunity to get people involved and then we'll need to move it off to other calls. 15:54:27 burn: Everyone that does the testing work knows there's a group that does that on their own and then they report back to the main group. 15:54:31 burn: Thank you, Manu. 15:54:42 burn: The chairs will schedule that in. Anything else for today? 15:55:14 burn: Thank you everyone! I really do mean that, we've made really good progress to get this point and we will see some really nice progress on issues because they stacked up on other major issues. 15:55:15 s/mice/nice/ !! 15:55:28 burn: Thanks again, talk with you next week! 15:55:38 zakim, end meeting 15:55:38 As of this point the attendees have been burn, ivan, sumita, rhiaro, chriswinc, dlongley, BrettMcDowell, identitiywoman, dezell, phila, markus_sabadello, eugeniu_jolocom, brent, 15:55:42 ... paulmadsen, manu, drummond, justin_r, oliver_terbu, jonnycrunch, joel, Orie, dmitriz, Tom_S__-_USAA, jonathan_holt, agropper, dpubc, dbuc, kimhd 15:55:42 RRSAgent, please draft minutes 15:55:42 I have made the request to generate https://www.w3.org/2020/05/05-did-minutes.html Zakim 15:55:44 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 15:55:48 Zakim has left #did 15:56:56 rrsagent, bye 15:56:56 I see no action items