14:57:32 RRSAgent has joined #did 14:57:37 logging to https://www.w3.org/2026/04/16-did-irc 14:57:37 rrsagent, make logs public 14:57:41 Meeting: Decentralized Identifier Working Group 14:57:44 Chair: Wip 14:57:49 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Apr/0014.html 14:57:49 clear agenda 14:57:49 agenda+ Agenda Review, Introductions (5 min) 14:57:49 agenda+ DIDWG Charter Extension (5 min) 14:57:49 agenda+ Debrief from the Special Topic call for 14th Apr \[1\] (5 min) 14:57:49 agenda+ Clarify that ""DID resolution"" is consistent with ""URI resolution"" \[2\] (10 min) 14:57:51 agenda+ DID Resolution PR Processing \[3\] (20 min) 14:57:53 previous meeting: https://www.w3.org/2026/04/09-did-minutes.html 14:57:54 agenda+ Next Steps: DID URL Dereferencing algorithm steps, including PathService (10 min) 14:57:57 next meeting: https://www.w3.org/2026/04/23-did-minutes.html 14:58:35 JoeAndrieu has joined #did 14:59:43 markus_sabadello has joined #did 15:01:12 present+ 15:01:17 present+ 15:03:43 present+ 15:04:37 present+ 15:04:38 transcriber-bot, status 15:04:55 present+ JoeAndrieu 15:04:58 Topic: Agenda Review 15:05:03 transcriber-bot, resume 15:05:03 scribe+ 15:05:11 Will Abramson: Um, yeah, so we'll just briefly touch on the working group charter extension. I'll hand over to PA for that... 15:05:12 present+ bigbluehat 15:05:16 ... And then, uh, debrief on the special topic call yesterday. Um 15:05:20 present+ markus_sabadello 15:05:22 ... Then we're going to touch on some open PRs that I'm hoping are going to be less controversial, and we can just get them through, and then 15:05:32 ... Um, if that's successful, we'll go on to some of the more controversial ones. And finally, I want to have a bit of time at the end just to discuss next steps. Like, initially, I was thinking 15:05:33 present+ TallTed 15:05:43 ... Um, you know, we can have… we will have a special topic called next week, but let's figure out what… what is most valuable for us to discuss in that call. Okay 15:05:48 present+ 15:05:50 ... So 15:05:55 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): sorry, just before we keep going here, um, I noticed that there are two agendas in the calendar item... 15:05:58 Will Abramson: Oh, okay... 15:06:01 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): It'll be helpful if that can be trimmed down going forward... 15:06:04 present+ 15:06:04 Will Abramson: Yeah, thanks for watching tonight... 15:06:10 q+ 15:06:11 ... Yeah, actually, on that note, does anyone else have any other agenda items to add for today? 15:06:11 q? 15:06:15 ack manu 15:06:17 ... Uh, ma'am? 15:06:24 Manu Sporny: I guess, um… where do we know where we are on charter extension?... 15:06:26 Topic: DIDWG Charter Extension 15:06:26 Will Abramson: Yeah, that is on the agenda, that is the next item... 15:06:29 Manu Sporny: Okay. Okay, sorry, apologies, I was late... 15:06:38 Will Abramson: Um, great, yeah, so that is the first thing I want to discuss, and I'm just going to hand over to you, Pia, and maybe you can give an update on... 15:06:42 ... The process, and uh… what we expect from that 15:06:53 Pierre-Antoine Champin: Uh, yes, so, uh, it's on me, and I haven't, uh, progressed on that yet, I'm sorry, uh, but, uh, basically, to get an extension... 15:06:59 ... All, all I need to do is make a request to the team 15:07:09 ... This is a team decision and motivating that, so, uh, it's on my list for my… it should be done by the end of the week 15:07:15 ... Um, and then, uh, the decision should come in the coming days 15:07:19 present+ Jennie_Meier 15:07:20 ... well, count a little more, maybe, because of the A/C meeting next week, but, uh 15:07:28 ... Uh, we should, uh, we should have an answer pretty quickly. Uh, the goal after discussing with the chairs is to request, uh 15:07:30 JennieM has joined #did 15:07:34 ... A 6 month extension, which is usually considered the maximum we can ask for and 15:07:38 ... Not consider a re-chartering for the moment 15:07:40 present+ 15:07:42 ... Hopefully we can we can 15:07:56 ... get the deed resolution, uh, through, well, both through, but deed resolution is more at risk. Uh, we can get all our right track through, uh, in those 6 months 15:08:00 Will Abramson: Great. Okay... 15:08:11 ... Yes, I mean, if people think that there's a better route, and that we should be focusing on re-chartering, then do jump on the queue and say so, but… My sense is 15:08:12 present- Jennie_Meier 15:08:16 ... We just want to finish the work, and 6 months should give us enough time to do so 15:08:23 Topic: Debrief from the Special Topic call for 14th Apr 15:08:25 ... Okay, I'm on the queue 15:08:32 ... So, let's move on. Uh, yeah, I just want to spend a little bit of time to debrief from 15:08:36 ... yesterday's call, I think most of us were there 15:08:37 https://docs.google.com/document/d/1xcoslzqA6Wr_CHhvvhZ4wKupEE32HZ69hp2AE1rJMjs/edit?tab=t.0#heading=h.3ctwosu54icw 15:08:43 ... Um, but we can just touch on it quickly. So it was a productive call in that we reviewed this, uh 15:08:54 ... document of the sort of itemized changes that Joe created, and we kind of, uh, traffic light coded them, like green being. You know, this has broad consensus, orange means 15:09:02 ... There's some discussion that needs to happen here, but we think we can move forward. There are some folks objecting, and. We need to figure out how we're gonna 15:09:07 I have made the request to generate https://www.w3.org/2026/04/16-did-minutes.html TallTed 15:09:14 ... either move through those objections, or have some hard conversations there. And then we 15:09:16 ... Ended the call just talking on one of the issues, which is really, like, 4A, and it was all focused on 15:09:21 ... Will we support HTTPS binding for digurl dereferencing? 15:09:24 ... Didn't come to a conclusion of that discussion 15:09:31 ... Um… and we need more time to talk on it. I don't think I'm gonna… we're gonna have time on the agenda today 15:09:39 ... But at the end of the call, we can discuss whether it's worth putting that on the topics that. Special topic call next week to continue, like 15:09:41 denkeni has joined #did 15:09:42 ... Momentum on that, or if there are other topics we'd prefer to 15:09:48 ... So, if I missed anything… Do you jump on the queue? 15:09:51 q? 15:09:58 ... Okay, give me one moment 15:10:04 ... So, yeah, with that, I'm going to continue on 15:10:06 Topic: Clarify that "DID resolution" is consistent with "URI resolution" 15:10:14 ... So, the first topic, and this did come up briefly yesterday, but this is about a PR that Marcus raised 15:10:16 https://github.com/w3c/did-resolution/pull/318 15:10:18 ... specifically to respond to Jeffrey's 15:10:31 ... concern… let me just drop the link in… 318. Uh, this is to address 226, which is about inconsistent use of resolution, which Jeffrey reads as part of his tag review 15:10:38 ... and Jeffrey has reviewed this and approved this PR. I think there's some concern from. Some people that, you know, this is 15:10:43 ... Uh, while Jeffrey is approving this PR, it maybe isn't completely resolving his concern 15:10:48 ... But, you know, this PR has broad acceptance of mind, too 15:10:52 ... suggested it's merged from Dimitri. I think Dimitri is also 15:10:59 present+ 15:11:00 ... in that mind, but I just wanted to open up a little conversation about this PR, and… If anyone has any concerns with this 15:11:04 ... Excuse me 15:11:11 ... And one thing I will say is, yeah, I think one of the concerns is Jeffrey has not 15:11:15 ... yet review did URL dereferencing as a section 15:11:19 KevinDean has joined #did 15:11:20 ... Um, this issue that he raised in 226 15:11:23 present+ 15:11:29 ... Um, but specifically about text in the introduction. Um, so maybe… The confusion that he has is 15:11:35 ... is going to rearrise as we go into… when we ask them to review did URLD referencing 15:11:39 ... But, um 15:11:51 present+ denkeni 15:11:52 q+ to merge, but also comment 15:11:53 ... I'm not seeing anyone on the queue, so maybe we're all like, okay, this is fine, let's merge this text. I mean, it has lots of approvals, so… That's great, and always then… you know, I think we can mark his 15:11:58 ack JoeAndrieu 15:11:58 JoeAndrieu, you wanted to merge, but also comment 15:11:58 ... Tag review. Pending close. Um 15:12:03 ... Joe 15:12:11 Joe Andrieu: Um, yeah, I think this is an easy cleanup, but I think we should merge it. Um, looking at Jeffrey's comments, I am one of the people who think he... 15:12:22 ... he does not… I think his confusion is not cleared up. He suggests things like, hey, maybe that reference to 3986 is just incorrect, and maybe what you should do is lean into that and say 15:12:29 ... We are a willful violation of 3986, um, but we're not, so 15:12:39 Will Abramson: Great, that was… Excuse me. Uh... 15:12:40 Topic: DID Resolution PR Processing 15:12:42 ... Okay, thanks. I'm gonna move on 15:12:53 ... So next, uh, we're just going to do some general PR processing, and I'm going to start with some of the. One's really raised from… by Marcus 15:12:55 subtopic: https://github.com/w3c/did-resolution/pull/301 15:12:57 ... better off more. Actually, no, I'm not going to start with 301 15:13:06 ... So, this has been, uh, about for a while. It was raised by Steven, who actually is not on the call 15:13:14 ... But it is talking about the URL query normalization, specifically to address the security 15:13:19 ... issue that was raised. I think it was initially raised in didcore, but moved across to here 15:13:28 ... Uh, it seems to have approvals. I guess I just wanted to flag this. Because, you know, this has been open for 15:13:34 ... Months now, maybe? At least a month. Um, and it'd be good to get it in, just 15:13:40 ... clear out some of these older issue PRs that can pose issues 15:13:46 q+ 15:13:46 ... Um 15:13:50 ack JoeAndrieu 15:13:54 ... Sure 15:14:01 Joe Andrieu: Um, yeah, I have not looked at this in detail, so, you know, I don't have an opinion against it. Um, my question is, there was... 15:14:06 ... an issue that I raised and didcore that I think we as a group do need to address 15:14:14 ... Which is, until this discussion, we have not formally defined what a query parameter is 15:14:17 Will Abramson: Hmm... 15:14:26 Joe Andrieu: Um, the definition in Didcore points to 3986, and 3986 says it's the thing between the question mark. And either the end of the URL or a hashtag... 15:14:33 This is the issue JoeAndrieu is referring to - https://github.com/w3c/did/issues/925 15:14:38 ... Um, so it's literally not possible to have duplicate, uh, query terms, and it's one of the things we comment in a note in Didcore. So, I think there's some cleaning up to do. I don't know if it will apply to here 15:14:46 ... This actually looked pretty good by my scan, um, but I do want to see if the group feels we also need to update Didcore to clear up that confusion 15:14:50 Will Abramson: Great. Thanks, Joe... 15:14:51 q+ 15:14:54 ack manu 15:14:59 ... Um… anyone else have thoughts on this? Uh… Madame? 15:15:10 Manu Sporny: Um, yeah, I think plus one to merge this with a couple of caveats. Um, I did review it in depth when it first came up. There is an enormous amount of text here... 15:15:24 ... a lot of it's just kind of, you know, explaining, I wish we could use maybe 25% of the amount of text that we have in here, but I don't see anything super dangerous. It just goes through and, like, tells people about, like, hey 15:15:35 ... You know, query string normalization, you know, is a kind of complex thing, and these are a number of things that you need to pay attention to, and it provides some examples of, like, where things go awry 15:15:49 ... Um, I wish we were not the ones that had to talk about this, I wish it existed in another spec, plus one to what Joe's saying, we should probably say something in Didcore. But even then, it's not Didcore's job to talk about this stuff, it's really a 15:15:58 ... you know, 3986 thing, uh, which does not talk a tremendous amount about, you know, uh, normalization and that sort of thing. So 15:16:10 ... Um, I'm fine with adding it, because it does address a comment that we got, um, very thoroughly, uh, but I would like to see us see if we can say less. In the future. That's it 15:16:14 Will Abramson: Hmm... 15:16:22 ... Thanks. I mean, I'm wondering, you know, Steven does also mention the length in his initial. phasing of this PR 15:16:31 q+ 15:16:33 ... Um, maybe we could try and ask for a pass to make it shorter, or, like, someone could take on a task to review it and try and make it shorter. I agree, there is a lot in here 15:16:38 ... The other thing I'm interested to hear from the group is, like, Steven mentioned in this PR around 15:16:43 ... like, issues that this raises with relative RAS 15:16:50 ... And… perhaps it would be better to drop relative ref. I mean, that's not related to this text here, but 15:16:55 ... Is that something that we should have a conversation about at a separate time, or 15:16:56 ack manu 15:17:01 ... We just wait and see if it comes up as an issue later on. Uh, man 15:17:11 ... Hmm 15:17:21 Manu Sporny: Um, I think… so, let's merge this. I don't think we should… we need to get things merged and get into CR. I don't… an editorial change, I don't think is necessary here, right? Like, we're addressing the issue, we're over-addressing the issue, like, let's just merge it... 15:17:26 ... and move on, uh, and keep it focused on just that, that, you know, um, merging the PR or not 15:17:29 Will Abramson: Okay... 15:17:33 Manu Sporny: I think we should. Um, for your relative ref question, that is another issue that we can discuss... 15:17:41 ... Um, just to be clear, I'd be a pretty strong minus one for getting rid of relative ref entirely. I… I 15:17:57 ... don't like it as a feature. I remember we put it in there for a reason, but, like, if we get this path service or any variation of that done, that is the thing we should be telling people to do. I think the most we could do is put out a deprecation warning for relative ref 15:18:03 ... To say that a future version of the spec might remove the feature entirely. Um, uh 15:18:08 ... or just deprecate it forever and tell people, like, please don't use relative breath. It creates 15:18:15 ... concerns and issues and that sort of thing. So, um, but that is a conversation we should have in the future 15:18:19 ... as a separate, you know, issue, if we have the time. That's it 15:18:26 Will Abramson: Great, thanks, I appreciate that. Okay, I'm hearing… let's merge this, and I will let Dimitri know... 15:18:29 subtopic: https://github.com/w3c/did-resolution/pull/321 15:18:31 ... What's that? Uh, so… Moving on 15:18:46 ... This next one should also be relatively straightforward. It's 321. It's just a fix, really, to a bug that was in the spec around misnaming of the… Resolution, when it meant. dereferencing. Um 15:18:49 q+ 15:18:49 smccown has joined #did 15:18:50 ... I think it has strong approvals 15:18:53 ack markus_sabadello 15:18:55 present+ 15:18:59 ... maybe we don't need to talk about it at all, I just wanted to make sure everyone had a chance. Yes. Marcus 15:19:07 q+ 15:19:12 ... Hmm 15:19:18 Markus Sabadello: I think it's more than maybe just a bug. I think it has to do a little bit with the other discussions about what means resolution, what means dereferencing, what do you do with the DID and with the URL. And so on, so if… if everybody... 15:19:27 ... actually agrees with this PR, it could also be helpful to get some alignment on the other. topic, so I would 15:19:33 ... I would maybe ask if Joe and Steven could also review this, um 15:19:38 ... And if they agree, then maybe some of the other discussions would be easier 15:19:41 ack manu 15:19:44 q+ 15:19:46 Will Abramson: Okay, great, yeah, Stephen has approved it, so, uh… That's good. Manny?... 15:19:53 Manu Sporny: Uh, yeah, I've reviewed this PR, I think it's a good change. I think it does clarify... 15:20:00 ... Uh… what, you know, a dereferencing cycle is, and why we care about those, and um 15:20:04 ack JoeAndrieu 15:20:07 ... Anyway, it feels like a good, a good change, um, that… that adds clarity. That's it 15:20:10 Will Abramson: Uh, 2?... 15:20:19 Joe Andrieu: Um, yeah, I think this is a good change in general. Um, there's some languaging I'd like to shift, so I'll take a look at that and give feedback. In particular, just the first line caught me... 15:20:25 ... And that we don't dereference a DID service endpoint, we dereference a DID URL that has a service property, or that 15:20:28 PDL-ASU has joined #did 15:20:30 ... like, we need to figure out how to talk about that better, because if you give me a DID service endpoint, I don't need to 15:20:35 present+ 15:20:36 ... they reference it. Um, I think the challenge is when you're going from the did URL, and then you trigger that loop 15:20:38 Will Abramson: Okay, great... 15:20:40 Joe Andrieu: But I will… I'll… I'll engage on that... 15:20:45 Will Abramson: Perfect. Thank you. Um... 15:20:49 subtopic: https://github.com/w3c/did-resolution/pull/327 15:20:51 ... Okay, I think there's just one more that's maybe, like, an easy win, uh 15:21:02 ... Uh, 327, there's another one from Marcus, and I think this is just a bug, right? It's the fix, like, we have old language 15:21:06 ... In the spec that talks about input metadata, and 15:21:11 ... these are no longer… this is no longer metadata, right? It should be options 15:21:28 ... Uh, I guess, like, I know there are some other outstanding things that maybe change, whether there is the URL dereferencing options, but I still feel like it's. Valuable for us to just fix the… Back text, as is today. But 15:21:32 ... Open to comments, questions 15:21:35 ... That was 15:21:37 +1 for options instead of metadata 15:21:46 +1 15:21:47 ... Okay, I see postpone from Joe. I'm not hearing anyone on the queue, so 15:21:54 ... I don't mind just to move on, uh, and maybe we can… tackle a more 15:22:01 ... challenging conversation now. Uh… If we have time 15:22:08 ... Yeah, so, I mean, we've got half an hour. So, question to the group, we could 15:22:15 ... continue the discussion on whether we want… what we're going to do about HTTPS binding 15:22:21 ... Uh, for did your LD referencing from yesterday, or we could discuss, um 15:22:26 ... this shift from resolving DIDs to DID URL 15:22:31 ... I think both of these are, uh, you know, topics with strong opinions 15:22:36 ... it'd be good to see which one. I mean, my, sort of 15:22:40 ... Instinct is maybe to talk about the bid versus did URLs 15:22:43 ... And then we can circle back to the HTTPS finding next week, but 15:22:48 ... if people want to dive into HPS mining, also happy to do that 15:22:59 ... Okay, I see Manny suggesting we close that HTTPS planning to do that 15:23:03 ... So, okay, let me just 15:23:13 ... Okay, great, yeah, so, um, let's talk about HTTPS binding, put that as a topic 15:23:16 Topic: HTTPS Binding for DID URL Dereferencing 15:23:19 https://github.com/w3c/did-resolution/issues/306 15:23:22 ... Uh, and 15:23:35 ... really is captured in this issue that Joe raised. The change also has been made in a PR that Joe has raised, but I think this issue probably captures. The best place for the discussion 15:23:43 ... Um, we discussed yesterday, and maybe, Marcus, it would be good for you to start this discussion 15:23:50 ... sort of talking about, uh, why you're opposed to your LD referencing. I think you came with some good examples 15:23:54 ... Yesterday, also some good points yesterday that we didn't get a chance to fully unpack, so 15:23:57 ... Better place to start 15:24:04 Markus Sabadello: Um, but I... 15:24:09 ... Oh, I, I 15:24:11 https://github.com/w3c/did-resolution/issues/306#issuecomment-4101276200 15:24:17 ... Wrote one comment in one of the issues, uh, with… that I'll put in the chat now 15:24:22 ... Which shows two… two real life, uh, examples of 15:24:26 ... what the HTTPS binding for TDRLD referencing? 15:24:33 ... is used for… one of them has to do with linked resources, and the other one has to do with 15:24:37 ... redirecting to a service endpoint, I think 15:24:49 ... So those are definitely things that have been implemented, that have been deployed, that are used in real-life use cases. And I think 15:24:57 ... If we remove that binding, then those would become unspecified, and therefore not interoperable 15:25:02 bumblefudge has joined #did 15:25:04 ... Between implementations. So these are two real examples that maybe some people were not aware of 15:25:13 ... Right, so I think in the discussion about the dereferencing and the binding. Maybe we don't all have a 15:25:17 ... Full picture of what that even means, right? 15:25:27 ... It has nothing to do with the fragment, and nobody's questioning that the fragment should be dereferenced on the client side. Everybody agrees to that, but 15:25:31 ... There are just some aspects, or 15:25:34 ... that maybe not everybody is aware of, so I try to 15:25:39 q+ to note that just because something is deployed, doesn't mean we need to support it (especially if we think it's a bad idea) 15:25:42 ... To share information about two concrete examples of. What this is used for 15:25:45 Will Abramson: Thanks... 15:25:47 ack manu 15:25:47 manu, you wanted to note that just because something is deployed, doesn't mean we need to support it (especially if we think it's a bad idea) 15:25:51 ... Yeah, thanks for that, Marcus. I see anyone on the queue? 15:26:08 present+ bumblefudge 15:26:09 Manu Sporny: Yeah, just a quick summary for, I guess, those that weren't there yesterday. I push back really hard on this feature. I think it is an anti-pattern. I think it can lead to security vulnerabilities and denial-of-service attack vectors... 15:26:18 ... Um, I do not think we should support it. Um, that doesn't mean that implementers can't implement it, um, that's fine 15:26:24 ... Um, but, uh, you know, just because people have implemented a feature and deployed it 15:26:30 ... Uh, does not mean that we should… we need to endorse it in a specification 15:26:37 ... For example, um, MDLs have been deployed in ways that are really bad for privacy 15:26:43 ... Um, that does not mean that W3C specifications need to say that 15:26:59 ... you know, those mechanisms are valid, or us defining it so that pattern becomes more entrenched, right? Certainly, this is not the same as the phone home issues that MTLs have had in production 15:27:07 ... Um, but I'm trying to draw a parallel to, you know, if you implement this feature on your GID resolver 15:27:18 ... Um, you have a lot more, uh, that you need to be aware of and guard against when it comes to exposing your APIs 15:27:29 ... to any external system, meaning that there are all kinds of attacks that could be, you know, taken on your system if you have such an endpoint 15:27:48 ... So, adding this would mean that, you know, at a minimum, we would have to go very detailed in the security consideration section about everything that you need to do around resource consumption and usage and redirection loops and. All that kind of stuff, versus not defining it 15:27:58 ... Because one, I don't think it's a good feature, and two, um, you know, we avoid, you know, suggesting that it's a good feature 15:28:03 ... Um, it feels like that is a better path, uh, to go, so 15:28:09 ... Uh, again, very strong minus 1 on this feature. It is 15:28:21 ... there are multiple security things that you need to be concerned about. I certainly don't want our company exposed to anyone claiming that it's in the spec, and therefore it's okay 15:28:27 ... Because we strongly feel that it's not. Um, and so, you know, yes, other people have implemented it 15:28:44 ... that's fine. Doesn't mean that we need to suggest that everybody, you know, should be implementing it, or that we need to do it for interoperability purposes. You don't want interoperability on bad features. Right? Um… That's it 15:28:53 q+ 15:28:53 Will Abramson: Great, thanks, Manu. And I think towards the end of last call, Manu, you mentioned, like, maybe there's a way to achieve some of the same... 15:29:02 ... functionality or use cases that Marcus is mentioning without exposing this feature, and we should. We should explore that, and 15:29:02 ack manu 15:29:05 ... Make that possible. Yes, I'll see you on the queue, go for one 15:29:24 Manu Sporny: I think that's a different issue, right? So I think, you know, Marcus, from what you said yesterday, I got the impression that you thought some of us were making an argument against the dereferencing algorithm, or taking out completely, or something of that nature... 15:29:32 ... I don't… I don't think anyone in the group has that position. I think the general position is we do think the dereferencing algorithm is 15:29:42 ... a worthwhile thing to keep in the specification. Um, I think there's a question around the API definition of it 15:29:54 ... Uh, and there's certainly questions around whether or not we believe the algorithm is, you know, the details of it, but I don't think anyone's saying we should take dereferencing out… the dereferencing out 15:29:57 q+ 15:29:58 ... Uh, sorry, the dereferencing algorithm out completely. Um 15:30:06 ... So, I would expect that if we remove the HTTPS binding, we would still keep 15:30:15 ... The dereferencing algorithm, uh, detailed enough so that it could be implemented. Certainly on the client side 15:30:24 ... Potentially on the server side, but we would not, you know, provide an interface. For the server side 15:30:28 ... Um, which is the HTTPS binding for that. Hopefully that made sense 15:30:28 ack markus_sabadello 15:30:31 Will Abramson: Great, thanks. I'm Marcus?... 15:30:43 Markus Sabadello: Just to respond to that, I don't think I misunderstood that, so I understand nobody wants to remove the dereferencing algorithm, or at least I... 15:30:48 ... I hope so, so that's, uh, that's clear to me. I understand this is about 15:30:50 q+ 15:30:52 ... About the binding and not about the algorithm itself 15:30:57 ack JoeAndrieu 15:31:03 Will Abramson: Yeah, looking for anybody else who has opinions about moving the, uh, fine, Jean? show... 15:31:08 Joe Andrieu: Um, yeah, I think… so I agree with Manu about all the security, uh, aspects... 15:31:16 ... But I also wanted to add that if we have an HTTP binding for dereferencers, then now we're gonna have URLs 15:31:24 ... that need to be dereferenced to talk to the dereferencer. And I think that's the heart of the confusion with Jeffrey. Like, there's 15:31:34 ... like, how do we dereference a dereferencer becomes a more complicated pattern when we explicitly have an HTTP endpoint, which is going to be representable by a URL 15:31:38 ... And so, I think that just gets really confusing 15:31:43 Will Abramson: Thanks, Joe... 15:31:47 ... Anybody else in the group want to share their opinion about 15:31:55 ... whether or not they support, or they support removing dereferencing, or HPS binding for dereferencing, or 15:31:58 ... They want to keep it. They feel strongly that we should keep it 15:32:00 q+ 15:32:07 ack markus_sabadello 15:32:08 ... Yeah, Apple, it's not a bad idea. I mean, I feel like 15:32:12 ... kind of in the document, but I'm happy to take one. Marcus? 15:32:22 Markus Sabadello: I mean, I would like, you know, before we have a vote or a poll request or any of that, I would really like people to... 15:32:26 ... consider the… the examples that I… that I gave 15:32:32 ... And maybe also getting input from Checked or others who are 15:32:37 ... Who have implemented the linked resources. I think there's 15:32:41 ... One misunderstanding in the group may be that 15:32:51 ... all of the dereferencing can always be done on the client side, and that it is all just about the document, right? So when we 15:32:53 q+ to speak to "all dereferencing can be done on client side, all about DID Document" 15:32:59 ... When we talk about things like the service parameter, when we talk about the path service proposal 15:33:04 ... When we talk about the fragment, then all of those things are 15:33:16 ... did method independence, they can be done after you have the DID document, they can be done in a method-independent way, they can all be done on the client side, you don't need an 15:33:20 ... HTTP binding for dereferencing for these things, but there are 15:33:25 ... did URLs, like the ones with linked resources, um 15:33:31 ... Where you're basically doing something similar to 15:33:38 ... to, uh… when you… when you obtain the deed document during resolution, right? You do it in a method 15:33:44 ... specific way. The way how you resolve the DID document for a DID 15:33:53 ... depends always on the… on the method, and sometimes the way how you dereference a DID URL also depends on… on the method. You cannot. Do that in a 15:33:58 ... Client that doesn't understand the method itself, um 15:34:05 ... And this would become unspecified or impossible if we remove the binding, so 15:34:11 q+ 15:34:15 ... I would like this to be considered. I understand some people don't want to use these features, or. Don't want to… want to implement them, then 15:34:21 ... This is also an optional feature, right? Nobody has to implement it 15:34:26 ... But if we remove it, it would break things that are working today 15:34:26 ack manu 15:34:26 manu, you wanted to speak to "all dereferencing can be done on client side, all about DID Document" 15:34:30 Will Abramson: Thanks, Marcus. Manu?... 15:34:49 Manu Sporny: Yeah, I wanted to kind of speak to, Marcus, what you said, that, you know, um… that we might be misunderstanding, um, that, you know, certain things need did method-specific features in order to dereference them. I'm pretty... 15:35:02 ... I mean, please put yourself on the queue if you don't understand that, but I think all of us understand that. The idea that, you know, there are some ways of dereferencing that are did method agnostic 15:35:07 q- 15:35:13 ... And there are some ways of dereferencing that very much depend on the did method, meaning, like, there's data stored on a blockchain somewhere, and that is tied, you know, very closely to the DID method, spec, and 15:35:28 ... you need to keep that in mind when you do the dereferencing, and it would be convenient to have something on a server that does all of that for you, right? Um, I think that is… Understood. Um, however 15:35:35 ... one of… there… there… I think we… we have been saying there are 15:35:49 ... ways to store these things in blockchains, and what we have seen is the did methods choose multiple different ways to do this, which has led to less interoperability, not more interoperability 15:35:56 ... Now, there are good reasons to do it sometimes. I'm not saying you shouldn't have a blockchain-based storage mechanism and 15:36:02 ... or a decentralized network-based storage mechanism. Um, uh, however 15:36:16 q+ to ask about did linked resources being method-specific 15:36:21 ... you know, to say, Marcus, you said it's going to be impossible, you know, to do it. It's not going to be impossible. It is going to be unspecified, uh, right, uh, to do it, or underspecified. That is very different from impossible. You can still write a dereferencing client 15:36:34 ... that understands, you know, special things about the AD method, and does the appropriate dereferencing algorithm that's did method specific to get the data. You could also have a dereferencing client 15:36:43 ... that knows how to dereference something in a did-agnostic way, um, that is generalized among multiple did methods. Um, all of those things are possible 15:36:51 ... Uh, we're not saying people can't do any of those things, we're just taking the HPS binding away, which you don't need for those other things. There's a separable 15:36:55 ... Those are separable concerns, right? Um 15:36:56 q+ 15:37:01 ... So, so, you know, again, I don't think anyone is confused about 15:37:06 ... You know, those examples you showed show us 15:37:22 ... you know, things that need special did method-specific logic to dereference the thing, like it exists in the blockchain or in, you know, some kind of verifiable data registry 15:37:25 ... Uh, yes. However, you don't need 15:37:30 ... an HPS binding to do those things, right? You can do them all client-side. That's it 15:37:31 ack JoeAndrieu 15:37:31 JoeAndrieu, you wanted to ask about did linked resources being method-specific 15:37:35 Will Abramson: Great, thank you, man. Um, Joe?... 15:37:40 Joe Andrieu: Yeah, um, two things. One, the meta-comment is, I think... 15:37:47 ... Um, it is often said in this community that something is did method specific about things that are not did method specific 15:37:59 ... Um, and I think did linked resources isn't did method specific, so I'd love to be corrected, Marcus. I have not been driving or deeply involved in that work, but I have been tracking it from the beginning, because 15:38:09 ... I wanted to understand how it interacted with the linked resources spec, um, because those properties are all in the metadata document that comes back from resolution 15:38:16 ... So, um, I could put a deadlinked resource property. In any, um 15:38:20 q+ 15:38:21 ... System that could respawn and put it into the resolution properties 15:38:30 ... Um, so I'm not… I'm not following where we're losing functionality by. getting rid of the HTTPS here 15:38:31 ack markus_sabadello 15:38:36 Will Abramson: Great, thanks, Joe. Um, Marcus, if you want to respond to that first, good... 15:38:45 Markus Sabadello: Yeah, it is that method-specific, because, um, yes, it does use some metadata. properties that are... 15:38:50 ... common and standardized across different deed methods 15:38:56 q+ the resolver addresses that. not the dereferncer 15:39:01 ... But the way how you… how you obtain the content, how you actually dereference the thing, and the way how you get the representation of the 15:39:05 This was the comments from Alext Tweeddale las time: https://github.com/w3c/did-resolution/pull/260#issuecomment-4143415339 15:39:11 ... resource that is referenced by the DTRL that is method-specific in the same way as obtaining the DID document for the DID. Is… is method specific, and 15:39:14 q+ to say the resolver addresses that. not the dereferncer 15:39:15 ... And I would also 15:39:21 ... I suggest to avoid maybe the concept of on-chain and off-chain 15:39:24 ... Um… because there could be a 15:39:35 ... a wide variety of approaches, how DTRLs can be dereferenced in a method-specific way, just like we've seen a lot of variety when it comes to 15:39:39 ... how the document is… is a pain for the 15:39:43 ... for the deed, right? We've been trying to avoid 15:39:49 ... Categories like web-based and blockchain-based, because people keep coming up with new ways how 15:39:56 ... how you can resolve a D28 document, and in the same way, I've been viewing URLs and 15:39:59 ... Dereferencing also in the… in a similar 15:40:06 ... Way, insofar as the methods can… Specify all kinds of ways how 15:40:09 ... how you could get from a DDRL to 15:40:18 ... Uh, to a representation of a resource that the URL dereferences, and did linked resources is, like, the first 15:40:27 ... implementation, or the first design, which makes, uh, which makes use of DPRLs, and… Dereferencing, um 15:40:32 ... and to implement that is… is method specific, right? So if you have a 15:40:39 ... client, and you want to do all of that on the client side, then… then the client would have to know 15:40:43 ... for every single method, how to do that, um 15:40:48