13:58:33 RRSAgent has joined #did 13:58:37 logging to https://www.w3.org/2026/06/10-did-irc 13:58:41 rrsagent, make logs public 13:58:45 Meeting: Decentralized Identifier Working Group 13:58:45 Wip has joined #did 13:58:49 Chair: ottomorac 13:59:00 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0001.html 13:59:01 clear agenda 13:59:01 agenda+ Will Abramson 13:59:01 agenda+ Pierre-Antoine Champin 13:59:01 agenda+ Otto Mora 13:59:01 agenda+ [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did/) ([View Calendar](https://www.w3.org/groups/wg/did/calendar/)) 13:59:21 previous meeting: https://www.w3.org/2026/05/28-did-minutes.html 13:59:31 next meeting: https://www.w3.org/2026/06/11-did-minutes.html 14:00:03 present+ 14:00:44 KevinDean has joined #did 14:00:52 present+ 14:01:36 manu has joined #did 14:01:42 swcurran has joined #did 14:01:42 present+ 14:01:48 present+ 14:04:21 transcriber-bot, resume 14:04:22 scribe+ 14:04:28 Otto Mora: Okay... 14:04:31 Will Abramson: Okay. Welcome, everyone, to today's... 14:04:34 ... Good working group special topic call 14:04:40 ... Um 14:04:46 JoeAndrieu has joined #did 14:04:49 ... So today we are just going to be focusing on the PR Stephen raised about the algorithm for determining the handling strategy. In the dereferencing algorithm 14:05:01 ... Um, so that's PR335. I don't know if everyone's had a chance to read it, but hopefully people have at least had a little glance, and we're just going to dive into it. Um 14:05:08 ... Yeah, so before I get into that, just, like, tomorrow, we are gonna… Be having this, um 14:05:12 ... proposal, I'm gonna do a vote, and then hopefully we're gonna get through this 14:05:22 ... discussion about the inputs to the DID resolution algorithm, so we'll start the call with, like, 10 minutes. I think Marcus wants to present some things to get them on the record, and then 14:05:33 ... um… Yes, that's just a flag for that 14:05:37 ... Okay, so… topic this 14:05:43 ... You know, if people want to respond to that, we can do that, but we'll be taking a vote by halfway through the call, at the latest. No, no, no 14:05:54 Topic: DID URL Dereferencing Algorithm - determine handling strategy 14:05:59 https://github.com/w3c/did-resolution/pull/335 14:06:10 ... Okay, uh, yeah, so this is the PR. I don't know, Steven, if you had anything prepared, I didn't, like, check if there's anything, I mean, we could just… um 14:06:15 ... Have a look at the 14:06:16 Stephen Curran: Yeah, the only... 14:06:19 Will Abramson: um... 14:06:26 ... the text, like, I could even share my screen, or 14:06:35 Stephen Curran: Um, do a pass through the extensions. things that I've got other than just the text. I didn't prepare a presentation or anything, but um… the text is pretty short and to the point, so I think it might be reasonable just to go through it that way, but I did... 14:06:49 ... registry, and found all of the extensions that were relevant, and that might be worth looking at. Um, we also have that question that you and I. We're batting back and forth in the comments about 14:06:54 ... Um 14:07:00 ... you know, there's different parts to DID URL dereferencing, and… how 14:07:07 ... Um, different parameters apply at different places, and so there's the question of 14:07:15 ... Um… Um, you know, our elements… I should include path in that, so there's the parameters of path, and our elements 14:07:27 ... there's no global picture of the parameters that actually get consumed and impact things. Like, there could be parameters that just get completely ignored 14:07:39 ... And I don't think there's a way to notify of that. So I did want to get the group to discuss that. So those are the things that I want to go through 14:07:40 q+ 14:07:43 Will Abramson: Okay... 14:07:45 ack JoeAndrieu 14:07:52 ... Great. So, I don't know if everyone has read it, so maybe I can share my screen, and we can just… I'll just sort of roughly go over what the algorithm says today. Um… I see Joe on the queue, so I'll let you go, Joe 14:08:07 Joe Andrieu: Uh, yeah, thanks. I do want you to read through it. Um, this inverts quite a bit of the strategy that, um, or the algorithm that I had put together, and I think it's broken for some important reasons. For example, if I have a version ID query parameter... 14:08:19 q+ 14:08:27 ... And it builds backwards. It is it needs to be a bid document, retrieval strategy. So the very first step, like, that's usually in the other algorithm I did, that was the fallback. If you didn't find any other strategy, then the only strategy left is did document. So this is put first 14:08:42 ... And I think the same thing happened in the in the next spec which is it says hey if it's did method specific then it overrides stuff. And I think did method specific should be a fallback if the other things don't apply. So I think there's some order of operation here that I think are not quite right 14:08:43 ack swcurran 14:08:51 Will Abramson: Okay, thanks, Joe. Yeah, I will note that I saw that… I mean, yeah, well, I'll pass it to Stephen... 14:08:55 Stephen Curran: I mean, I guess he did put it out. I… Joe, I don't understand how you... 14:09:01 ... Say that the, you know, the first step says if it's a fair URL, did you get it? 14:09:10 ... then you return the DID document. I don't think that's… If the DID URL is a bare DID, has no parameters, no path 14:09:15 ... Too controversial, maybe, in having it there, as opposed to a fallback 14:09:28 ... I've also got the fallback, which is also returned the did docs. So I'm confused as to why that would be problematic, but that's okay. Let's take a look at it 14:09:42 Will Abramson: Yes, okay. I mean, I'm just going to walk through the top level things. I mean, so, right, we're going into this algorithm We have executed a resolution request. So we have a did URL... 14:10:03 ... We execute a resolution request, and we get back a DID resolution result. And then the purpose of this algorithm, 5.1.3, is to determine the, like, handling strategy, we're calling it here. So, like, how are we going to handle this DID URL? to retrieve a resource, right? 14:10:08 ... um… Well, algorithm we're going to use, I suppose 14:10:13 ... And then 14:10:15 q+ 14:10:19 ... Yeah, so there is this question of, like, if it is a bad DID, I don't think this is wrong, like, so if it's a bad DID, return the DID document, but I do question… I think I'm more on Joe's point, where if we have this fallback 14:10:26 Stephen Curran: Okay. That's fine... 14:10:30 Will Abramson: Like, it's not… you don't need it, right? Like, it's gonna fall back anyway if it's embedded, is my sense of that, but… Um, okay, then there's this question about did method specific, um, so... 14:10:36 Stephen Curran: Yeah... 14:10:41 Will Abramson: Can you give an example of what this would be? Or is this something undefined that we don't know about?... 14:10:45 Stephen Curran: No, I think this… I mean, there's a very real one. I mean, CHEPT went through a lot of work to define... 14:10:54 ... Um, however, at the end of the day 14:10:59 ... When you have a check DID, and you use a DID 14:11:04 ... links resource. What you want to do is. a generic, non-DIDMET-specific thing called DID-linked resources, and that's great 14:11:21 ... process a data from the checked blockchain and retrieve a resource off the blockchain and return it. Well, to me that is did method specific 14:11:25 ... And so I'm very much talking about where 14:11:33 ... you get to that. So they give another example, and let me… they give another example where you can have a DID web with a DID linked resource 14:11:52 ... And the way that example works is you have a DID web, the example they use, you have a DID web DID link resource, so you get that back and then you would then process the resulting DID because the result of that is the DID. dereference that 14:12:08 ... And that did is a did checked resource. Now if you do that again, dereference it again, you're just in an infinite loop. So you eventually have to stop at that point and you have to say, oh, this is a did check 14:12:12 q+ to discuss how did linked resources is a property-based retrieval strategy usable in any DID Document 14:12:18 ... resource, and I need to use the DID method-specific code. and did chat, or at least I think that is implied. Um, because 14:12:24 ... That is the 14:12:35 ... resource you're trying to get to, and the only pointer to it, the only reference to it, the only identifier for it, is a DID. Is a DID URL, not a DID. A DID URL 14:12:38 ack manu 14:12:41 ... So that's the example that I use for that one 14:12:44 Will Abramson: Okay, well, I see there's a queue, so we can go through the queue, and then keep going on. Uh, Manu?... 14:13:05 Manu Sporny: Um, yeah, this was on the previous statement about, like, you know, having… doing all the generalized stuff early in the algorithm, and then falling back to the, you know, DID method-specific one, uh, towards the end. Uh, plus one to that, so I think I'm agreeing with Will and Joe's general statement... 14:13:27 ... But, you know, looking at this algorithm, I'm kind of like, is it in that order already? Um, so, so just light feedback on, I too would prefer that we do, you know, as much of the generalized stuff up front as we can, and then go. Drop back to the DID, you know, DID-specific or extension-specific stuff. um 14:13:30 ... Uh, towards the end 14:13:38 ... And, and I realized even that it's complicated, right? Because, um, okay, so, so that was the first statement. Second statement is, uh, it doesn't really matter 14:13:41 Stephen Curran: Could I just quickly respond to that, Menu? Just real quick... 14:13:44 Manu Sporny: Sure, and I've got a second thing after that, but please go ahead... 14:13:48 Stephen Curran: Yeah, yeah, but my… the reason I put it there is because... 14:13:51 Manu Sporny: Mmhm... 14:13:54 Stephen Curran: If you keep doing this algorithm over and over, you never get to the DID method specific. And so that's why I put it at the top. That's it... 14:14:02 Manu Sporny: Yeah, yep, yep, yep, yeah, yeah, that, that, that, um, it makes sense to me. I, I think the, the other, the other comment is it... 14:14:20 ... Doesn't really matter. Like the algorithm doesn't really matter as long as the outcome is the same, meaning that we just need an algorithm that that works. It doesn't have to be pretty or perfect or, you know, and whatever we can rearrange 14:14:25 ... the algorithm in CR, as long as the output isn't changed, right? So 14:14:37 q? 14:14:44 ... So I want to make sure we don't get wrapped around the axle too much about like, oh, well, you know, step three should happen before step four, unless there's a bug, because we can always make this nicer in CR if we want to, understanding that we want to get it right the first time. I don't think we should get too wrapped around, like 14:14:50 ... You know, um, the design philosophy, if the outcome is the same 14:14:52 ack JoeAndrieu 14:14:52 JoeAndrieu, you wanted to discuss how did linked resources is a property-based retrieval strategy usable in any DID Document 14:14:58 ... no matter which way we order the steps. That's it 14:15:01 Will Abramson: Okay, thanks. Bye. Joe?... 14:15:13 Joe Andrieu: Yeah, sorry, Manu, I don't agree, actually. I think the point of this conversation is to figure out the steps. I construct a very different set of steps. I'm seeing a bunch of holes when I compare the two of them. Um, one of them is, I... 14:15:23 q+ 14:15:29 q- 14:15:30 ... firmly disagree that DID-linked resources is a DID method-specific, um, algorithm. It is a property-based algorithm in the metadata document, and I could create another DID method that uses that. And so, you're not going to know from looking at my 14:15:46 ... Did method specification in the did whether or not I have a property called did linked resources. So the did method specific is also in the forefront here means we're going to have interoperability problems with any did method 14:15:53 q+ 14:16:05 ... Um, that defines things differently. So this is an anti-interoperable strategy. I believe the DID method-specific stuff absolutely needs to happen at the end, and that we should be processing the query parts and the parameter parts before that, so that we can use these interoperable mechanisms that we have come up with in our conversation, such 14:16:05 as having 14:16:11 ... An object has type path handler. Right? So I think we've come up with mechanisms that are not gonna be exposed with this algorithm 14:16:14 ack swcurran 14:16:15 Will Abramson: Okay. Thanks, Joe. Steven?... 14:16:18 Stephen Curran: I'm gonna try again... 14:16:27 q+ 14:16:28 ... DID linked resources is not DID method specific. However, in the example where it is used with DID checked 14:16:34 ... It is… the handling of it is specific to chat 14:16:42 ... So while I completely agree that linked resources can be used in a variety of ways with different 14:16:47 ... did methods, and I gave an example of one earlier 14:16:59 ... I would assume that… If it's used within checks, the behavior is intended to be that you go to the blockchain ledger and you pull a resource off it. And what I'm wondering about, and I'm 14:17:11 ... If you need to pull something off the did check ledger, that would be handled by the did checked method and that's why it's there 14:17:16 ... If there's some other way to handle it 14:17:19 ... I'm open to that, but I don't understand another way to do it. But that's why I put it there, is because 14:17:24 q+ to say that is a handling strategy invoked based on the property in the DID document metadata 14:17:25 ack Wip 14:17:28 ... If it falls through, it'll never get down to did method specific because it'll keep being interrupted by identified object 14:17:35 Will Abramson: Uh, yeah, I put myself on the queue to respond to that, because. My sense is... 14:17:51 ... if the, you know, like, if a DID-linked resource is also an identified object, like we kind of discussed, right? Like, there's DID-linked… currently, we know of DID-linked resources, we know of linked resources, and we know of these services with a specific type 14:17:57 ... And I believe, in our previous conversation, we discussed defining a type, right? So all of these things would 14:18:08 ... add, or any… anything that wishes to handle paths would add to itself, and say, look, hey, I handle paths. And then, you know, you do this algorithm, which I think is here, to select 14:18:24 ... the object that you are going to use to handle the path. And for me, the did method specific part that you're kind of referencing is, okay, how do I handle this object that is a did link resource, right? I think you are right. There is, you know, if that's a 14:18:35 q+ to ask about "property specific" handlers? 14:18:35 Stephen Curran: Okay... 14:18:40 Will Abramson: for, right? Like, this is just saying, identify the object. if that's a did-linked resource stored on check, like, I'm gonna have to interact with the checked ledger. But that is encapsulated in the retrieval algorithm, or whatever we're calling that now, which is... 14:18:46 ... that is going to define how I… how I handle the path and retrieve the object, how I… used it. And I think we can say 14:18:58 ... that there are no did method… well, I think we really should be saying there aren't any did method-specific approaches. If you want to handle path, you should be using this path handling object type 14:19:00 Stephen Curran: Okay, and so… and so what you're saying is... 14:19:01 Will Abramson: Uh, well, let's do the queue, Steven, if... 14:19:03 ack JoeAndrieu 14:19:03 JoeAndrieu, you wanted to say that is a handling strategy invoked based on the property in the DID document metadata 14:19:04 Stephen Curran: Okay... 14:19:08 Will Abramson: Cool. Uh… But maybe that's too far. Joe?... 14:19:12 Stephen Curran: I'm happy then. Okay, that makes sense... 14:19:15 Joe Andrieu: Um, yeah, my point was mostly the same as what Will just said. Um... 14:19:31 Stephen Curran: Okay... 14:19:37 Joe Andrieu: The retrieval strategy of a did link resource may in fact need you to talk to the checked, ledger. But at the point here at step two we don't even know we don't have the information to know if that strategy is the one that we need to use. So, I can't look at, uh, did WebVH, um… Ah, ah... 14:19:50 ... uh… set of data. Like, I can't look at the URL and know if, somewhere in the process, I'm gonna get a DIDLINK resource attached to it 14:20:00 Stephen Curran: Okay... 14:20:02 ack manu 14:20:02 manu, you wanted to ask about "property specific" handlers? 14:20:02 Joe Andrieu: So we don't have the information at this point to make a determination. I think it's part of if you have a did linked resource property in the metadata, then we have to invoke this this strategy as defined by did linked resources, which may need you to talk to the ledger... 14:20:03 Stephen Curran: That explanation makes sense to me. Good... 14:20:06 Joe Andrieu: Cool... 14:20:09 Will Abramson: Great. Uh... 14:20:11 Stephen Curran: So I'll take out… I'm taking out 2… oh, I'm taking out 1 and 2... 14:20:14 Joe Andrieu: Well, hold on, let me… I guess the other half of that was… wait... 14:20:16 q+ manu 14:20:22 Will Abramson: Ah, you got it. Alright, let's do a queue. Let's do a que... 14:20:28 Joe Andrieu: Sorry Will. We do have the expectation that of our two hundred plus did methods that there may be some that have method specific path handling... 14:20:39 ... Um, so I do think we should still have a fallback. Um… Um… and we don't have a way to even inventory that. We don't have the resources to actually go and find them. Because it… to… to 14:20:42 Will Abramson: But... 14:20:45 Stephen Curran: But you're saying we… sorry, I was just saying we take it out of where it is now... 14:20:50 Joe Andrieu: Okay, fair enough. Okay. Yeah. I think two should be, like, maybe the last one or or the last one... 14:20:50 Will Abramson: Okay, Stephen, let's do the queue, if you can jump on the queue... 14:20:52 ack manu 14:20:54 Stephen Curran: We haven't, yeah, we haven't gone through the rest of the algorithm, so 1 and 2 are gone. Yeah, sorry... 14:21:01 Will Abramson: Hahaha... 14:21:01 Manu Sporny: Okay, and by gone, we mean move further down in the algorithm, not delete it entirely, right?... 14:21:03 Will Abramson: Uh, but yeah, I think I agree, one and two are gone. Manu, sorry... 14:21:07 Manu Sporny: Okay, all right, that... 14:21:10 q+ 14:21:14 Stephen Curran: Yes. Perhaps, yes. I'm just saying, let's… we're going through this in order, and so right now, the first two are… are out from where they are... 14:21:20 ... Yes 14:21:24 ... Yep 14:21:27 Manu Sporny: Yeah, let me strongly assert they're moved down in the algorithm somewhere, we haven't determined where yet, because they do need to exist somewhere in the algorithm. So, are we also talking about adding a path... 14:21:37 ... uh… sorry, a property-specific, like, step? Is that what I'm hearing, Joe, you say, and Steven, you agreeing to? 14:21:45 Stephen Curran: Well, I think 3 is now step 1, and now we're going to continue on with. discussing the rest of the algorithm... 14:21:54 Manu Sporny: Okay. Okay. All right. Yeah, let's just go. I'm just… I'm wondering if there is an additional step here in that you've got some kind of... 14:22:14 ... property-specific processing based off of DID extension, or extension-specific property… uh, uh, processing, right? So, like, you know, the resolver knows of a variety of different extensions, and in, you know, step 14:22:20 ... whatever, uh, it is allowed to use those to… to do, um, you know, dereferencing, and then 14:22:26 Will Abramson: Mm-hmm... 14:22:30 ack Wip 14:22:31 Manu Sporny: If it's not that, then the the one after the step after that is the did method specific processing. Is that what others are thinking?... 14:22:42 Will Abramson: Well… Well, I put myself on GitRoot to talk, like, to get us back into that algorithm, and I think you're right, right? Like, this… to me, this identified object is about the property... 14:23:00 ... to me, this identified object is, like, we're trying to select some object in this DID resolution result that is going to tell us the handling strategy. And… And currently, I think how this algorithm works is we are selecting, uh 14:23:16 ... we are going to look at our query parameters, right? Like, our query parameters might be like service. The service query parameter is identifying a specific object by an identifier that we should use, right? 14:23:23 ... And then there is some question about any other query parameters that might be extensions that we should… that also target specific objects 14:23:40 ... like, for example, maybe in the future there's some like linked resource query parameter that acts similar ways that that could happen. And we should allow that. Then I think there's this, you know, like, so we've we've applied all the query parameters that we understand 14:23:45 ... And then we have to decide, okay, which one of these objects, based on the things that we've applied, which might be none 14:23:51 ... do we select? And I think that is then using the path, and this path handling object type 14:23:56 ... Right, so we collect all the pass handling objects left in the DID document that 14:24:04 ... you know, that we need to select from, and then we use this… this… the path in the DID URL to 14:24:16 ... identify one of these objects. And if there are multiple, it's an error. That was my reading of the algorithm. um 14:24:22 ... I mean, maybe it would be good to have like an example here. Together. Um 14:24:28 q+ to advocate for service query parameters first 14:24:37 ... So, that is all of the properties for me. Like, these identified objects are what we're now calling, like, path handling objects, and the DID resolution result is expected to have 14:24:41 ... some objects in there that say, hey, I'm a pass handling object, I handle. Ah 14:24:48 ... But then this part would just… I guess the DID URL might not have a path 14:24:52 ... Like, you would just fall through here, and probably go to default, unless 14:24:55 ack JoeAndrieu 14:24:55 JoeAndrieu, you wanted to advocate for service query parameters first 14:24:59 ... One of these query parameters are explicitly targeting a. Joe? 14:25:08 Joe Andrieu: Um... 14:25:15 ... Yeah, I'm looking through the PR preview for that process object section, which maybe would… Answer what I'm looking for. But in this this. Oops 14:25:23 ... In this process, I'm not seeing the properties pulled up 14:25:31 ... Um, as an invocation. Nor am I seeing that if there's a service query parameter that that takes priority 14:25:34 Stephen Curran: That's in 3. That's in 3... 14:25:38 Joe Andrieu: Um... 14:25:47 Will Abramson: Okay... 14:25:56 Joe Andrieu: Right. My understanding was our consensus in previous conversations was that if the service query parameter is presented that that has priority. Um... 14:26:00 ... This doesn't seem to suggest that. Um, but I, I get 14:26:02 Stephen Curran: It's the first step in the algorithm... 14:26:03 Joe Andrieu: So we got rid of 1 and 2... 14:26:07 Stephen Curran: Yeah. So, 3... 14:26:12 Joe Andrieu: Right? So… so you're saying if there is only… only a service query parameter, then... 14:26:20 ... What if there are multiple query parameters? And what about query parameters outside the specification? 14:26:24 Stephen Curran: So that's… I don't have a joke... 14:26:27 Will Abramson: Yep... 14:26:27 Stephen Curran: Please read step three... 14:26:28 Will Abramson: Well, no, I can switch that, because I... 14:26:31 Stephen Curran: I'm sorry, I'm frustrated... 14:26:32 Will Abramson: I… I also... 14:26:35 Stephen Curran: Yeah, um... 14:26:37 ... Yeah 14:26:40 Joe Andrieu: I'm frustrated too. So, like, go ahead, Will. We got a queue to manage, and I don't want to be disruptive... 14:26:58 Will Abramson: In the comments around this. I'm not on the queue, but I will imagine I'm on the queue and put myself on it. My comment was similar that I mean, we did say service query parameter takes priority. I mean, I have some, there's some commentary, good commentary on the issue... 14:27:06 ... Processing all query parameters that you understand. Uh, I do think, really, step 3 should be about 14:27:11 ... That are… you know, and then this is another thing that we don't really have well-defined, but that are about selecting objects in the… Um 14:27:14 Stephen Curran: Yep... 14:27:36 Will Abramson: In the document. I don't know what I tried to name it. I didn't name a very good job. I think there are like three types of query parameters that you could have in a DID URL, right? There are DID resolution parameters. We don't care about these, and we also don't even know which ones are them, right? Like maybe we know version ID 14:27:36 and version... 14:27:37 q+ 14:27:39 Stephen Curran: Yep... 14:27:53 Will Abramson: time, but there might be others in the DID URL that we don't understand, but we're just going to pass on to DID resolution, and it's going to do some stuff and return back. And then there's these ones that are about targeting a path handling object. I had in here, I mean, we can come up with a different name, these are like 14:27:53 service... 14:27:54 q+ 14:28:05 ... And I think service type, and even though currently we've said we're not going to standardize service type, that is an extension that, you know, we're going to move it to extensions, we need to have a way for our algorithm to handle all of these extensions that might be about targeting path handling objects 14:28:17 ... And obviously, you know, people doing dereferencing might not understand service type, and I think they're just going to ignore all the query parameters that they don't understand 14:28:28 ... Uh, but service should be processed, and it should be processed first, before you get into the actual path handling bit. Um, you know, for me, like, processing service is, you are identifying a specific object in the 14:28:34 ... document, and if you don't find that object by that ID, then it's an error, right? You've got a not found error or something 14:28:37 ... there is no path handling that happens here, right? Because 14:28:44 ... Path handling is just about filtering from the set of objects, if there are more than one. Uh, and then I'll just go, and then there's 14:28:51 ... query parameters, which are kind of like… I mean, we went a bit back and forth, me and Steven, but they're, like, strategy-specific 14:29:04 ... Uh, which is about some transformation to the… the result. And all of these, or maybe not relative rep, but these are about… these are only specific to, like, the DIV document strategy. Um 14:29:08 ... Which is… And then, Stephen mentioned one more 14:29:23 ... uh… result parameters, so these are applied at the end. But I think the main thing for this step, where we're at right now, is there are some parameters which are about targeting a path handling object 14:29:34 q? 14:29:35 q+ the primacy of service is to bypass query parameters you don't understand. and we need to search for path handlers even if the path is "empty" 14:29:36 ... And those parameters should be applied first, right? For me, as a client executing this algorithm, I need to apply all of the query parameters that I understand are about targeting a path handling object. I think that's not quite in this algorithm yet 14:29:36 ack manu 14:29:41 q+ to the primacy of service is to bypass query parameters you don't understand. and we need to search for path handlers even if the path is "empty" 14:29:41 ... Uh, sorry, that's long for me. manner 14:30:01 Manu Sporny: Yeah, I think a plus one to that, Stephen, what might help here is to break it into those categories that, or some subset, I don't care about what the categories are, but having examples where we're like, you know, um... 14:30:19 ... I think that would help 14:30:22 ... process, you know, these sets of parameters first, process these types of parameters second, and maybe these types, you know, third. I don't know if we can cleanly do that. But then giving examples of, like, version ID and version time, and then service and service type, and 14:30:35 ... clarify, you know, what step 3 is doing. Because right now, it's, you know, it's good, but it's vague, it's a bit vague, and I think adding those kind of classes of parameter processing would 14:30:41 ... Clarify if the implementers on like, you know. They should be thinking about, you know, these things 14:30:41 ack swcurran 14:30:45 Will Abramson: Hey, thanks, my name's Steven... 14:30:48 Stephen Curran: Okay, 3 things, um... 14:30:59 ... On that last bit that Manny just said, I think it would be a good idea to put before, long before this, as part of the dereferencing, to talk about those classes 14:31:05 ... of parameters and how different aspects of this algorithm will process 14:31:10 ... different subsets of the parameters, because 14:31:15 ... like, a version ID, version time that you just mentioned, well, they've got 14:31:35 ... a place above this. those have been processed and would be ignored in here, because we've already done the DID resolution by the time we get to here. So, anything that applied the DID resolution. So, I think that… that classification that Will put into the comment, that should go into the document, but in a 14:31:48 ... I think I like what Will said. I agree with it that the we've got to broaden the I've got to broaden the wording in the identified object paragraph. Um, to include that 14:31:58 ... You know, all parameters get processed. Those identified that would identify a specific object would take precedence at this point 14:32:02 ... And then the last thing I wanted to say was 14:32:07 ... I think when… once we get past this and into the handling 14:32:11 ... I think we do want to pass in the DID URL, because 14:32:20 ... A service object that is also a path handling object, and you've got a path. In it, um, the 14:32:29 ... identify object strategy would still need the DID URL, because it might say, oh, well, this service type is a 14:32:39 ... you know, I picked it out because I selected the service, but I also passed in a path, and I want to use that. So, um 14:32:47 ... Even though we, what we don't wanna do is have a path passed in that gets ignored. Um, so the 14:32:55 ack JoeAndrieu 14:32:55 JoeAndrieu, you wanted to the primacy of service is to bypass query parameters you don't understand. and we need to search for path handlers even if the path is "empty" 14:32:58 ... handling of identified object would have to take into account the DID URL, not just… Wouldn't be limited to that. Um… That's it 14:33:03 Will Abramson: Steven? Uh, Joe?... 14:33:06 Joe Andrieu: Uh, yeah, two things. One is, I do think the primacy of service was in part to bypass... 14:33:14 ... Um the query parameters that, uh the caller may not know 14:33:18 ... Because if there is a service endpoint then this is this means invoke that service. And I think 14:33:29 ... So I just wanted to anchor that. Like, I think it's an important separation from the rest of the processing of the other query parameters. Um, the other thing I wanted to point out is that, um 14:33:32 ... Path handling algorithms may work just fine with an empty path 14:33:39 ... Um… if I put a domain name into the browser, it works 14:33:42 q+ 14:33:50 ... Um, and so there is, you know, an architecture for, hey, you don't have a path, but because your DID document has a path handler, we should use that instead of just returning a DID document. Um… So I'm I'm not sure 14:33:59 ... um… We moved away from a property-based analysis here, Steven, and I'm not sure what we're getting from it 14:34:04 ack swcurran 14:34:06 ... So, that confuses me here 14:34:09 Will Abramson: Uh, I'm sure… Steven?... 14:34:13 Stephen Curran: Uh, could you explain what you mean by... 14:34:25 ... That… like, if you just pass in… the last thing where you just… there's a… task handling in the DID document, and we're supposed to handle it 14:34:29 ... How would that work? I've been reading the extension called resource 14:34:35 ... Um, the parameter, and it had this similar concept that if you have the parameter resource 14:34:42 ... And it was just there as like resource true. You were supposed to infer something from the did 14:34:46 q+ 14:34:49 ... the doc to get an object, to get a resource, and I just wondered what that meant 14:34:49 ack JoeAndrieu 14:34:51 ... Like, how would you do that? 14:35:01 Will Abramson: Yep, sure... 14:35:01 Joe Andrieu: So, um, I'm not sure, um... 14:35:10 ... Uh, I was specifically talking about properties, not parameters. I can… in the algorithm I put together, I specifically walked through the information that was available, and I structured it in a way that I felt, uh, a 14:35:14 ... A dereferencer could walk through and say, oh, there's a service 14:35:25 q+ 14:35:27 ... query parameter. Let me handle that first. If there's not a service query parameter, then I need to look at the properties in the DID document. If there's nothing, no properties in the DID document that trigger me, then I need to look at the properties in the metadata 14:35:37 ... Right So I'm not seeing looking at the properties in the did document or the metadata here. And so it's hard to map this particular algorithm to how I had understood a reasonable flow 14:35:38 Stephen Curran: So that's the question I had. Sorry, Will... 14:35:41 Will Abramson: Yeah, go for it... 14:35:50 Stephen Curran: What do you mean, look at the properties? Could you explain how that would work? I saw that in your algorithm, and it didn't make any sense to me, so I didn't understand... 14:35:53 Joe Andrieu: So, you're... 14:36:00 Stephen Curran: I would think there would be rules around that. And yet so that's what I'm looking for is understanding what you mean by that... 14:36:02 could we view Joes alg in preview mode like this? 14:36:03 Joe Andrieu: What I mean is you look in the DID document, and you see if there are any properties in the DID document that, um... 14:36:06 ... Uh, should tell you to work with them. Um, because 14:36:09 Stephen Curran: Like what?... 14:36:12 Joe Andrieu: Like like a linked resource property... 14:36:19 ... For a did document that hasn't upgraded to this new path handling approach 14:36:22 Stephen Curran: Okay, so... 14:36:22 Joe Andrieu: We have linked resources as a way to do path handling. I'm trying to not break it... 14:36:25 Stephen Curran: Right... 14:36:30 Joe Andrieu: And if we don't look at the properties in the did document, then we're gonna break it. And so... 14:36:34 Stephen Curran: But… so, Joe, just… just one sec. I'm trying to say... 14:36:41 ... how do I look at those? What… like… like, if I have two linked resources, what do I do then? 14:36:47 ... I don't… what I'm saying is, saying that… Doesn't tell me what to do 14:36:48 Joe Andrieu: So linked resources of property at the top level of the document. So you go... 14:36:51 Stephen Curran: I understand that... 14:37:10 Joe Andrieu: So you use regular JSON parsing algorithms, you index to that property, and you read the value. There might be a dozens of linked resources all behind the linked resource property. And what you're looking for is the property linked resource, which you would handle according to the algorithm defined in the linked resource 14:37:11 specification... 14:37:11 ack Wip 14:37:14 Will Abramson: So I'm on the queue to have some things about this... 14:37:28 ... I do hear what you're saying here, Joe, but I felt like we moved past that, because your algorithm, as I remember it, was a 14:37:45 ... series of ordered steps, right? Like, first look for the properties, like linked resource, then fall back and look at the service, or something like that. There was an order of doing things. And my sense was, what we decided last time is. It's really this step, 4.1. We're gonna 14:37:58 ... That is the path handling object type. we're gonna collect all path handling objects, really, yeah, in the DID document and the DID document metadata, and how are we gonna know they're path handling objects? Because they have a type 14:38:08 ... Right? Like, my… I think the problem with calling out specifically linked resources or anything like that is that's effectively referencing a 14:38:15 ... non-normative thing, isn't it? Like, I don't think we wanna 14:38:26 ... bring those references into this spec, we would just want to create a common way that any extension can say, look, I fit into this pattern, I am 14:38:29 ... gonna handle paths, and do it in a way that I define, but in a way that the dereferencing algorithm can 14:38:30 order was service, service type, property, document metadata, method specific . missing how you handle query parameters 14:38:36 ... work? That was my understanding. So, I mean, I 14:38:47 ... I agree with what you're saying about having service. We should do all service stuff for all query parameter stuff first and see if we get an object. If we don't and there's a path, we're going to 14:38:52 https://pr-preview.s3.amazonaws.com/LegReq/did-resolution/pull/326.html#dereferencing-algorithm-determine-retrieval-strategy 14:38:57 ... Do some path handling, or maybe what you're saying is we should, even if there's not a path in the URL, I think I could agree with that, we should do some, we should check to see if there are any path handling 14:39:05 ... objects. But then the problem, I think, with that approach is, say, I have… I am just dereferencing a… a DID 14:39:06 q+ 14:39:14 Joe Andrieu: Wait, could you just repeat that last bit, Will?... 14:39:19 Will Abramson: When I want to get the DID document, like, how do I do that if there's a path handling object in there? So, I'm dereferencing a bad deed, right?... 14:39:32 ... And I'm going through this algorithm, but the DID document in this BEDID has some path handling objects. Like, if we go through this algorithm and we target those path handling objects. uh 14:39:37 ... That means that there will be no way to dereference and get back the DID document 14:39:40 ack ottomorac 14:39:42 ... um 14:39:50 ... Maybe that doesn't make sense, but anyway. Also? 14:39:54 Otto Mora: Is it worth just pulling, um… because I really like this here, like, this is... 14:40:11 ... I don't know if it's just me more visual, and then just, like, as we discuss things in my head, I just, like, lose path, because… lose sight of, like, what it is, because I'm just obviously not as familiar with the spec as you guys are, but, like, this has been really helpful, like, even, like, for 14:40:19 ... I think, like, folks on the call tomorrow, to just, like, share the preview of the PR like you're doing here, like 14:40:24 ... way, way more easier to follow, and for people to have an opinion, I feel like, you know, like 14:40:29 ... Would… could we pull… I see that Joe had shared his here, um 14:40:33 ... Uh, his preview link, is it worth pulling it now, just to see 14:40:40 q? 14:40:44 q+ 14:40:48 ... What the difference is that I believe evens oh, yeah. There that one. Is this helping… clarify Steven's… question around. That one part where he wasn't clear on 14:40:49 q+ 14:40:55 ... the aspect of how Joe had thought about the retrieval strategy 14:40:57 ack JoeAndrieu 14:41:00 ... Or maybe, Joe, you could walk us through this. I don't know. Just my two cents 14:41:03 Will Abramson: Yeah, I'll let you go first, Joe... 14:41:09 q? 14:41:12 Joe Andrieu: Sure. Yeah, so the ordering I had put in chat here, I think we've agreed that service type doesn't make sense... 14:41:23 ... And then the one thing that is missing here is how do we handle arbitrary query properties? And so I appreciate that Stephen's trying to figure that out. um 14:41:23 path is also missing 14:41:40 q+ 14:41:46 ... Then you look in the did document for any property that you know that contain that, affects the retrieval strategy. But the the idea was here is if there's a query parameter that is specific to a service do that first because this URL means to invoke that service. um 14:42:00 ... this is going to be property specific, and it is for those properties which have this function. I do not think we have decided that there… I don't know that we have consensus, we might be able to get there, but that if you have defined a property 14:42:24 ... Um, and it did document produced by software before there was a path handling type 14:42:41 ... Um, then we should be able to handle it. Or someone tomorrow comes up with a new property, which is ex… we have this extensibility mechanism, and either we get rid of the extensibility mechanism, or we need to be able to process these future-looking properties that we may not even know about today, or properties that are in use 14:42:45 ... that affects retrieval strategy or handling strategy, then that it must be a path handler, and that there is no other way for you to get your property to be legible to the system. This is a mechanism that if you have a property that is legible to the system, such as linked resource 14:42:47 q- later 14:43:01 ... By any of the deployed 200 plus did methods that we just don't know about. Part of what I'm fighting for is we have these mechanisms for extensibility. I'm trying to make sure that we retain our respect for that extensibility because we built the architecture to not require a centralized registry 14:43:05 ... And so, it's important to me that this sort of extensibility is still supported. Um, if… if you still don't have a… a 14:43:21 ... Uh, handling strategy. I'd call the retrieval strategy in here. Then you look at the document metadata, um, which includes the, the, uh, resolution metadata. And then finally, you fall back to, uh, method specific. So if we haven't already found a, uh 14:43:32 ack manu 14:43:33 ... a handling strategy, then you might hope that maybe the DID method has some way to do it. And if, after all that, you still don't have a way that you know how to retrieve it, then you just return the DID document. That's the essence of that algorithm 14:43:39 Will Abramson: Okay, thanks, Joe. Manu?... 14:43:55 Manu Sporny: Um, uh, yeah, plus one, Joe, that's very helpful. Um, and I do like this, I mean, looking at this algorithm, it's, you know, the order of operations is pretty clear, also plus one to the, we have this, you know, decentralized extensibility mechanism, let's make sure that we... 14:44:20 ... You know, keep that in there. I guess, Stephen, would it be possible to merge this into the algorithm that you have? And if not, where are the problems? Meaning, like, I think Joe already said, like, step two, we're taking out. Right. But with the stuff that's remaining, do you see a place where it, you know, augments or fits in? Uh, to the 14:44:20 algorithm you have 14:44:31 Stephen Curran: So yeah, I don't see them radically different. The two differences now that did meth, you know, one and two got moved down... 14:44:36 ... And and, as I said, I didn't quite know where method specific 14:44:41 ... belong, so I'm good with that. Um, the fallback, I 14:44:50 ... The two differences are property. and document metadata that I don't have in mine, and path that Joe doesn't have in his 14:44:54 ... As, you know, my 14:44:59 q+ 14:45:02 ... I'm trying to get… struggle with property and document metadata is I think of it as an implementer. What's an implementer gonna do? I just 14:45:13 ... rules around that. And it just didn't make sense to me just to say 14:45:18 ... look for properties that might impact things, and especially where 14:45:24 ... And having that before, well, before path handling anyway, where 14:45:30 ... You don't have a way to… you don't know 14:45:48 ... I just don't understand how to process that. So I get it now that there's no trigger for it. You just sort of, oh, there's not like a service parameter that says linked resources as a parameter that triggers the use of that property 14:46:00 ... or the path to trigger that property. It's just… it exists in the DID doc, therefore you use it. That… I struggle with. That… that's the only difference. I'm happy to… if… if 14:46:17 ack Wip 14:46:19 ... If people want this in there, easily, it just goes in, we just pick one. I think property and document metadata can be combined into one, that's fine, or kept as two, doesn't really matter. Um, but I… I really struggle as to what an implementer is going to look at that and go, how do I do that? 14:46:22 Will Abramson: Thanks, Stephen... 14:46:26 ... Yeah, I put myself on the queue to kind of talk about 14:46:44 +1 14:46:48 ... My understanding of when we last discussed this, and it was in two weeks, was, I mean, we were kind of going to encapsulate both of these steps in this new type that we defined. And I think what you're saying, Joe, is we do still want to do that, but we also want to support these sort of legacy systems. But. That might not be using that new 14:46:49 type 14:46:53 ... My sense is that we really do want folks, if they want to extend 14:47:08 ... their DID documents and define new extensions and new ways for doing pass handling. We want them to have a way to signal to any client that they are a pass handling thing and should be taken into account 14:47:21 ... And maybe that is the way that 14:47:24 ... Like, otherwise, what we get is, like, you know, I'm a client, and I understand linked resources, so I… I mean, maybe that's fine, and I know linked resources are a property that handle retrieval, so I'm just going to look in there 14:47:39 ... And they're both targeted. that we address that, and then different clients just understand different properties in the DID document, but I don't think we're going to get interoperability in that way, in that, you know, my client only understands linked resources, and your client only understands some other retrieval strategy 14:47:42 q+ to say 3, 4, 5 are "legacy support" for extensibility mechanisms other than path handling type 14:47:43 ... differently, then they might get different results for the same URL 14:47:52 ... Question mark. Uh, I do think also in here, there is not this concept of using the path. to target specific 14:47:53 q+ 14:48:04 ... Objects. So like this property, let's say there is a linked resource And that linked resource is an array of resources, right? 14:48:15 ... Are you assuming, Joe, that this retrieval strategy is like the linked resource retrieval strategy, which takes in an array of resources, and does the path handling 14:48:21 ... uh, you know, selection in that algorithm. Because for me, we did kind of get to this, this sort of 14:48:35 ... consensus, I thought, that we were going to have this type, and then we were going to collect all of the path handling objects, like including the services, the path services, the linked resources, and any object in the DID document that kind of claims to be path handling, and then apply the same 14:48:42 ... matching algorithm to select which one of those objects is the object that I should. trigger on 14:48:45 ... If, assuming I understand the retrieval strategy 14:48:51 ack manu 14:48:51 ... So that was my understanding, and I can't see the argument for having some legacy 14:48:56 ... Bye. But I think it just makes things more complicated 14:49:08 Manu Sporny: Uh, yes, it makes it more complicated, but it's worth putting in the algorithm, right? So, you know, um… Uh, I think we can say, like... 14:49:28 ... please, please, please, implementers, use the path handling object approach. Like, if you want to do path handling and you want to do some, you know, custom, please just signal to the implementation. You're much more, you know, it's much higher likelihood that 14:49:42 ... We will reach interoperability through that mechanism than implementers implementing potentially random DID extensions at different points in time, right? So please, please, please use path handling object 14:49:47 +1 to suggestion from Manu 14:50:00 ... But for those of you that, for whatever reason, have a good reason not to do that, you can use property and document metadata as well. But we're just warning you that property and document metadata might lead to less interoperability than the path handling thing. So, you know, plus one to merging 14:50:16 ... all of these into, Steven, the algorithm that you have, minus, you know, service type. I think the argument is, you know, legacy support and allowing for, you know, extensibility in ways that we haven't thought about 14:50:32 ack JoeAndrieu 14:50:32 JoeAndrieu, you wanted to say 3, 4, 5 are "legacy support" for extensibility mechanisms other than path handling type 14:50:33 ... But we can nudge people towards, like, please use the path handler object. Like, that is… that is your best path to… to getting, you know, broad-scale interop, um, uh, with your… with your, um… a path handling strategy. That's it 14:50:38 Will Abramson: Okay, great. Thanks. That makes sense. Joe?... 14:50:47 Joe Andrieu: Yeah, plus one to that. 3, 4, and 5 are really about legacy stuff. We know, for example, that IXO has deployed... 14:50:59 ... physical stoves. In fact, they're… it's… it's a significant effort to create carbon, uh, credits, smart contracts, and NFTs, and they're deployed in the field 14:51:17 ... Um, with families in Africa using these devices that are using linked resources in this way. The cost of updating those stoves is probably absolutely not worth it. Um, I don't know particularly if they have a nice update mechanism that's secure, yada yada yada 14:51:32 q+ 14:51:32 ... But my point is, there are people who are not in these meetings who are using these technologies in ways that we don't know how, and I really think we need to continue to support the notions that we had enabled when we first put this through 14:51:45 ... So plus one to the general sense of merging and and trying to sort of add these fallback mechanisms. We do sort of have an open question about how do we handle other, query parameters 14:51:54 ... ah. And I don't have a good solution. I think it's not clear to me what you should do if you have a service parameter that 14:51:57 q+ to speak to "what would implementers do?" 14:52:06 ... is not service, and therefore you don't know to go look for a service property to find the ID for it, and then invoke that service according to the service type 14:52:22 ... So I do think there is a gap here about, like, do we handle query properties, query parameters before we look at properties in the DID document? I think we should for the same reason I like service being handled first. It's explicitly in the DID URL 14:52:30 q- later 14:52:36 ... So, uh, I would imagine that the person who created the DID URL is trying to direct the flow in a way that's hopefully, you know, helpful, as opposed to an attack. Um, but I'm not sure how we fit that into here. I think it's an open question 14:52:38 ack swcurran 14:52:45 Will Abramson: Okay, thanks, Joe. Uh, just knowing the time, I'm gonna close the queue, uh, so we'll just run the queue and hope that's enough. Uh, Steven... 14:52:49 Stephen Curran: Yeah, to get a concrete example of my... 14:52:55 ... concern about property and document metadata as they are here and without rules around what you do. Um 14:53:09 ... Would it not be the case that if you put a linked resource in a DID document, you would never get the DID document back? You could never see it because you would always hit three and four and say, oh, there's a linked 14:53:15 ... resource in here, therefore I return the linked resource, and I never get… oh, there's no way to ever get the DID doc back 14:53:17 Joe Andrieu: May I answer, Will?... 14:53:18 Will Abramson: Yes, go for it... 14:53:21 Joe Andrieu: Um, the... 14:53:32 ... The handling strategy for linked resources includes finding the particular linked resource that matches to the path 14:53:42 ... So if there is not such a math, a match, then that retrieval strategy will say go use return the did document 14:53:48 ... It falls back to when I don't have a match to a specific resource. Uh, go to the document 14:53:53 Stephen Curran: So, this approach works... 14:54:01 ... based on the extension doing the right thing. So that's the rule around it. Okay 14:54:05 ack manu 14:54:05 manu, you wanted to speak to "what would implementers do?" 14:54:07 ... I'll try to figure out… yeah, I'll try to figure out a way to word it 14:54:10 Will Abramson: Okay, thanks. Uh, Manu?... 14:54:27 Manu Sporny: Yeah, I think plus one to that, the algorithm is dependent on these extensions behaving well. And if they behave badly, it'll just break, right? And then people will stop using the extension as kind of, you know, the outcome to that... 14:54:48 ... Stephen, you asked, you know, as an implementer, what would implementers do? That totally resonates with me. But in some of these cases, especially the legacy support cases, or the ones where we're like, you know what, we have no idea what kind of innovation is going to come out of this 14:55:02 ... I think in those cases, we've gotta trust the ecosystem to figure it out, right? So it is going to look vague in the spec. I know that's not like ideal, but we're trying to strike the right balance between being overly prescriptive 14:55:19 ... And allowing there to be enough decentralized innovation where neat things might come out of this. And the downside to that is that things will also break. They'll be not well specified, people will make mistakes in their extensions, um, and uh, and hopefully 14:55:27 ... Uh, the blast radius of that is going to be, um, uh, kind of limited to the extensions and who implements them. Um 14:55:36 ... So, all that to say, I think it's fine for us to be a little vague with property and document metadata, um, in, in, you know, when we're dealing with extensions 14:55:43 ack Wip 14:55:48 ... It's about hitting the right balance between pointing people towards the extensions and then trusting the extensions to do the right thing. That's it 14:56:08 Will Abramson: Yeah, thanks, man. Um, okay, I just want to try and… I mean, first I'll say I'm a little concerned about our timeline, but I just want to try and summarize what I think we kind of got to on this call, because I think it was useful. So, the determining retrieval. Strategy, or whatever the algorithm we called it, is gonna… 14:56:08 really... 14:56:19 ... handle service first. I mean, I still have a question about whether we want to, like, make service, put service on this pedestal, but it's certainly going to handle query parameters that 14:56:30 ... Ah, okay. it understands to be about selecting retrieval strategy, right? Like, each client is going to understand different things, and one of those that all of them should understand is service, so certainly service is different in that sense 14:56:40 ... And it's gonna, you know, use those query parameters to select an object and execute that retrieval strategy, right? And then, after that 14:56:45 ... You know, if it doesn't find an object, it's gonna go into this sort of, like, uh 14:57:00 ... thing that we're trying to define here, like, in that we're saying, you know, ideally you should use this type, and we're… that's the first thing we're going to check for, um, objects with that type 14:57:16 ... And then we're going to use the path to select that object and execute the retrieval strategy. If that fails, we're going to fall back to you're the client, you understand the DID document, however you decide to, and you understand that some properties are relevant for your use case, right? 14:57:31 ... did linked resources, you might understand the did… the linked resource metadata property, and you should handle that. And we're just basically saying, like, these things exist 14:57:41 ... the XO case, they're going to understand linked resource, and they can handle that however they have been programmed to handle that, right? And then, similarly with the document metadata, like, if you are working with linked. If you haven't found something that's using this sort of more standard pattern, you might want to look in these other 14:57:41 places 14:57:51 ... And then failing that, we're going to fall back. So I think that does kind of combine these two together, right? Like, we can see a pathway where it's, like, query parameters first. This sort of standardized path handling object approach. And then these properties 14:58:01 ... We're just saying it's not allowed, I think 14:58:01 Stephen Curran: Yep... 14:58:04 Will Abramson: And we don't really need to say much about these properties, just that, you know, you're an influencer, if you understand these properties, feel free to use them, that's not... 14:58:07 Stephen Curran: I think that sounds good, Will. Good summary... 14:58:10 we should probably also special case versionId and versionTime 14:58:12 Will Abramson: Great. Okay, uh... 14:58:18 ... With that, yeah, I mean, I guess, Steven, you're gonna take another pass, and I appreciate that. We will have another call 14:58:22 Stephen Curran: Happy to pass it on. Happy to pass it on, but I will take pass if otherwise. Yes... 14:58:38 Will Abramson: Yeah, well, we will have a call on this again probably on Wednesday, but I would appreciate folks, like, taking time to review the review and add comments to the PR beforehand. It just helps us get a bit more on the same page in this call. Because we are in a bit of a time crunch, right? Like, we're, like, one and a half months 14:58:38 through our... 14:58:39 Thanks for your service Stephen 14:58:41 Stephen Curran: Wow... 14:58:49 Will Abramson: Six months extension. And the biggest concern for me is we need to get this algorithm done so we can get it reviewed by TAG and then address the TAG... 14:58:51 Stephen Curran: Um, but... 14:58:54 Will Abramson: Yes. Concert in time, right? So that's the time pressure here... 14:59:05 ... Uh 14:59:11 Stephen Curran: Well, sorry. One more thing in in the changes. Do we want to put in the that commentary about the different parameters, and how they might be in different places, be used in different places. I think… Yeah... 14:59:11 Will Abramson: Maybe in this section it goes, though. No problem... 14:59:13 Stephen Curran: Do you want to do a PR about that?... 14:59:16 Will Abramson: Okay... 14:59:22 Stephen Curran: Sorry, I think it should go in the dereferencing algorithm, but higher up... 14:59:26 Will Abramson: Um… okay... 14:59:31 ... Yeah, I'll have a think about it. Yeah, okay, great. Yep 14:59:35 Stephen Curran: Okay, let's talk about that. Yeah, let's offline, let's talk about it. One of us will do a PR. Yeah... 14:59:46 Will Abramson: Yep, perfect. Okay, um, and with that in mind, I'll see you all tomorrow. Hopefully, it's going to be an okay conversation, and then we can move forwards and try and get this whole algorithm complete as soon as possible. Thank you... 14:59:49 Otto Mora: Thank you... 15:00:05 transcriber-bot, pause 15:00:05 scribe- 16:00:21 bigbluehat has joined #did 16:07:44 TallTed has joined #did 18:00:32 ottomorac has joined #did 18:00:42 transcriber-bot has joined #did 18:01:06 zakim, end the meeting 18:01:06 As of this point the attendees have been Wip, KevinDean, manu, swcurran 18:01:08 RRSAgent, please draft minutes 18:01:09 I have made the request to generate https://www.w3.org/2026/06/10-did-minutes.html Zakim 18:01:16 I am happy to have been of service, ottomorac; please remember to excuse RRSAgent. Goodbye 18:01:16 Zakim has left #did