14:52:01 RRSAgent has joined #did 14:52:05 logging to https://www.w3.org/2024/08/22-did-irc 14:52:05 rrsagent, draft minutes 14:52:07 I have made the request to generate https://www.w3.org/2024/08/22-did-minutes.html burn 14:52:10 rrsagent, make logs public 14:52:26 Meeting: Decentralized Identifier Working Group 14:52:31 Chair: Dan Burnett 14:52:35 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0019.html 14:54:17 present+ 14:56:21 present+ 15:01:17 KevinDean has joined #did 15:01:19 present+ 15:01:20 present+ 15:01:25 bparth24 has joined #did 15:01:44 Present+ 15:02:22 Wip has joined #did 15:02:24 present+ 15:02:37 manu has joined #did 15:02:37 present+ 15:02:41 present+ 15:03:15 swcurran has joined #did 15:03:24 scribe+ 15:03:29 + 15:03:35 Topic: Agenda Review, Introductions 15:03:54 present+ 15:04:17 TallTed has changed the topic to: DID WG Agenda 2024-08-22 https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0019.html 15:04:50 burn: Agenda for today, announcement from PA, DID Core issue/PR processing, rest of time is DID Resolution issue/resolution PR processing. Any request for changes 15:04:50 q+ 15:05:03 ack manu 15:05:42 I've messaged Joe to see if he can join. 15:05:46 manu: Let's introduce the controller concern brought in VCWG yesterday. 15:05:50 To discuss the controller concern. 15:05:54 burn: Ok, we can add 15:05:59 He will join shortly. 15:06:07 burn: Any introductions? 15:06:10 q+ 15:06:18 ack bparth24 15:07:09 ack 15:07:27 q? 15:07:34 q- bparth 15:07:48 bparth24: Hi, this is my first DID WG meeting, with Moby, started career as software engineer and transitioned into technical product management, software development teams from POC to launch, worked in different verticals, healthcare, supply chain, finannce, and now Web3 decentralized identity related and VC related. Nice to meet you all. 15:08:00 bparth24: I joined based on my own interest, not on behalf of Moby here. 15:08:24 burn: Are you joining as an individual? 15:08:27 bparth24: Yes 15:08:35 JoeAndrieu has joined #did 15:08:50 Topic: TPAC Topic Announcement 15:08:53 decentralgabe has joined #did 15:08:57 present+ 15:09:00 JennieM has joined #did 15:09:01 present+ 15:09:04 present+ 15:09:08 burn: You're welcome to participate as an observer today, please contact Pierre-Antoine to talk about Invited Expert status. 15:09:16 https://github.com/w3c/did-wg/issues/57 15:09:48 burn: We've started putting together an Agenda for TPAC, if you have any other topics that you'd like to request, if you have new DID Features to share with the group, add yourself to the Github issue in IRC. It's important that we get that in, we're going to try to finalize the Agenda next week. 15:09:55 Topic: DID Wg site migration 15:10:06 burn: Pierre-Antoine, would you like to discuss this? 15:10:18 https://www.w3.org/2019/did-wg/ 15:10:27 pchampin: Historically, the WG home page has been managed by Ivan at the address above. 15:10:47 https://www.w3.org/groups/wg/did/ 15:11:03 pchampin: It's a generated website, in the meantime, the W3C infrastructure has evolevd quite a bit, and we have the page above that's automatically generated, containing most of the information that we have on the home page. 15:11:36 danpape has joined #did 15:12:17 pchampin: The suggestion is to decomission the old webpage and favor the new one because it's generated automatically and because the old page requires manual intervention from team contact. We switch from specific minutes generation tool by Ivan to the one provided by W3C, minutes generated from IRC bots that anyone can generate/edit. This is the suggestion. 15:12:26 q+ to ask about minutes inclusion in Github issues. 15:13:13 scribe+ 15:13:15 pchampin: We will lose some features, like full names for individuals. I believe there would be more value in using W3C infrastructure because it makes many people and chairs/contact able to update information. We'll do the migration soon, unless someone objects. 15:13:22 ack 15:13:26 scribe+ 15:13:28 ack manu 15:13:28 manu, you wanted to ask about minutes inclusion in Github issues. 15:13:48 q+ 15:14:00 manu: it was nice being able to see which issues were discussed 15:14:24 pchampin: no. There is a new bot that does something similar, but not as nice. 15:14:34 pchampin: It does not have that feature. Note that recently this has not been activated, one part of Ivan's tooling that I'm not familiar with. We haven't had that for a while. 15:14:35 q+ 15:14:56 ack TallTed 15:14:59 pchampin: If I have to spend time on getting it working, more useful to get it integrated than continuing to use other tooling. 15:15:02 https://w3c.github.io/GHURLBot/manual.html 15:15:17 manu: one of the valuable features of Ivan's tool is the inclusion of meeting in the github issues being discussed. Is this part of the W3C tooling? 15:15:21 TallTed: That bot is the Github bot and here's the web page. I don't know if it's official W3C tooling, but it's running on W3C IRC server. 15:15:24 ack manu 15:15:43 scribe- 15:16:48 q? 15:17:03 manu: Ok, +1 to migrating and +1 to integrating ivan's feature into the W3C tooling 15:17:18 burn: Ok, no volunteers to integrate the feature yet, but agree that it's valuable. 15:17:24 Topic: DID Core Issue/PR Processing 15:17:50 scribe+ 15:18:03 scribe- 15:18:06 manu: we've got 3 PRs in DID core. 15:18:11 subtopic: https://github.com/w3c/did-core/pull/813 15:18:51 ... I believe that we addressed TallTed's concerns, and I believe that JoeAndrieu responded with an ok. 15:18:56 +1 to merge 15:19:00 ... Just wanted to double check before I merge. 15:19:15 TallTed: Yes, I believe that's fine. 15:19:22 manu: good, we can then merge. 15:20:01 subtopic: https://github.com/w3c/did-core/pull/852 15:20:12 s/... I believe/manu: I believe 15:20:27 manu: we don't have any reviews on this one yet. We need more reviewers. 15:21:00 ... I'll try to tag folks. 15:21:35 ... We may want to add a default set of code reviewers. Otherwise, people forget to tag people and don't get reviews. 15:21:47 FWIW +1 for Multibase, it is in line with the "sister" work at VC 15:21:49 decentralgabe: I'll take an action to setup the github repo. 15:22:00 subtopic: https://github.com/w3c/did-core/pull/858 15:22:22 manu: we got positive reviews on this. It's been out there for 2 weeks. 15:22:31 ... Merging unless there are any objections. 15:23:34 ... Do we want to do issue processing? 15:23:42 scribe+ 15:23:46 burn: we have a new topic, so rather not. 15:23:55 scribe- 15:24:00 Topic: DID controller update from VCWG 15:24:05 scribe+ 15:24:33 manu: a discussion came over about what the controller field means in the DID/controller document. 15:24:59 q+ to say I think we can get there 15:25:00 ... There are some misalignments which we need to discuss, though not necessarily today. 15:25:09 ack JoeAndrieu 15:25:09 JoeAndrieu, you wanted to say I think we can get there 15:25:37 JoeAndrieu: I agree it's kind of messy. The confusion is linked to David @@1's question about the subject. 15:25:59 JoeAndrieu: I agree, it's a bit of a mess on how we're talking about it and what led to David Chadwicks concern, I think we can get there, patterns that people have used that we don't have consensus on... DID as value of controller field, pattern is not in sync w/ proposals -- reverse the patterns, think about it more clearly to figure out how to use this stuff. 15:26:07 scribe- 15:26:17 s|JoeAndrieu: I agree it's kind of messy. The confusion is linked to David @@1's question about the subject.| 15:26:46 scribe+ 15:27:11 manu: This is just a request to the Chairs to coordinate w/ the VCWG Chairs to figure out where the discussion happens. 15:27:17 Topic: DID Resolution Issue/PR Processing 15:28:06 burn: Markus is still on leave, anyone familiar with issues/PRs to walk us through them. 15:28:36 Wip: I could walk us through some of it. 15:28:44 subtopic: https://github.com/w3c/did-resolution/pull/84 15:29:21 Wip: This is the reverse of the one Manu just talked about, moving content from DID Core into DID Resolution. 15:30:10 Wip: We need more reviews on this, but it's the sister PR to the one we just merged on DID Core. 15:30:28 phila has joined #did 15:30:33 present+ 15:30:37 subtopic: https://github.com/w3c/did-resolution/pull/49 15:31:31 Wip: Markus is requesting changes, there are merge conflicts. 15:31:40 subtopic: https://github.com/w3c/did-resolution/issues/83 15:32:05 Wip: This is about HTTP binding in the spec. Is this something we should have in the spec? How will we want to change it? 15:32:05 q+ 15:32:09 ack manu 15:32:29 scribe+ 15:33:33 q+ to support MTI https binding 15:33:40 scribe- 15:35:40 manu: We should have HTTPS be one of the mandatory to implement interfaces, library interface being the other one, and implementers need only implement ONE of those. It's useful to use HTTPS for the test suite and it won't be throw away code for developers. 15:35:42 ack JoeAndrieu 15:35:42 JoeAndrieu, you wanted to support MTI https binding 15:36:09 scribe+ 15:37:17 JoeAndrieu: I'm a big supporter on mandatory to implement for HTTPS binding, because that's how we integrate with the Web. Elika mentioned a view as being by "anything you can get to by a URL" or by a browser, if we can provide a way that any conformant DID Method provides an HTTP accessible interface in an implementation somewhere, then we can have software components that can get standard DID Document data. 15:37:33 smccown has joined #did 15:37:34 JoeAndrieu: I think think is how we get cross-method interoperability, wanted to try to put a definition of that out there. 15:37:40 present+ 15:37:42 q+ 15:37:46 ack manu 15:38:16 q+ 15:39:09 q+ to say I think the semantics are a form of extensibility, and so there will always be gaps in cross-method interop 15:39:23 manu: with a concrete HTTPs bindings, and with us being able to assert that there are features that are shared across DID documents, we would be able to argue this is cross-method interop. 15:39:36 ack decentralgabe 15:39:48 q+ 15:39:48 ... It might be good to write down what we believe is cross-method interop, so that we can point people to that. 15:40:42 ack JoeAndrieu 15:40:42 JoeAndrieu, you wanted to say I think the semantics are a form of extensibility, and so there will always be gaps in cross-method interop 15:40:48 decentralgabe: Chair hat off, I do think that cross-method interop does mean accessing/using properties across DID Methods consistently, I don't think they all need to be the same, but some understanding on how some properties are used. For example, class of controllers that apply to some DID Methods, different set for others. Property that has certain type and same understanding in other DID Methods. This should be communicated clearly so people 15:40:48 accessing docs can do that interoperability. 15:41:28 JoeAndrieu: I think the semantic meaning of properties is we need two features of 1) shared understanding of common properties, and 2) extensibility architecture. If we have those two, you will have some DID Methods that extend in some direction, but not everyone needs to extend in that direction. 15:41:39 ack Wip 15:41:44 JoeAndrieu: Our job is to figure out what are the properties that should work in every DID Method. 15:42:03 Wip: This is a great discussion, but Chairs are intending to discuss this at TPAC. Keep in mind that we're going to work on this at TPAC. 15:42:09 q? 15:42:19 Wip: Any other comments before we move on? 15:42:21 subtopic: https://github.com/w3c/did-resolution/issues/82 15:42:54 Wip: What are the serialization of the results from DID URLS / dereferencing -- dependency on our decision on the abstract data model? 15:43:08 Wip: I think he's saying "we need concrete output" 15:43:10 q+ 15:43:13 ack manu 15:43:16 Wip: And perhaps it needs to be JSON-LD 15:43:34 manu: I wouldn't say the serialization needs to be JSON-LD. 15:43:37 danpape has joined #did 15:43:51 q+ 15:44:04 ... we need a concrete serialization. If we do HTTPS, we need to define what concrete syntax goes in the request and in the response. 15:44:31 ... Fundamentally, the request and response are JSON. 15:44:48 ... Some responses need to be a valid DID document, some can be JSON, other can be JSON-LD. 15:45:29 ... It feels to me that we are not going to get rid of the abstract data model, and because of that it makes our decision on the concrete syntax harder. 15:45:45 ... At least it should be JSON. The good thing is that JSON-LD can be represented in JSON. 15:45:58 ... But I don't think that resolver will have to do any JSON-LD processing. 15:46:07 q? 15:46:15 ack smccown 15:47:15 smccown: I have a general question that's relevant to this discussion, every group I go in, we have this "JSON vs. JSON-LD" question, I'm comfortable with either. Specific question, if you have a JSON-LD item and it links in another item, when first item is signed, we don't always put those linked items under the signature, which means you're signing an object that are important but can't be signed, because target of the link can change. 15:47:38 smccown: Some notable examples of that recently. I'm not saying I don't want to use JSON-LD because of that; how do you handle that situation? 15:47:39 q+ 15:47:50 smccown: How do you validate the links under the signature? 15:47:56 ack manu 15:48:18 https://w3c.github.io/vc-data-model/#integrity-of-related-resources 15:48:23 manu: we had that discussion about the VC data-model. 15:48:35 ... We have a mechanism called "related resource" (link above). 15:48:36 https://w3c.github.io/vc-data-integrity/#resource-integrity 15:48:52 s/mechanism/solution to that 15:49:33 ... To be clear: it only strongly works in JSON-LD. JSON does not have any link semantics. 15:50:16 ... You can reliably sign all objects that are linked to -- alternatively you can retrieve the data you are signing. 15:50:35 ... The same thing could be applied to DID documents. Hopefully that answers your question. 15:50:46 smccown: That is awesome, thank you so much. Is this required/normative? 15:50:46 q+ 15:50:51 ack manu 15:51:31 manu: there are plenty of times where you don't want to sign the things that are pointed to (e.g. pointer to a logo, that may be refreshed). 15:52:00 ... So it is not a good idea to mandate that everything is signed. 15:52:12 ... Applications should make the decision to sign externally linked resources or not. 15:52:21 smccown: Ok, yes, that answers my question. Is it well known that linked items are signed or not. 15:52:50 s/or not./or not?/ 15:52:55 manu: no. You are largely asking application dependant questions. The VC data-model and DID core specs don't go into that level of details. 15:53:02 zakim, close the queue 15:53:02 ok, burn, the speaker queue is closed 15:53:54 ... Typically you would go together with other implementers of your use-case area, and make an additional specification (this is the allowed cryptography, c14n is done that way...). 15:54:01 ... But we work at a more generic level. 15:54:17 smccown: Ok, thank you. 15:54:32 Wip: Take a look at issues, 80 and 83 where Markus is trying to get some feedback. 15:54:33 Topic: VCWG recharter 15:54:50 https://lists.w3.org/Archives/Member/w3c-ac-members/2024JulSep/0026.html 15:55:12 ivan: The VCWG recharter call went out yesterday, if you are an AC Rep, please vote, if you are not, please tell your AC rep to vote. If you have already voted, good job! :) 15:55:14 Topic: Next Up 15:55:37 burn: Anything else that needs to be brought up today? 15:55:57 burn: Thanks to PA and manu for scribing, we'll chat again next week! 15:56:09 RRSAgent, make minutes 15:56:10 I have made the request to generate https://www.w3.org/2024/08/22-did-minutes.html pchampin 17:54:02 dmitriz has joined #did 18:05:43 Zakim has left #did