14:50:17 RRSAgent has joined #did 14:50:22 logging to https://www.w3.org/2026/06/11-did-irc 14:50:49 rrsagent, make logs public 14:50:55 Meeting: Decentralized Identifier Working Group 14:51:00 Chair: ottomorac 14:51:11 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0002.html 14:51:12 clear agenda 14:51:12 agenda+ Agenda Review, Introductions (5 min) 14:51:12 agenda+ DID Resolution Algorithm Inputs Discussion (15 min) 14:51:12 agenda+ Vote on DID Resolution Algorithm Inputs (10 min) 14:51:12 agenda+ DID Resolution TAG Review \[1\] (5 min) 14:51:15 agenda+ DID Resolution PR review \[2\] (15 min) 14:51:17 agenda+ Next Time: Threat Modelling Discussion (5 min) 14:51:29 previous meeting: https://www.w3.org/2026/06/10-did-minutes.html 14:51:41 next meeting: https://www.w3.org/2026/06/17-did-minutes.html 14:56:06 TallTed has joined #did 14:59:17 Wip has joined #did 14:59:23 present+ 15:00:59 JoeAndrieu has joined #did 15:00:59 present+ 15:02:15 swcurran has joined #did 15:02:34 markus_sabadello has joined #did 15:02:37 present+ 15:02:38 https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0000.html 15:02:40 present+ 15:02:47 present+ 15:03:25 KevinDean has joined #did 15:03:31 danpape has joined #did 15:04:41 "Proposal for discussion" doesn't look like "upcoming vote" to me. I do see the word "vote" in the message. 15:05:07 present+ 15:06:26 transcriber-bot, resume 15:06:26 scribe+ 15:06:32 Otto Mora: Absolutely. Okay... 15:06:37 ... Yeah. uh 15:06:41 ... Alright, uh, thanks for that, Gracie, I appreciate it, and uh 15:06:43 Topic: Agenda 15:06:50 ... Check that. We've got, uh… Alright, yeah, I started the transcription. So, yeah, for today, um 15:06:53 ... Conversation around the inputs to the debt resolution 15:07:01 ... Uh, we also have… Algorithm. The vote on the resolution 15:07:06 ... And we've got a conversation around a dip resolution tech review 15:07:08 present+ 15:07:14 ... Uh, then we've got a PR from Steven 15:07:19 ... Is there, um, anything else that anybody… Uh, that we've been discussing yesterday, that we also want to talk about. We want to add? 15:07:20 present+ 15:07:25 ... Yep 15:07:29 ... Okay, perfect 15:07:30 Topic: DID Resolution Algorithm Inputs Discussion 15:07:36 ... Alright, so… Let me just move to the next topic. So, for this topic 15:07:49 ... Yeah, the resolution algorithm inputs. I want to, uh, before we vote on the proposed resolution. uh… first emoted here. And 15:07:54 ... So folks have it as a reference. I'll also paste that into… from chat 15:08:04 smccown has joined #did 15:08:09 ... But before we go into deep discussion of that, I wanted to yield the floor to Marcus, who had requested, uh, given 15 minutes to discuss. Uh, his take on it. So, Marcus, you wanna go ahead? 15:08:12 Markus Sabadello: Yes, thank you. Can you hear me?... 15:08:13 Otto Mora: Yep... 15:08:16 Markus Sabadello: Okay, then... 15:08:21 ... Share my screen now, can you see? 15:08:23 present+ 15:08:25 Otto Mora: Uh, just... 15:08:41 Markus Sabadello: as an input... 15:09:01 ... I want to start by saying we've had this layering, this kind of separation, forever, basically. We've always had it like this, that we said we have a resolution function that takes a DID as an input, and separate from that, we have a dereferencing function, or 15:09:05 ... Okay, so yeah, thanks for the opportunity to present a little bit my thoughts on this. My understanding is that this here is the proposal that we would change the resolution function to take a deed URL instead of a deed as an 15:09:20 ... algorithm or whatever that takes a DIT URL as an input. Even in the first versions of the DIT specification we already had something like DIT URLs, we called them DIT references back then and the DIT documents were called DDOs. But we've always said that the input to resolution is the deed and plus options and nothing else 15:09:46 ... I don't remember this proposal or this topic ever having come up in the past. I think this is the first time this idea comes up that the input to resolution would be a DTRL rather than a DIT. I also asked this explicitly when this working group started in 2024, we went over the specification 15:09:53 ... And this has never come up before, or at least I don't remember. So I think it's a very problematic change 15:10:10 ... We've been telling all the DEED method authors that the method specifications must specify how a DEED resolves to a DEED document. So I think this change would potentially impact a lot of existing DEED methods 15:10:17 ... we've had… we have this separation, basically, at the core of everything we do, right? I mean, look at what our 15:10:49 ... specification is called. It's called deed resolution. The subtitle is about resolving deeds. The abstract says that we take a deed as an input. The charter says that we resolve deeds and dereference deed URLs. So this. Um, as far as I know, other standards, uh, build on top of this in… This layering, in my mind, has always been very 15:10:49 fundamental to the entire architecture. We resolve DIDs and we dereference DID URLs 15:10:59 ... the European Standards Body in ISO. Otto knows this better than me, but I think there are other standards that build on 15:11:16 ... on this basic idea that we take a deed as an input plus options and we get a deed document out of it. I would argue that a lot of infrastructure, a lot of projects that are being built on top of deeds don't even know about deed URLs or don't 15:11:22 ... I don't care much about path and query. So the idea of 15:11:38 ... of not just resolving a deed to a deed document and having an entire deed URL potentially as input to deed resolution, I think would also affect a lot of other standardization efforts 15:11:57 ... Um, is this a breaking change? So, we've talked about this in previous calls, some people have said that this is not a breaking change. Now, I know that, theoretically, we can make breaking changes, so I understand that the deed resolution specification is not final, and I know about the class 1 and 2 and 3 15:12:14 ... A TT is a TTRL, so it's true that, for example, in this first 15:12:17 ... changes, so I'm not saying that we're not allowed to make breaking changes, but I want to try to argue that this would be a breaking change. So, it's true that 15:12:32 ... diagram, if you have a DIT 1.0 conformant client that calls a DIT 1.1 resolver, assuming that we make this change, things would still work in the sense that you can still send a DIT and get back a 15:12:45 ... a DID document, so that would still work, but some other things would, uh, would break, right? So a DID 1.0 client, if they send a DID URL, they would expect an invalid DID error, but instead, with this proposed change, they would be getting a DID document 15:12:55 ... And in some cases, instead of getting an invalid DID error, they would get an invalid DID URL error, right? So there's some 15:13:03 ... I think changes that breaking changes like that 15:13:15 ... if we turn this around, and we… in the future, we have DID 1.1 clients, after we make this change, after we say the input to DID resolution is a DID URL 15:13:23 ... And we have a DID 1.1 client talking to a DID 1.0 resolver. If we still… if we just send a DID, then yes, nothing breaks, we'll continue to work 15:13:32 ... But a DIT 1.1 client may in the future send a DIT URL with a path and a query 15:13:45 ... to a DID 1.0 resolver, which may not have been upgraded yet, and then this will break, right? Because the resolver will return an invalid DID error, whereas the client would actually. expect at the document 15:13:58 ... So, and I've tried this with several existing implementations, and they all return errors. The existing implementations, they don't know how to handle DTRLs in a resolver 15:14:08 ... uh, the W3C test suite also, right? So some of the existing tests in the, in the W3C test suite, um 15:14:14 ... would break in the sense that previously conformant results would not be conformant anymore 15:14:17 dmitriz has joined #did 15:14:27 ... There are many other parts of the specification that build on the assumption that the resolver takes a bit as an input 15:14:33 ... For example, we say the… Value of the ID property must be equal to the deed that was resolved 15:14:52 ... the ID property in the DID document must match the DID that's being resolved. If we say that what we're resolving is a DID URL, not just a DID, then some of these things would have… Some would require updates or some unknown implications potentially 15:15:01 ... We'd have to think about what this means for things like also known as and canonical ID and equivalent ID 15:15:09 ... like, the DTRL that we are sending as an input, would that be an identifier for the DT document? How would that relate to the subject? Things like that 15:15:24 ... example, I don't want to spend too much time, but if we look at the DTRL. I think the change would lead to some ambiguity, um, it's a bit more of a complicated 15:15:26 klea has joined #did 15:15:34 ... that, uh, that uses the DEET linked resources stuff, then 15:15:45 ... the inputs for… Resource, but if we make that change… at the moment, the way things are now, it's clear that the DID alone would be resolved to a DID document, and the DID URL would be the reference to an image 15:15:57 ... resolution and dereferencing would be… would be the same, and in… in my mind, I think there would be some cases where you… if you pass the same string, the same DDRL 15:16:01 ... to the resolve function, you would get a D document, but if you pass the same DTURL 15:16:15 ... to the dereferencing algorithm, you get an image resource. I think this could have some problematic implications, for example, for the HTTPS binding. If you pass… if you 15:16:33 ... resolve or dereference this DTRL, what would you get, right? Depending on whether it's resolution or dereferencing, you wouldn't necessarily be able to tell which one it is, because the inputs. The function signature would be… Would be the same 15:16:47 ... I think it would have potential privacy implications if we're sending unnecessary information to a resolver, right? So we would be 15:16:51 ... sending the entire DT URL including a path 15:16:54 ... to a resolver, and at the same time, I think we would say that the path 15:17:05 ... would be irrelevant for the resolution process. The path would be used for the dereferencing algorithm, but would be irrelevant for the resolution process, so we would be sending information 15:17:15 ... to the resolver that we would say the resolver must not use 15:17:21 ... And I think this is problematic for a number of reasons. Um, I think some people would, uh… would actually mistakenly, or… Or for whatever reason 15:17:30 ... might start to use the path and return different D documents, depending on what's in the DTRL 15:17:40 ... Which I think we would not want. I think some people might, by mistake, even send the fragment, if we say that the resolver receives the entire TTRL 15:17:44 ... And I think it would lead to tracking. I think this — 15:18:07 ... In the identity community, there's been some effort to try and prevent phone home, right? Don't phone home. Um… architectures this is this is the opposite this is a please phone home please send more information to a resolver that can track you that it doesn't actually need 15:18:16 ... heard a lot of explanations for why this change should be made. To be honest, most of the 15:18:25 ... explanations didn't… didn't make much sense to me, most of the explanations I've heard. In my mind, we're not really a reason for 15:18:42 ... confused deputy attack argument that if we 15:18:47 ... dereference at the URL, and we have the parameters, and also… making that change. I'm spending too much time on it. The one thing that I understood was the 15:18:54 ... options that that could lead to a resolver being called with 15:18:59 ... options that were originally parameters. And so there's this whole discussion that a resolver 15:19:03 ... Must be able to distinguish what was originally a parameter 15:19:08 ... And what is passed as options, which at the moment, in the current design 15:19:15 ... it's true that this is not preserved, right, in the… I have examples here in the current design 15:19:36 ... If you have start with the deed URL, then the parameters get turned into options. And if you start with the deed plus options, then those options are also options. So it ends up looking the same. The resolver and the current design cannot be changed 15:19:47 ... to make this change. I think there are a number of other things that… That can be done 15:19:54 ... Maybe we should just, uh, warn about this in the security considerations. tell whether something was originally an option or a parameter, so I understand that part, but I don't think it's a good enough reason to 15:20:07 ... Maybe we should change the algorithm to say that did parameters should just not be passed to the resolver, or only known did parameters should be passed to the resolver 15:20:37 ... passed to the resolver as additional options. We could have some certain syntax to differentiate what was… what comes from an potentially untrusted DTRL and what is passed. Uh, by a client as options. So I think the number of. Or, uh, in the resolution options, we could even indicate which options are really options from the client, and which 15:20:37 options were originally parameters from a deep URL that could be 15:20:51 ... of solutions to these security problems, and I think, for the reasons I mentioned, changing the input to the DID resolution function to DDRL 15:20:59 ... would really be a big mistake. I would not implement it, and to be honest 15:21:06 ... I think even if we make the change, most implementers, I think, will ignore it. I think it will be a little bit like 15:21:13 ... The abstract data model that we had in the past that made some sense, but nobody really. really implemented it 15:21:18 q+ 15:21:19 ... So that's it. Thank you for the time 15:21:30 Otto Mora: Okay. Uh, and, and is this, uh, uh, presentation, uh, Marcus, uh... 15:21:37 ... Is it uploaded somewhere, or are you gonna… or maybe send it to the mailing list or anything? You just wanna… See if there's 15:21:42 Markus Sabadello: Uh, not, uh, not yet, but I can, I can upload it, of course, yeah, I can upload... 15:21:50 ack dmitriz 15:21:56 Dmitri Zagidulin: Thanks, Marcus... 15:22:04 ... Um, Mike, I just have one question about the, sort of, trust model, uh, in your presentation, about the phone home part 15:22:05 Otto Mora: Or just to have it somewhere that we can reference it after. I think that would be useful for the record. Uh, okay, so let's see. I see Dimitri first in the queue... 15:22:08 Dmitri Zagidulin: Yes... 15:22:13 ... So, so my impression was that the resolver 15:22:17 ... Is part of the client's trusted infrastructure 15:22:21 ... Right, so it's not part of the… like 15:22:29 ... You can't phone home to the resolver in the same way you can't for… the client can phone home to itself 15:22:39 ... Different mental model with it. It's within its trust boundaries, its trust zone. I was curious if you have a different security model in mind 15:22:54 Markus Sabadello: Well, sometimes it is, and sometimes it isn't. Of course, it's preferred to have a resolver to be a local thing, but... 15:23:04 ... Sometimes it is, it is not. Um, sometimes people use remote, uh, services as, as resolvers and, and I mean, we. We, we said that 15:23:09 ... Resolution is also what individual bid methods 15:23:31 ... implement. So, remember, at some point, we merged the resolve function with the read operation. We used to distinguish between a resolve function and the read operation in the bit method, but now… now that's the same thing. So, if we. say that the input to DID resolution is a DID URL, then in my mind, it means that that will also get passed 15:23:31 to 15:23:39 ... whatever infrastructure the method uses, so 15:23:42 q+ 15:23:44 ... And yeah, sometimes resolvers are remote services, sometimes they're not local 15:23:54 I think he's saying that a resolver can be used as a surveillance point and the same thing is true of the DNS 15:23:59 Otto Mora: Okay, thank you, and I see Joe... 15:24:00 ack JoeAndrieu 15:24:04 Joe Andrieu: Yeah. Thanks, Adam. A couple of things... 15:24:11 ... I don't think we've collapsed the read and resolve 15:24:18 ... If you look at the recent PRs that I've put together, we make it clear that resolve is a call to the resolver, and the resolver then calls the VDR 15:24:23 ... And it calls the read function of the VDR. However, that read function needs to happen 15:24:42 ... So I think we have been sloppy with this language, but I also think we've been sloppy with DIDs and DID URLs. We often, when we're talking to each other, say, hey, this is something we do with a DID. But the reality is what is very clearly understood is there's a whole DID URL that has parameters and stuff 15:24:51 ... So I don't think the long term historical vernacular that we're using should be considered a strong guide as to how we should architect the system 15:25:00 ... Uh… Um, but I think, you know, I've talked a lot about the technical complexity here. I appreciate that, um 15:25:03 ... The 15:25:24 ... So, necessarily, whether 15:25:28 ... Privacy angle was interesting here, Marcus, but I agree with Dimitri that we've always said that you have to trust the resolver. Fundamentally, if you think you're relying on Bitcoin, but you're actually calling a resolver that you don't control, then you are relying on that resolver. Either you bring it into your trust boundary and you're 15:25:29 running it or you are by inclusion making that, service provider, a trusted party in the system 15:25:49 ... So the path thing was interesting, but I don't think it's as big as a privacy risk as the confused deputy problem that we have when we're conflating parameters. But what I wanna close with, 'cause I think a lot of us have gone around and around about these technical differences 15:26:09 ... Is it… it's very clear in the spec that this is a draft document, maybe updated, replaced, or obsoleted, and it's literally inappropriate to cite this document other than as a work in progress. So I fear that may be what you're doing here, Marcus, is you are treating this as something other than a work in progress 15:26:15 q? 15:26:22 ... But it is a work in progress. And as we went through the threat modeling exercise and we identified the different components and the workflows between the components, that's when these issues became clear and were brought to the group. So I feel like this is the natural place in the conversation 15:26:38 ... Where, having published ADCOR previously in a different charter, we're now figuring out what resolution means. So I think this is absolutely the right place to challenge our assumptions, to make sure that our architecture is correctly described and discussed. And to address any holes that we find in that process 15:26:50 Markus Sabadello: Okay... 15:26:51 q+ 15:26:53 Otto Mora: And just one thing, you're saying... 15:26:56 ... Even if we make the change to the input 15:26:59 Joe Andrieu: So, I think this is an improvement that will reduce complexity, and will increase interoperability, and I think we should switch to DID URLs instead of DIDs... 15:27:02 Otto Mora: You could still strip out the, uh... 15:27:08 present+ 15:27:12 ... the parameters out in the… in, like, one of the first early steps in the algorithm, is that right, Joe? Or 15:27:17 queue+ 15:27:30 Joe Andrieu: I didn't… I'm not sure what I said that may have triggered that. But certainly, if I know that a resolver is not conformant to the current spec, because maybe they're, you know, aligned with Marcus and are refusing to adopt the spec as published... 15:27:30 q- later 15:27:36 q+ 15:27:36 Otto Mora: Got it... 15:27:39 Joe Andrieu: Then if I want to use that resolver, sure, I'll mangle whatever I have to do on the front end to use that pattern. You could map from one to the other. It's just not going to be interoperable... 15:27:46 ack smccown 15:27:46 Otto Mora: Okay, thanks, Joe. Okay, see, uh, Steve… Steve McCann?... 15:27:50 q- later 15:27:57 Steve McCown: Yeah, just a real quick comment. Marcus, I really appreciate your presentation. Thank you for explaining all of your thoughts that way. Um… I'm... 15:28:07 ... Generally in in favor of the did URLs, but I did pay particular note to your 15:28:12 ... Presentation of the confused deputy attack. I think 15:28:37 ... Yeah, of that, that potential problem. We ought to separately address that issue and talk about how it can occur and different things that we can do to help mitigate that to make developers and users aware 15:28:46 ... and address it going forward. So I just wanted to point that out, even though I'm still in favor of the did URLs. I think we need to study that problem a little bit and 15:28:49 q+ to note "in favor of didURL" and there are other things that need to be discussed downstream from this. 15:28:52 ack markus_sabadello 15:28:53 Otto Mora: Uh, I see… Marcus?... 15:29:04 Markus Sabadello: Yes, I agree with Steve that... 15:29:11 ... we should explore this more, and I've… I've outlined a few potential ways to handle that, which I think we haven't discussed at all in the group, and 15:29:20 ... We're addressing that, and it should not be 15:29:24 ... By itself, a reason, and uh… Changing the input to the DTRL, in my mind, is complete overkill 15:29:28 ... talk about Joe's point regarding the interoperability 15:29:35 ... Of course, this resolution has always been a draft, and it's not appropriate to cite it 15:29:46 ... or use it as a basis for anything stable, and I don't think anyone has done that 15:29:53 ... But the inputs to the resolution function were already in the bit 1.0 standard, right? And that has been implemented by many people 15:30:04 ... And, uh, that will break, um, so unless everybody upgrades their… their implementations, it will… it will break in the sense that 15:30:07 ... If you implemented it… if we make this change, and we implemented it 1.1 15:30:10 ... Conformant client 15:30:21 ... it will, in some cases, not be able to talk to all the existing OneDid 1.0 infrastructure. That's what we're breaking 15:30:23 q? 15:30:25 Otto Mora: Okay... 15:30:30 ack Wip 15:30:35 ... So, okay, we got, uh, Will, and then Manu, and then, yeah, this is, like, the last set of comments before we go ahead and vote. Uh, so, Will? 15:30:43 Zakim, close queue 15:30:43 ok, pchampin, the speaker queue is closed 15:30:45 ... That might be a 15:30:48 Will Abramson: Yeah, I just want to throw it... 15:30:52 ... I just want to say, with my chair hat on, I think 15:30:59 Otto Mora: Okay... 15:31:02 Will Abramson: we found ourselves in a very unfortunate position, right? We have four and a half months left. I think my biggest concern about... 15:31:13 ... Have this discussion, it didn't come up. making this change, it's who is going to take on the work to do all the things that Marcus has just highlighted to make it possible. So that's the only thing I want us to consider. You know, it's unfortunate, as Marcus said, we did 15:31:22 ... earlier, but that is the reality that we find ourselves in. We have also spent months now discussing this. Unfortunately, we just need to make a decision and 15:31:26 ... move on, even if that's going to be uncomfortable for folks. We really need to 15:31:30 ack manu 15:31:32 manu, you wanted to note "in favor of didURL" and there are other things that need to be discussed downstream from this. 15:31:32 ... Just focus on getting this spec done and wrapping up this group 15:31:36 Otto Mora: Uh, Manu?... 15:31:58 Manu Sporny: Uh, yeah, I mean, uh, plus one to that. Um, I think there is a group of, uh, new editors that have stepped forward to do the work. Um, so I think that addresses, uh, your, um, you know, latter question, uh, Will. Uh, I wanted to highlight that we have been talking about this for months. This is not a new thing... 15:32:10 ... Um, it is coming about because we actually do have engagement around, uh, you know, the details of the specification when that was not true, you know, uh, last year at this time 15:32:42 ... Um, uh, and, you know, Marcus, you know, did a good job highlighting many of the things that we have talked about, uh, over the last couple of, uh, months. I don't think these are, you know, new, uh, uh, revelations to the group. We understand 15:32:46 ... uh, you know, those concerns. We've discussed them at length, um, and agree we just, you know, we need to make a decision here and move on. And it doesn't mean that we're done with this one decision. It's this one decision is going to impact algorithms needing updated and things like that. There are other discussions that we need to have after 15:32:46 it. Uh, but this decision is blocking our ability to 15:32:58 ... For a significant number of us, improve the specification in a way that allows us to finish it. That's it 15:33:07 Otto Mora: And one more thing, Manu, there's nothing to say that you're following the previous. But the resolver can connect in... 15:33:20 ... Kind of read backwards compatibility and and just understand when one version of the specs being used versus another, perhaps based on the input or anything like that 15:33:29 PROPOSAL: Modify the DID Resolution algorithm to receive a DID URL and options as input. 15:33:32 ... It's possible? Okay, thumbs up. Alright, well, then, uh, yeah 15:33:34 transcriber-bot, pause 15:33:34 ... The proposal is, uh, laid out here 15:33:34 scribe- 15:33:40 +1 15:33:41 -1, breaks interoperability with DID 1.0. many implications of this not considered. potential charter violation. 15:33:43 +1 15:33:46 +1 15:33:59 +0.5 15:34:00 bigbluehat has joined #did 15:34:03 +0 15:34:08 +0.7 15:34:12 -0 - i don't like the overall direction of the did resolution algorithm, but non-blocking 15:34:15 +0.75 15:34:15 +0.7 15:34:21 present+ 15:34:32 +1 15:34:40 PDL has joined #did 15:34:51 present+ 15:34:55 q+ 15:35:22 ack Wip 15:36:02 q+ to mention https://www.w3.org/policies/process/#Votes 15:36:15 transcriber-bot, resume 15:36:15 scribe+ 15:36:24 Markus Sabadello: If it's okay, I don't want to answer that right now, because I'm not sure, but I think that... 15:36:42 my point is: the fact that there is dissent should be recorded, in the text of the resolution 15:36:44 ... a really big 15:36:45 Will Abramson: Okay, thanks... 15:36:49 Markus Sabadello: it may not be a violation of the charter. That's my potential interpretation. So I would have to think about it. I think the consequences are really… a lot of people who are voting may not be aware of all the implications. I think it's even a… it would also be good for the chairs, maybe, to discuss if this... 15:36:56 Otto Mora: Okay, yeah, so I will just, yeah, note that, yeah, we didn't have overwhelming, sorry... 15:37:00 ... Absolute consensus, but we did have, uh 15:37:02 RESOLVED: Modify the DID Resolution algorithm to receive a DID URL and options as input. 15:37:03 ... More of a majority, and we noted that 15:37:05 s/it may not be a violation/it may be a violation/ 15:37:12 zakim, open the queue 15:37:12 ok, ottomorac, the speaker queue is open 15:37:15 q+ to mention https://www.w3.org/policies/process/#Votes 15:37:17 ... the same thing, opinion as well, uh, on the record. So, with that, it's resolved, uh, and… I will open to this now 15:37:20 ack JoeAndrieu 15:37:20 JoeAndrieu, you wanted to mention https://www.w3.org/policies/process/#Votes 15:37:22 ... I think a few folks… Was it Joe that you wanted to… Yeah, go ahead, Joe 15:37:35 Joe Andrieu: Yeah, I just wanted to give the chair a pointer to the section in the W3C process document that deals with where we're at and what we just did... 15:37:48 ... Just take a look at that, that'll give you some background 15:37:51 Otto Mora: Thank you. Mm-hmm... 15:37:55 Joe Andrieu: So, this is part of dealing with dissent, so I think we have appropriately acknowledged that Marcus has a dissenting opinion, um, and the chairs decided to, uh, vote, and there's a section that describes how that works, and so... 15:38:01 Otto Mora: So now the question, I guess my immediate question, which is the next topic... 15:38:04 Topic: Who will make the changes to DID Resolution inputs? 15:38:07 ... It's, uh… Okay, um 15:38:13 ... inputs, right? I mean, is it 15:38:18 q+ 15:38:22 ... part of the work that Steven was thinking about, or how are we thinking about this? I know Steven's already been… Who would make the changes to the date resolution? 15:38:28 ... volunteering a lot of his time, so I don't want to just presume that he would, but… Yeah, uh, I see Joe 15:38:29 ack JoeAndrieu 15:38:40 q? 15:38:41 Joe Andrieu: Yeah, so a couple of my PRs already have language that we can use for this. I know those PRs are too monolithic to adopt as a whole, but we can certainly mine the language in there... 15:38:43 ... And as one of the editors, I'm happy to help with that 15:38:46 Otto Mora: Okay... 15:38:49 q+ 15:38:52 ack Wip 15:38:53 ... Okay, sounds good. Unless anybody else has any comments on that 15:39:02 ... Uh, well 15:39:06 ... Go ahead, sorry, you're on mute 15:39:16 q+ 15:39:19 Will Abramson: Sorry. I don't like you muting myself. I was just pointing out that we will also need to make changes to this call. I mean, as Marcus showed us, but there are… There are sentences in there that we'll need to change to... 15:39:28 ack Manu 15:39:31 Otto Mora: Phenomenal... 15:39:34 Will Abramson: So probably one of the tasks we'll have to do is just do a thorough review of all of these specs to check the language... 15:39:43 Manu Sporny: I can make any changes to did core if we want to issue. If it's not already raised, we can raise one and then we should... 15:39:54 ... point to the resolution made on the call today, and then instruct the editors to update didCore, and I can do so 15:39:54 q? 15:39:56 Otto Mora: Okay. Alright... 15:39:57 Manu Sporny: uh... 15:40:02 Otto Mora: Okay. No one on the queue, and we... 15:40:03 Topic: DID Resolution TAG Review 15:40:11 ... Okay, uh, next topic is the date resolution tag review 15:40:12 https://github.com/w3ctag/design-reviews/issues/1157#issuecomment-4602993561 15:40:15 ... On this one, uh, I know that we have a comment from Lola 15:40:17 q+ 15:40:21 ... It's here. uh… And, uh 15:40:23 ack Wip 15:40:26 ... we wanted to 15:40:36 ... see how we best respond to that, so I see, yeah, go ahead, Will 15:40:47 Will Abramson: But the problem is... 15:41:00 q+ 15:41:04 ... I can't also say, but we still have this… well, I mean, I kind of need to say, we still have this section that needs to be reviewed, but that section isn't done yet. So… I don't know if people have advice for how to… navigate this situation. But… Um 15:41:07 ... That's where we are 15:41:13 Otto Mora: Mm-hmm... 15:41:21 ... Let's see what it should say. Mano? 15:41:26 ... Oh, sorry, no, I thought about it. I was thinking, never mind 15:41:39 Manu Sporny: Comments that you made? Yeah, I think, uh, I think that's fine, Will, just to say that. I mean, you know, the TAG are friendly people, they don't have sharp teeth, um, so we can just give them an update. Are we positive we've responded to all of Jeffrey's... 15:41:42 Will Abramson: Yes, well, what I will do is I'll, like... 15:41:49 ... Bye-bye. Itemize them and point to the issues, but 15:41:54 ... Right, right 15:42:13 Manu Sporny: Yeah. Yeah, and just… and then just let Lola know that, hey, we're still at it, working on the resolution algorithm, which is one of the things that, you know, Jeffrey mentioned, but we… you know, it kicked off a lot of discussion in the group, and we're rewriting it in the hopes of going beyond... 15:42:26 ... You know, what Jeffrey was talking to about getting real, real crisp clarity around what exactly resolving and, you know, resolution and dereferencing means and does, and we will let them know. when that last piece is done, because we'd really like them to review it 15:42:31 Otto Mora: Okay... 15:42:31 q? 15:42:37 Manu Sporny: I think we should just leave it at that, you know, it's not, yeah, and do it sooner than later... 15:42:41 q- 15:42:43 Will Abramson: Yeah, I'll do it tomorrow. Great, that's great. Um, yeah, and then the last thing I'll add is, you know, it's just another flag, but we are in time pressure... 15:42:49 ... Because… So hopefully, let's try and get this dereferencing algorithm done in the next month. That would be wonderful 15:42:50 Topic: DID Resolution PR review 15:42:52 Otto Mora: Mm-hmm... 15:42:57 ... Thank you 15:43:07 ... Uh, okay, so the next topic is the debt resolution PR review, including, uh, the conversation from yesterday. So yesterday, we had a special topic call 15:43:12 ... Uh, discussing PR335, which was introduced by Steven. Uh 15:43:19 ... We talked about the, you know, his proposal text for the algorithm and the various changes 15:43:23 ... Then Joe had also raised some concerns about the order of the operations, and 15:43:32 ... Really helped me visualize 15:43:45 ... what the implications are, I think that's really helpful to do. For those of us that maybe are a bit newer to the spec. Some of the other folks, and then having… kind of… Uh, we had some feedback about the way he had ordered the steps. Uh, I think there was some useful screen sharing we did, which 15:43:58 ... and the logic, and I think, uh, Steven 15:44:06 ... It helps to follow things, just when you're screen sharing. Um, then we talked about the broader implications of that. I was gonna perhaps rework the PR, but I don't know, Steven, if you had a chance to do that yet or not, but maybe asking you if… It's worth 15:44:09 Stephen Curran: Yeah, so, um... 15:44:12 Otto Mora: reviewing now... 15:44:21 Stephen Curran: Yeah, so what I did, there was… there was conflicts based on previous PRs, so I closed, um, the first one, um, and opened a new one... 15:44:31 ... Um, the… Um, Will's gone through it, so I opened it yesterday. Um, Will went through it this morning, um, invited others to 15:44:35 ... The changes are listed in the… in the comments, so it, um 15:44:47 ... Removes what were the first two steps. Um, narrows it down to just 3 types of things that get… that happen. Um 15:44:56 https://github.com/w3c/did-resolution/pull/340 15:44:56 ... And that happened in the next phase, which is either the resolution doc is returned 15:45:05 ... um 15:45:13 ... dereferencing of some other resource other than the DID doc, or there's some DID method specific handling 15:45:20 ... a an object in either the did doc or did metadata drives the. Um, there's some extra wording to say, you know, like, if you pick a service 15:45:47 ... Um, and then it opens… I'll open a can of worms question on… on… at this moment, which is, um 15:45:55 ... and there's a path. even though you don't get to the path selection. You're you stop it at at the identification of the service, that service, the processing of that service may involve the path 15:46:01 https://pr-preview.s3.amazonaws.com/swcurran/did-resolution/pull/340.html 15:46:03 ... In the overall processing, there's various stages that we've talked about and the algorithm describes various stages. And one of the things that comes up is that at the different stages. The 15:46:12 ... Um, elements of the DID URL, the parameters in the path, get used 15:46:19 ... And what becomes tricky is, and probably is a security risk, is the fact that 15:46:41 ... Those stages are kind of invisible to one another. And so there is no global picture of what parameters are actually processed and which ones, if any, are ignored 15:46:41 q+ 15:46:52 ... And and that is, is kind of interesting and something that I think we need to talk about and figure out. So I'm trying to figure out how best to do that 15:47:01 ... Um… Will had proposed, um, some categorization of parameters, and I've got some wording that I'm gonna propose for that. But I think, fundamentally, we have to make a decision that. Then 15:47:03 Pierre-Antoine Champin: Bye... 15:47:06 Stephen Curran: did URL be referencing is... 15:47:15 ... A, um, do you want to pass back the fact that you've ignored a parameter, and B 15:47:28 ... Um, how does that get passed back? And… and that could lead to the requirement that there be 15:47:33 ... The referencing metadata pass back that says, hey, here's the, the parameters or the path that I ignored. In… in the overall process 15:47:33 q+ 15:47:38 ... So I'll stop there 15:47:46 ack manu 15:47:57 Otto Mora: Yeah, sorry, go ahead... 15:47:58 ack manu 15:48:02 Manu Sporny: I'm next on the queue. I guess I'll go. Otto, you might be muted, acknowledging people... 15:48:10 ... Uh, uh, plus one, Steven, I think that is a, uh, it's a good call-out. I, I'll highlight that the algorithms that we have in the spec 15:48:26 ... are general guidance. Um, implementers can do something wildly different, as long as the end result is the same. And we can't 15:48:32 Stephen Curran: Mm-hmm... 15:48:36 q+ 15:48:39 Manu Sporny: tell implementers every little thing that they might have to care about, especially if they're in different, you know, programming environments than others, different libraries being used, you know, all that kind of stuff... 15:48:49 ... Um, so… I do agree that we should call it out, but I don't think we need to… I mean, the algorithm does not need to be perfect and cover every single case. It just needs to cover, kind of, the basic stuff 15:49:02 ... Um, and we can talk about implementation, uh, you know, security and privacy considerations in the threat model, um, and we can highlight places where we're kind of like, hey, you might want to, you know 15:49:09 ... let different parts of the process know when different warnings are kicked up from different subsystems, right? But unless it results in, like 15:49:16 +1 to Manu -- I just felt it important that we have the discussion. 15:49:28 ... critical change in the output. One, we don't have to document it at all, but it's usually a good idea to at least write a note or two, you know, about it 15:49:41 ... So even though everything in the algorithm is a black box to other parts of the algorithm, it's up to implementers to try and like, I mean, you know, figure out the right thing to do. We need to kind of trust that, you know, the good majority of them are going to do 15:49:56 ... a decent enough job implementing it and have processes in place that will find bugs and refine their implementations and make new releases. And if software projects don't have those 15:49:58 q? 15:50:02 ... processes in place, people might not use that software, right? 15:50:08 ack Wip 15:50:12 ... So anyway, I don't think, you know, yes, we should speak to it, but I don't think we need to be perfect in the first go around. That's it 15:50:15 Otto Mora: Okay... 15:50:33 Will Abramson: Yeah, no, I mean, I think this is good step in the right direction. I just wanted to flag folks. I mean, please take some time to try and review this over the weekend, so we can talk about it on Wednesday. The one thing that I want to draw people's attention to in there is... 15:50:40 ... This idea that, Steven, you've got about process objects as this… as this handling strategy, I still don't fully understand that 15:50:49 ... And… it… I think… so, like, they set the handling to process objects. Like, for me, that is, like… I mean, for me, the purpose of this step 3 15:51:03 ... That is 15:51:10