14:52:14 RRSAgent has joined #did 14:52:18 logging to https://www.w3.org/2024/08/01-did-irc 14:52:22 rrsagent, draft minutes 14:52:23 I have made the request to generate https://www.w3.org/2024/08/01-did-minutes.html burn 14:52:29 rrsagent, make logs public 14:52:52 Chair: Dan Burnett 14:52:55 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0034.html 14:53:08 Meeting: Decentralized Identifier Working Group 14:53:14 present+ 15:01:01 decentralgabe has joined #did 15:01:05 present+ 15:01:26 present+ 15:01:38 phila has joined #did 15:01:38 KevinDean has joined #did 15:01:43 Wip has joined #did 15:01:45 bigbluehat has joined #did 15:01:47 present+ 15:01:51 present+ 15:01:54 present+ 15:02:01 Topic: Agenda Review, Introductions 15:02:01 markus_sabadello has joined #did 15:02:06 present+ 15:02:41 present+ 15:03:06 andres has joined #did 15:03:19 scribe: KevinDean 15:05:01 burn: 10 minutes of work item status updates, major topic splitting the DID spec registry. 15:05:11 danpape has joined #did 15:05:32 JoeAndrieu has joined #did 15:05:40 present+ 15:05:56 scribe+ 15:05:59 present+ 15:06:03 present+ 15:06:03 present+ 15:06:05 Topic: DID Method Standardization Announcement 15:07:14 https://blog.identity.foundation/decentralized-identity-leaders-partner-to-accelerate-did-method-standardization 15:07:26 Topic: APAC Meeting Time 15:07:28 decentralgabe: A number of us across different organizations have talked about a way to standardize DID methods. We have started a letter of intent that communicates this intent. Letter to be provided in chat including link to register interest in participating in this effort. More to come. 15:07:46 - Thursday 5-6 pm US Pacific Time 15:07:46 - Thursday 8-9 pm US Eastern Time 15:07:46 - Friday 0200-0300 Central European Time 15:07:46 - Friday 8-9 am Hong Kong 15:07:47 burn: We have chosen a meeting time and day that is more convenient for those in Asia. 15:07:47 The time in Asia will change by one hour when we go off of Daylight Savings Time. 15:08:05 ...All of these you are seeing are all the same time in different time zones. 15:08:19 JennieM has joined #did 15:08:26 present+ 15:08:27 ...Anyone who doesn't do Daylight Savings Time will notice an hour change. 15:08:58 ...Not yet decided which weeks we will do this. We may do it the fourth and fifth Thursday, or only the fifth Thursday, yet to be decided. 15:09:13 ...Once decided, it will be added to the W3C calendar, which will be updated automatically. 15:09:16 stephan has joined #DID 15:09:30 Topic: Reminder: Special topic call 7 Aug 15:09:39 ...Our first special topic call is going to be August 7. 15:09:57 ...It will be on the AG Spec data model. 15:10:24 Topic: Work Item Status Updates 15:10:25 q+ 15:10:35 ack manu 15:10:36 ...We'd like each of the primary document editors to get on the queue. 15:11:09 manu: For the DID Core specification, we've gone through and classified all issues as class 1, 2, or 3. Many have not yet been assigned. 15:11:17 s/AG Spec/Abstract/ 15:11:26 ...Not much to change until we've had further discussion. 15:11:59 ...We do have some pull requests that I can't process either because the submitter didn't respond or they changed our recommendation document, things like that. 15:12:11 ...Those PRs are probably not going to go anywhere and will be closed. 15:12:35 ...For DID Spec Registries, the good news is that the volunteers and I have been able to process every open PR. Some new ones as of yesterday. 15:12:46 ...Merged if acceptable, or requested changes if appropriate. 15:13:16 ...There are a number of issues on DID Spec Registries that have not gone in the process yet, could use some help there. Will have discussion today. 15:13:16 q+ to ask about process to start the DID Method Rubric registry transformation. What's the next step? 15:13:28 ack JoeAndrieu 15:13:28 JoeAndrieu, you wanted to ask about process to start the DID Method Rubric registry transformation. What's the next step? 15:13:49 JoeAndrieu: What do we need to do to get the DID Method Rubric transformation going? 15:14:08 ...There are things we need to specify and we need a method to do so. 15:14:29 burn: Yes, let's include that in the discussion about the DID Spec Registries. 15:15:14 markus_sabadello: Regarding DID Resolution and DID URL Dereferencing, I sent an email to the list sharing the slides and created issues in the repository for what I considered major topics that the specification should cover. 15:15:27 ...Four in total. 15:15:52 ...What I would be most interested in is if the WG agrees with the scope and content and in particular with the topics at a high level. 15:16:04 ...In general, want to know if this going in the right direction. 15:16:26 ...I raised an issue on the DID Core Specification to move some to the DID Registries Specification. 15:16:29 brent has joined #did 15:16:59 ...One thing I haven't done yet is gone through the open issues on DID Resolution and categorize them but I've had a call with Christopher Allen who has offered to help. 15:17:16 Topic: Splitting the DID Spec Registries 15:17:32 Email and slides from last week's presentation about DID Resolution: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0033.html 15:17:37 q+ 15:17:40 burn: Should have been called "What to do with the various registries" document. 15:17:47 ack manu 15:17:52 ...25-30 minutes before I start pushing people to wrap up. 15:18:02 At first glance, splitting out every section into a separate registry document probably overkill. One possible organization is to split into 5 portions: 15:18:03 DID Properties (current §5: Property Names, §6 Property Values) 15:18:03 DID Representations (current §7: Representations, §8 Representation Specific Entries) 15:18:03 DID Metadata (current §12: DID Document Metadata, §13 Parameters) 15:18:03 manu: I want to start with Christopher's proposal, which I think was pretty solid. 15:18:04 DID Resolver (current §9: DID Resolution Options, §10: DID Resolution Metadata, §11: DID Dereferencing Metadata) 15:18:05 DID Methods (current §14) 15:18:23 ...Christopher is saying why not take the current document and split into these sections. 15:18:55 ...Each would become a separate document. Let's keep the repository so we can track all the issues for these documents, create subdirectories to manage each of them. 15:19:09 markus_sabadello has joined #did 15:19:10 ...That would be the first major cut at an update. It feels fairly mechanical and easy to do that. 15:19:21 https://github.com/w3c/did-spec-registries/issues/568#issuecomment-2239510427 15:19:29 ...I did in this comment suggest mechanically how we would do that. 15:20:15 ...There are a couple of details we need to figure out, like where do we state what the process is, do we state it in every document. I suggest a top-level document that says we have these different parts and the process for registering in every one of them is the same. 15:20:52 ...I'm wondering if we want to rename the technical report to DID specifications. This is a collection of different DID specifications broken down by category. 15:20:56 /TR/did-specifications/ 15:21:06 ...Pretty easy to do and redirect. 15:21:52 ...The other thing, and maybe the controversial thing, I think it's fine to run it under the W3C registry process. I don't that's an issue. However, I think we do need to clearly communicate that we are not the DID police, we're not going to say what's good and what's not. 15:22:22 ...I think some of the responses of some of the people outside the community about centralizing the registry shows that there's a problem. 15:22:52 q+ to ask whether "did-registries" would be better than "did-specifications" and to confirm whether separate documents or just separate sections 15:23:01 ...People in this community know that's not what we're doing. We need to be clear that this is a set of specifications, not the end-all and be-all, we're just providing documentation, whereas sometimes registries are used as enforcement mechanisms. 15:23:14 ...I think we should strip the word "Registries" off of what we are doing. 15:23:23 ack burn 15:23:23 burn, you wanted to ask whether "did-registries" would be better than "did-specifications" and to confirm whether separate documents or just separate sections 15:23:57 q+ 15:24:12 q+ 15:24:15 burn: I'm just concerned that "DID specifications" for registries when there are already DID specifications will confuse people. 15:24:23 q? 15:24:26 ack manu 15:24:32 burn: I'm also concerned about them being separate documents vs. separate sections. 15:24:52 manu: It is separate documents. I think we'll have each one in TR space. 15:25:14 s/I'm also concerned about them being/Clarification: will we have/ 15:25:17 ...Here is a central document that talks about all the extensions. Each directory will be about properties, extensions, etc. 15:25:31 ...One place in TR, multiple documents underneath. 15:26:01 q? 15:26:08 ack markus_sabadello 15:26:11 ...I strongly argued against did-registries, we probably don't want did-specifications. We could use did-extensions, but it also includes the stuff in did-core. Naming stuff is really difficult 15:26:48 q+ to ask if anyone disagrees with the proposed approach? 15:26:54 ack burn 15:26:54 burn, you wanted to ask if anyone disagrees with the proposed approach? 15:26:56 markus_sabadello: I agree that if it's called did-specifications it would be really confusing. I never felt that did-registries was too bad because we were always clear that registration was not mandatory. I like something about extensions. 15:27:11 q+ to ask about process 15:27:13 burn: Is there anyone who disagrees with that proposed approach? 15:27:15 ack JoeAndrieu 15:27:15 JoeAndrieu, you wanted to ask about process 15:27:50 q+ 15:27:50 q+ 15:27:52 JoeAndrieu: My questions is related to DID Method Rubric. The first step in the writeup of the new registries stuff is that we get formal definitions that the group agrees to. 15:27:53 q? 15:27:54 smccown has joined #did 15:27:58 ack decentralgabe 15:28:05 present+ 15:28:23 decentralgabe: Speaking as an individual, not a chair, I always thought it was a little confusing that methods were always co-located with properties. 15:28:31 ack manu 15:28:31 ...I see value in separating them. 15:28:45 manu: +1 to that, Gabe. The proposal is to separate them. 15:29:01 +1 to separate methods from extensions 15:29:11 ...Responding to Joe, we have a table format that I agree we need to formalize. 15:29:37 ...I think we also need to revisit and reformalize the process. There are some weird things we say from the early days that we may want to clarify. 15:29:47 ...There are things that need to be cleaned up. 15:29:56 ...I don't know when the best time to do that would be. 15:30:23 ...There's an interesting proposal entirely to split out DID methods entirely from what we are discussing. 15:30:42 ...The did-extensions document may include some of the material in the did-core document so we have to be careful. 15:31:01 ...Interested to hear if we wholly want to separate DID methods and DID extensions. 15:31:18 q+ to support two namespaces 15:31:18 burn: It's a nuisance to move things from one TR space to another after we started. 15:31:19 It is annoying to move things :) 15:31:22 ack JoeAndrieu 15:31:22 JoeAndrieu, you wanted to support two namespaces 15:31:49 JoeAndrieu: I like the different namespaces. We have a different dynamic about name squatting between DID methods and DID extensions. 15:32:01 Personally, +1 to separate top-levels for methods and extensions 15:32:13 ...Maybe a DID method needs to be conformant to be in the registry. 15:32:36 ...We are the point of centralization, we just need to minimize it to the spec as much as possible. 15:33:02 burn: What I'm definitely not seeing is concerned. Manu, would you be willing to put together a draft proposal to get approval on a direction? 15:33:11 dmitriz has joined #did 15:33:19 JoeAndrieu: Where are we going to iterate on the definition of these registries? 15:33:27 ...I don't know if I should do it now. 15:33:40 burn: I don't have a strong opinion. 15:33:50 s/if I should do it/where I should do it 15:34:05 decentralgabe: Folder seems reasonable. 15:34:47 burn: Joe, do you need an answer before Manu submits the proposal? 15:34:55 JoeAndrieu: No, so I'll wait. 15:35:48 q+ 15:35:53 ack Wip 15:36:15 q+ to upgrade to authorizing two "registries" 15:36:26 ack JoeAndrieu 15:36:26 JoeAndrieu, you wanted to upgrade to authorizing two "registries" 15:37:30 scribe+ 15:37:37 q+ 15:37:46 ack Wip 15:37:53 burn: are we doing 2 registries or 5? 15:38:02 KevinDean has joined #did 15:38:07 present+ 15:38:19 Wip: W3C registry path is a separate question. We want to split these up, but do we also want to follow the W3C process? 15:38:19 I agree with Will, I think it's orthogonal, too. 15:38:22 Lost connectivity. I can resume scribing. 15:38:24 scribe+ 15:38:31 Maybe change `using one directory/file per section` to `using one directory/file/namespace per section`? 15:38:31 Also note that each "W3C Registry" is *one* table, where these would seem to be one table per section 15:38:33 scribe- 15:38:34 q? 15:38:35 q+ 15:38:40 ack JoeAndrieu 15:38:59 q+ 15:39:04 ack TallTed 15:39:05 JoeAndrieu: Good point, Will. I don't want us to do this twice. We should follow the process before we start moving repos around. 15:39:30 +1 to TallTed 15:39:32 q+ to opine on TR structure being important to define now 15:39:35 TallTed: Each W3C registry is one table, so this would seem to be one registry per section. I suggest changing "one directory file" to "one directory file namespace". 15:39:43 ack burn 15:39:43 burn, you wanted to opine on TR structure being important to define now 15:40:09 burn: I think what is important here is that we establish the structure. What goes into that particular structure, whether it is a W3C registries document, is up to us. 15:40:16 s|changing "one directory file" to "one directory file namespace"|changing "one directory/file" to "one directory/file/namespace"| 15:40:26 ...Doing it properly now will have us a lot of work down the road. 15:40:48 manu: I wasn't clear if people wanted me to remove the "W3C registries" sentence. 15:40:50 q+ 15:40:55 ack decentralgabe 15:41:16 +1 to keep it in 15:41:16 decentralgabe: I think it's best to keep the registries bit for now and we could later determine if we want to issue another patch, but I would keep it. 15:41:45 burn: This is going beyond what we originally discussed, which was that we would leave that decision until later. 15:41:58 JoeAndrieu: Is there anyone that we know of that expressed concern that isn't here? 15:42:04 ...It wasn't in the agenda. 15:42:20 "repositories will" -> "repositories are currently likely to" 15:42:29 decentralgabe: I don't think the proposal is considered adopted by the group until after the minutes are published. 15:42:40 burn: Yes, one week after minutes are published. 15:43:06 burn: Ted has proposed some additional wording change, want Manu to note that. 15:43:10 no concerns. thanks 15:43:20 ...Joe, if you still have concerns, a week's notice might not be sufficient. 15:43:31 PROPOSAL: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries. 15:43:56 s/PROPOSAL: Split/DRAFT PROPOSAL: Split/ 15:43:59 ...I will note for the chairs, this is the first time that we are making contentful decisions. The chairs will send out a note pointing out that there were decisions made in the group that will be assumed to be agreed upon if no objections within a week. 15:44:23 ...Any concerns with this draft proposal before we vote? 15:44:25 PROPOSED: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries. 15:44:33 +1 15:44:34 +1 15:44:35 +1 15:44:36 +1 15:44:36 +1 15:44:37 +1 15:44:38 +1 15:44:39 ...In IRC, +1/-1. 15:44:40 +1 15:44:41 +1 15:44:43 +1 15:44:48 +1 15:45:03 RESOLVED: Split the did-spec-registries into two repositories: did-extensions and did-methods. Place DID Properties, DID Representations, DID Metadata, and DID Resolution into did-extensions using one directory/file/namespace per section. Place DID Methods into did-methods. The two repositories are likely to be managed as W3C Registries. 15:45:13 ...I declare this to be resolved. 15:45:26 ...Clearly that's not everything we need to discuss in respect to registries. 15:45:32 ...On to Joe's question. 15:45:55 JoeAndrieu: What do I need to do next for the DID Method Rubric. I need to put forward a formal definition of the group to review. 15:46:04 +1 to that path forward ^ 15:46:11 +1 15:46:23 q+ 15:46:26 ack manu 15:46:58 manu: Joe, have you put thought into how the rubric is going to be managed over time? One mechanism we can use is that lots of different items can go in, I don't know how people can propose them. 15:47:08 q+ 15:47:15 ...I'm concerned that many will be proposed. Do we want it in one big document or lots of little pieces? 15:47:18 ack JoeAndrieu 15:47:52 JoeAndrieu: One thing I think we should do is switch to a JSON preprocess loop to make it easier to fit into the HTML. 15:47:54 Good, that's what I was hoping Joe would say :) ^ 15:47:56 q+ 15:48:17 ...The rubric is structured by category. I'm not sure what you mean about people wanting to put things in there. Right now, it's all about methods. 15:48:28 ack manu 15:48:40 ...Opening the aperture to discuss things like security suites may be interesting but a lot of work. 15:48:59 manu: I don't know how much exposition we want to do in the rubric document. I'm fine with us keeping it simple. 15:49:24 q+ to bemoan evaluations 15:49:31 ...I was wondering what goes with some of these rubrics. There are some evaluations, but I heard Gabe say that we will do them. 15:49:33 ack JoeAndrieu 15:49:33 JoeAndrieu, you wanted to bemoan evaluations 15:49:34 q+ to clarify 15:50:06 zakim, close the queue 15:50:06 ok, burn, the speaker queue is closed 15:50:09 JoeAndrieu: Evaluations are one of the biggest flaws in the current rubric. What we found was that even though there were six of us in a room together, we ended up talking past each other. 15:50:28 ...The current DID Method Rubric is dominated by the six methods that were top of mind at the time. 15:50:31 ack decentralgabe 15:50:31 decentralgabe, you wanted to clarify 15:50:43 ...Once we start publishing evaluations, we may have political problems. 15:51:07 zakim, open the queue 15:51:07 ok, burn, the speaker queue is open 15:51:07 decentralgabe: I think something like the evolved version of the rubric is something we could have alongside DID methods. 15:52:00 JoeAndrieu: My summary is that we have clear marching orders to come up with a formal definition. We have marching orders to move forward with DID method rubric. 15:52:10 ...We need to kick it around some more. 15:52:30 burn: We have these two primary documents. Please ping the chairs if you would like time to discuss something. 15:52:41 Topic: Next week: Issue and PR Processing 15:53:11 ...We're trying to predict what the topics will be for the upcoming weeks. It can change if there's something really urgent. What we really want to do is get into regular issue and PR processing. 15:53:28 ...What this means is that we will be asking the editors which of the issues and PRs will benefit from call time to discuss. 15:53:46 ...The chairs will endeavour to have them sent out in the agenda, but that may not always happen. 15:53:51 ...Keep an eye on issues and PRs. 15:54:29 rrsagent, draft minutes 15:54:31 I have made the request to generate https://www.w3.org/2024/08/01-did-minutes.html burn 15:54:42 stephan has left #did 15:57:41 StephanBaur has joined #did 15:58:06 StephanBaur has left #did 15:58:23 stephan has joined #DID