14:46:34 RRSAgent has joined #did 14:46:38 logging to https://www.w3.org/2026/09/03-did-irc 14:46:47 rrsagent, make logs public 14:46:59 Meeting: Decentralized Identifier Working Group 14:47:03 Chair: ottomorac 14:47:11 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Sep/0001.html 14:47:11 clear agenda 14:47:11 agenda+ Agenda Review, Introductions (5 min) 14:47:11 agenda+ Review of Introduction Section to DID URL Deferencing Algorithm (15 min) 14:47:11 agenda+ DID URL Dereferencing algorithm \[1\] (30 min) 14:47:12 agenda+ Next Time (5 min) 14:47:22 previous meeting: https://www.w3.org/2026/08/27-did-minutes.html 14:47:26 next meeting: https://www.w3.org/2026/09/10-did-minutes.html 14:58:47 present+ 14:58:54 transcriber-bot-l has joined #did 14:59:13 present+ 15:01:18 JoeAndrieu has joined #did 15:01:52 JennieM has joined #did 15:03:03 transcriber-bot-l, connect 15:03:05 scribe+ 15:03:09 swcurran has joined #did 15:03:09 Topic: Agenda 15:03:32 Otto Mora: Uh, so for today, we really just have two topics, uh, one of them being the new, uh, uh, review of the new intro section to Data URL Dereferencing that Joe has kindly prepared for us. Uh, so we'll be reviewing that... 15:03:42 ... And then, after that, we would continue the review of the comments on the date URL to referencing algorithm PR for using the presentation that Steven had previously prepared. So we still have 15:04:04 ... couple more sites to go through to review the comments. But beyond that, was there anything else that folks wanted to add to the agenda 15:04:09 danpape has joined #did 15:04:12 Manu Sporny: Sorry, I'm not on, uh, trying to get on hex chat, um... 15:04:17 KevinDean has joined #did 15:04:24 present+ 15:04:25 present+ 15:04:28 ... Do we have an understanding of where Pierre Antoine is on the DID Methods Charter? And TPAC scheduling, and any of that stuff 15:04:33 manu has joined #did 15:04:34 present+ 15:04:40 Otto Mora: Um, I can check that with him. Um, I believe that the three sessions were already scheduled for Tuesday. And if we need an additional one, we can. But not sure about the charter status. Yeah. I can definitely follow up with that, I'll make a note about that. Rooms. Starter... 15:04:43 Manu Sporny: Okay, thanks... 15:04:49 Topic: Review of Introduction Section to DID URL Deferencing Algorithm 15:04:52 Otto Mora: Yeah. Okay, perfect. Alright, anything else? No?... 15:04:54 https://legreq.github.io/did-resolution/#dereferencing-provisional 15:05:01 ... Alright 15:05:01 ... Cool. So yeah, let me just move to this topic 15:05:07 ... Um, then, um, I believe that we would be using this link. Um, I'll also paste it in Zoom, because, uh, there was some preview issues on the 15:05:31 ... on the… PR from the W3C GitHub repo, something to do with the 15:05:34 Joe Andrieu: Alright, can you hear me?... 15:05:46 Otto Mora: the GitHub Actions, I believe, some of the display. So we'll just use the Legendary Requirements link, and I'll yield the floor to Joe to walk us through his changes... 15:05:48 Joe Andrieu: Okay, let me pull up those changes... 15:05:51 Otto Mora: Yep. Mm-hmm... 15:06:15 Joe Andrieu: Okay... 15:06:23 Otto Mora: Uh, yes... 15:06:30 Joe Andrieu: Hopefully y'all can see that... 15:06:39 ... Okay, so, um 15:06:50 ... This is… intended to be a quick write-up to explain why this dereferencing algorithm is here, how it fits into the rest of the specification, and how it should be interpreted by those reading it. So we introduced dereferencing, and specifically, um 15:06:56 ... Start introducing the language about a did URL, and how that means invoking a function that applies it in the current context which will become a handler 15:07:10 ... I mentioned that DIDs allow for a number of distinct handling strategies, because we have ways that DID URLs can refer to resources in a variety of ways 15:07:14 ... And regardless of that strategy, we first do resolution. So I connect it back up to that part of the, copy. We probably should have a link here 15:07:31 ... Um 15:07:41 ... But because the document's out of sync, I didn't… I didn't bother putting all the links in yet. Um, we could do that during cleanup 15:07:58 ... Um, and then I say, the following DID URL D referencing algorithm describes how a conforming client of a conforming DID resolver prepares for, executes, and handles the respawn… the response to a call to resolve 15:08:23 ... And then I do have some normative language, which was one of the things the editors were discussing about whether or not this section should be completely non-normative or not. But I leaned in to the notion that this should be normative because I do feel that conformance clients must execute the steps in this algorithm. Um 15:08:27 ... I described that the only required input is the DID URL itself, the context in which the DID URL is being used, which is implied. But here we're making explicit and any configuration details specifically regarding preferred resolvers and available handlers. Those are the only inputs required and the expected side effect 15:08:39 ... of dereferencing is the invocation of a handler that applies any retrieved resource to the current context. So there isn't an explicit return value because there isn't an explicit function signature, but we are expecting that somewhere in here, this handler that we are discovering gets called. Um, and then we do have the language around 15:08:39 conforming clients must allow DID URL users to set specific resolvers to be used for any specific DID method. This was pulling it out of the 15:08:50 ... Um, outline, so that it didn't seem like you're supposed to do it in the flow every single time, because that would be maddening. Um, and then I realized we had a similar gap with regard to handlers. I used a should language 15:09:09 q? 15:09:10 q+ 15:09:14 ack manu 15:09:14 q+ 15:09:22 Otto Mora: Okay, thank you so much, Joe. Did we have any... 15:09:27 Joe Andrieu: we could discuss whether that should be must, but I say the conforming clients should allow DID URL users to set the handlers to be used for any specific handling strategy. Um, that certainly is my expectation, but, um... 15:09:31 ... Uh, we have not discussed that at all, so just want to put that before the group, and that is the new intro 15:09:34 Otto Mora: Oh, we have no one on the queue, maybe. Manu, yeah, go ahead... 15:09:42 q+ to mention TallTed's suggestions generally look good 15:09:57 Manu Sporny: Yeah, just to say it out loud, I like the intro. It feels fine to me. I am still a little concerned about the normative language, but I mean, we're just going to hit that when we go to test it. We'll see what tests. pop up. I know, Joe, you had a number of ideas on how we could test this... 15:10:06 ... Concretely, um… The… so, plus one, I think this is better than what we have in the spec right now, and any adjustments we can make, you know, um, in future PRs. I'm, um… I'm wondering, I thought, Joe, I thought you were 15:10:21 ... Opposed to specifying dereferencing normatively. That might have just been the, you know, the function signature, you know, part of it. Has your position changed? I probably misunderstood your position 15:10:30 ack swcurran 15:10:32 q+ to mention it is the "dereferencer" as something other than a client that I am opposed to 15:10:36 Otto Mora: Okay, thank you. Okay, I'll let Stephen go next... 15:10:44 Manu Sporny: Um, I still didn't really want to make didURL different, dereferencing normative, um, but I'm happy to go with whatever the consensus in the group is. That's it... 15:10:48 Otto Mora: Sure, Joe, do you wanna... 15:10:51 Joe Andrieu: Sure. Um... 15:10:59 Stephen Curran: Did Joe want to respond to Amanda's question there first?... 15:11:19 Joe Andrieu: So I'll go ahead and also make the other comment, which is that Tel Ted has already made a bunch of editorial suggestions. Mostly they look good. I just didn't get through hitting resolve and accept on all of them. So those all I didn't see anything controversial in what he was proposing... 15:11:36 ... Um, and then… what I… what I'm opposed to, to clarify for Manu, is defining a dereferencer that is something other than a client. I very much think we do need to describe the dereferencing algorithm 15:11:37 Manu Sporny: It does, thanks... 15:11:37 Joe Andrieu: I do not think we should define a dereference error as anything other than the client to resolve... 15:11:39 Otto Mora: Okay, great. Uh, Steven?... 15:11:39 ack JoeAndrieu 15:11:39 JoeAndrieu, you wanted to mention TallTed's suggestions generally look good and to mention it is the "dereferencer" as something other than a client that I am opposed to 15:11:42 Joe Andrieu: So, hopefully that helps a little bit, Manny... 15:11:47 Stephen Curran: Yeah, so thanks, um, for doing that, Joe. Um, I'm... 15:12:04 ... okay with this. My reaction to it at 1st was, this doesn't get across the point that I wanted. I really reread it and reread it, and it's there. But I find you really have to read the tea leaves 15:12:08 ... In that, and the subtle use of words to get the point 15:12:23 ... Um, so… while I do think it would be okay to merge, and… Um 15:12:26 q+ 15:12:27 ... Perhaps it's good 15:12:38 ... I don't think it is, but maybe other spec writers that have experience with this might think it's good to be that vague. I I do find it too vague. So I did a separate pass, and I put a comment in with a link to a a Google Doc. That is a rewrite of this. Um 15:12:58 ... trying to… based on this, but much more explicit about saying, this is about a resolution client, and this is explicitly not about a… Um, I did… URL library. Um, I did 15:13:05 comment Stephen is mentioning: https://github.com/w3c/did-resolution/pull/344#discussion_r3918482746 15:13:12 ... put in language that say parts, and and I use not just context as a word. That's to me very vague versus 15:13:40 ... aware of the business, the business purpose of the dereferencing I did put in that. It's it's. possible that a 15:13:50 ... Uh, a library 15:13:51 q? 15:13:57 ... Could cover part of this, but, um, that is not business aware, but could cover part of this, so that 15:14:02 ... allows for understanding that, hey, part of this is… could be done as a library, but definitely not all of it, because it… it doesn't lend itself, as Joe said, to a… a specific result, so I 15:14:05 ... You know, if you want to 15:14:12 ack manu 15:14:14 Otto Mora: Mm-hmm... 15:14:17 Stephen Curran: Not... 15:14:22 ... do anything with that. I… that was my reaction to it, was it's just… it is… it is complete, but it… I found it to be very vague, and, um, really not getting that message across that I was hoping, which is to say, this is a resolution client. That's it 15:14:30 Otto Mora: Okay, uh, thank you, Steven. I see Mano. Thank you... 15:14:41 Manu Sporny: Yeah, this is mostly a comment on Stephen's vagueness comment. It is okay to be vague in a specification, and sometimes it's preferable if the group can't agree on the exact wording or the exact point... 15:14:57 q+ 15:15:11 ... you know, that they're… that they're trying to highlight. Um, the only point that vagueness is not okay is when it will lead to interoperability failures. I 15:15:15 ... don't see how being vague… or I don't see how the… the thing that's written right here will lead to interoperability failures. If that happens, if we, you know, go with what's here, and it's vague, and people misunderstand it, we can always revise in the 1-1 15:15:18 ack swcurran 15:15:22 ... to remove the vagueness that led to the interoperability failure. But I think… I don't know, Stephen, if making that clarification would make somebody implement this in a wildly different way, uh, that would… that was not interoperable 15:15:24 Otto Mora: Uh, Steven?... 15:15:27 Stephen Curran: Yeah, my worry about vagueness here is that... 15:15:37 Manu Sporny: is my take... 15:15:41 Stephen Curran: without really getting the con… the… context, I hate to use that word again… uh, the context in the specification of how the algorithm is supposed to be used, people will simply implement a… a... 15:15:56 ... Uh, a dereferencing service 15:15:59 ... and, um, go from there, and then try to figure… they won't be able to understand the algorithm, because it doesn't have enough information in it to… to do that. And 15:16:00 q+ 15:16:01 q+ to point to the two diagrams and detailed language 15:16:09 Manu Sporny: That's it. Thank you... 15:16:12 Stephen Curran: you know, for good reason, but without having that context, it would become difficult to implement, and you would get interoperability and implementation problems. You'd turn off... 15:16:15 ... implementers, or you would get interoperability problems because they would each interpret how to accomplish it 15:16:17 Otto Mora: Mm-hmm... 15:16:17 ack manu 15:16:18 Stephen Curran: That's it... 15:16:21 Otto Mora: Uh, okay. Romano again, go ahead... 15:16:47 Manu Sporny: Yeah, I don't know, Steven, if I agree. I think there's a lot of detail here that an implementer can look to. And it may be that we don't want to be that explicit in the first go around. There may be some innovative ways of doing this that we don't want to cut off... 15:16:49 q+ 15:16:54 ... And, you know, if people read this and they have a hard time, you know, implementing it, I'm sure we're gonna hear about it, right? I mean, that's what Candidate Rec is for. I would rather be 15:17:05 Stephen Curran: Okay... 15:17:08 Manu Sporny: a little more vague in this section at this point than, you know, too specific. So, like, if somebody goes off and they implement a resolution, you know, service, or dereferencing service... 15:17:24 ... let them do it, right? Like, that might be an interesting thing to see. I know, you know, Marcus has done it, and he feels that there's a lot of value there. I know that Digital Bazaar does not want to do that. We see nothing but, you know, distributed denial of service attacks against that thing. Um 15:17:30 ... But, you know, I don't think we should try and constrain the market too much at this point. I think we should kind of 15:17:44 ... see what happens, and then use that for a revision. Um, there's only so much guessing, I think, uh, Steven, we can do, you know, um, on how people are gonna use this to implement 15:17:49 q- 15:17:58 ... Another good test is to point a LLM at it and see if it can do an implementation based on the language and see where it gets tripped up, right? I mean, that's a fairly easy first pass to see if we've got enough in here 15:18:19 ... All this to say, I think this is better than what we have in the spec today, and I think we'd be in pretty good shape if we merged it in any modifications to it, we could make further down the line. I guess I don't want us to keep 15:18:19 ack JoeAndrieu 15:18:19 JoeAndrieu, you wanted to point to the two diagrams and detailed language 15:18:19 Otto Mora: Mm-hmm... 15:18:20 Manu Sporny: you know, putting off a merge on at least the text that we're looking at on the screen right now. That's it... 15:18:23 Otto Mora: Thanks, Jeff... 15:18:30 ... Uh, thanks, Valerie. Go ahead, Joe, sorry 15:18:36 ... No? You're on mute 15:18:48 Joe Andrieu: Sorry The screen sharing interface moved all the mute buttons... 15:18:53 Otto Mora: Go ahead... 15:18:58 q+ 15:19:02 Joe Andrieu: I wanna push back that this is vague, Steven. I think there's two diagrams here and a whole another step by step prose description of what's happening. I don't I don't think it's vague. I think it's flexible... 15:19:15 ... That is a design criteria because we are trying to find a way to be backwards compatible with all the different ways that different people use different things. to define dereferencing. Um, but… And this is the intro text 15:19:31 ... like, the intro text, which actually I don't think is vague at all. In fact, I wish this were less words, but I couldn't find a way to get it to be less words and actually cover the kinds of things that people had mentioned. So, this is an intro to a section that has very detailed steps 15:19:43 ack swcurran 15:19:44 ... So, I think it's fairly complete. Um, I don't know if throwing it in an LLM is the right answer, but… Um, I think, especially with the accompanying diagram and algorithmic description, I'm… I'm struggling to say how you could call it vague 15:19:48 Otto Mora: Steven?... 15:20:00 Stephen Curran: Uh, to be clear, I think the introduction is vague, and the introduction is crucial to understanding the detail that follows. That's what I'm saying, is vague... 15:20:08 ... it… it doesn't convey the point that I was hoping the introduction would do, but that's fine if I… you know, I'm not gonna 15:20:21 ... object or anything to it. I did write a an update based on that. And if you want to use that or take a look at it, that's fine. If you don't, that's fine as well 15:20:28 ... Um 15:20:34 ... I also had originally put my name, gone on the queue, and then forgot what I was gonna ask, but I realized what it was. I wondered about the intention of 15:20:43 ... The group… is… is the intention to merge 344 and then… and then do another PR to remove? 15:20:46 q+ 15:20:47 ... Uh, Section 5. I had assumed that all along, but um 15:21:03 ... I just wanted to make sure I understand the intention of the group and what others think about that. I had assumed that, but it's just, I've had that come up in questions a few times and wanted to raise that to ask 15:21:04 ack JoeAndrieu 15:21:06 Otto Mora: Mm-hmm. Go ahead, Joe... 15:21:22 Joe Andrieu: Yeah, it's a good question to check in with the group about. There had been two previous omnibus updates that addressed multiple sections, and this 344 was specifically just replace the dereferencing in context... 15:21:31 q+ 15:21:34 +1, agree on that path forward -- do the big thing, and then clean up afterwards 15:21:34 ... Um, so we will have to go through and update links, uh, update any other, uh, language that may disagree with the new approach, etc. So there is going to need to be another round of edits after 344 is submerged 15:21:35 ack ottomorac 15:21:59 Otto Mora: Uh, yeah, I also pulled myself just to, uh, restate that, yes, like, I… the goal now being to just… exactly, let's go through all the comments on 344, get it merged in with the intro section, and then anything else that needs to be, I guess, further detailed, or… or commented on, or, like, refined. We can do another PRs, but yeah, 15:21:59 like, at this point, let's try to get this one merged... 15:21:59 q? 15:22:10 ... Okay, so I don't see any other comments on 15:22:26 Topic: DID URL Dereferencing algorithm 15:22:30 Joe Andrieu: Sounds good... 15:22:33 Otto Mora: people on the queue, and I believe we already addressed Ted's suggestions. There's no issues with those, so... 15:22:33 https://docs.google.com/presentation/d/11fdtIGQ8iB1w13VqGVsaFE0IaBqYhWozjP9NUxdUiOA/edit?slide=id.g3f9aefff577_0_107#slide=id.g3f9aefff577_0_107 15:22:41 ... If it's OK, we can move on to the next topic. Okay. did the URL dereferencing algorithm. And here is the link to the presentation 15:22:44 ... Uh, do we want to do the same thing where Steven goes ahead? Yeah, there we go, perfect 15:22:48 Stephen Curran: Yep... 15:22:52 Otto Mora: So, I think I… I had it on your… on your same exact slide, uh, but... 15:22:55 Stephen Curran: Let me see... 15:23:00 Otto Mora: I think I saw you resolved on a few of them. So let's go to the last one... 15:23:05 Stephen Curran: Yeah, um, yeah, I was just jumping through, um, select the resolver, remove any fragment, I think we've gone through that... 15:23:20 ... So I've got resolved on a lot of these, so I think here's where we were… well, um 15:23:37 ... Yeah, um, so I think this is where we were. Um, I updated this slide after our last discussion. Um 15:23:41 ... Joe, you've talked a few times about the client should not blindly pass on version time, um 15:23:51 ... I… but I don't think it's ever stated in there, and 15:23:58 ... and does something need to be added to the spec to be able to say stuff like that? Like, I find it that if… I were writing it, if I got a DID URL 15:24:16 ... Um, with a version time, I would… I would hope it would be processed, but again, that comes back to the resolution client. If… if I don't have a… If if it's generic, you're right. The version time would be 15:24:22 ... Determined by the business logic of it, you know, based on what time the thing was signed, or something like that 15:24:29 ... Um, you're… I think you're assuming the 15:24:38 ... The URL writer is the person who writes, for example, the verifiable credential, for example, and my 15:24:44 q+ to say versionTime is an option to Resolve and should be discussed there. 15:24:49 ... and might do something to the version… to the URL, and it shouldn't be blindly processed. I think that's your thinking on that, but I'm wondering if that needs to be stated 15:24:52 Joe Andrieu: Um... 15:24:53 ack Joe 15:24:53 JoeAndrieu, you wanted to say versionTime is an option to Resolve and should be discussed there. 15:24:55 Otto Mora: Go ahead, John... 15:25:07 Joe Andrieu: Does it need to be stated? Maybe we should have it stated. The... 15:25:12 ... Uh, my… sort of… I guess my top level take on it is that this is about a resolution option 15:25:15 ... And it's the section on resolution that should explain when and why 15:25:19 ... Um, a caller to resolve would use version time 15:25:38 ... And so, if the caller to resolve understands what version time is, then they will know whether or not to pull it out of the query parameters, um, or to apply their own version of version time because their business case, uh, requires that 15:25:51 ... We did, I thought, to support some change in language here, Steven, I thought we talked about this step. 4 under 611. Uh, in this conversation with your slides. So I thought we had wanted some language there 15:25:58 ... I think it's the same itch that you're scratching, so I feel like we've… I've got a little bit of deja vu about trying to 15:26:01 ... that did resolution options language there 15:26:07 Stephen Curran: Okay... 15:26:10 Joe Andrieu: specifically to reference what you're talking about. So I'm… I would be comfortable adding a sentence or so to that. Um... 15:26:13 Stephen Curran: Yeah... 15:26:27 ... Yeah 15:26:32 Joe Andrieu: I don't think it violates anything about what's going on. It just, and it's not a big burden to say within that section, you know, go figure out the options. This may include parsing query parameters and treating them as options or something like that. Um... 15:26:42 Stephen Curran: Yeah, I realize, as you're speaking, that this… this is in… it's not associated with 613. This is tied to the… What you construct and pass to resolve... 15:27:01 ... Um, yeah. Okay, so this is where we got into confusion, and I got 15:27:05 ... Uh, confused about where the term round robin… it… it 15:27:09 ... Round robin is used, so I think 15:27:19 ... This is the 1-4 step 15:27:26 ... process. Let me jump to the section and show that. Um… And 15:27:32 ... And there's example leans into that there's an array of endpoints. And, um 15:27:46 ... you know, obviously, if there's just one endpoint, you try to resolve it. If there's multiple endpoints, could you explain what you expect 15:27:49 q+ 15:27:54 ... to happen, and what you're implying should happen. For example, should or must they point to the same resource? Are they assumed to be equivalents? Um 15:27:58 ... If so, you're assuming, you know, go ahead. Actually, I'll just stop there 15:28:00 ack Joe 15:28:15 Joe Andrieu: Yeah, well, that was an interesting question that… so let me also address that before you go back. I do think the trick here is making sure that they refer to the same resource... 15:28:28 ... Um, some of my concerns with different versions of this algorithm were that we were bundling together, um, potentially different namespaces from the DID documents, and in that use case, you wouldn't necessarily expect them to be the same resource 15:28:33 ... Because you might have multiple file service endpoints specified in your DID document 15:28:40 ... So 15:28:47 ... The… my expectation is that this is like DNS. Which is that when the, dereferencer gets the DID document 15:28:57 ... When the client of resolution gets a DID document back from resolution, they're going to look at this set of potential endpoints and they're going to pick one. Um, and, uh, execute it 15:29:05 ... If it fails, whether or not they exhaustively search all of them is a business 15:29:09 ... Uh, decision by the client 15:29:31 ... It is not how DNS works, by the way. The DNS round robin doesn't necessarily exhaustively go through because the client doesn't even know that it's exhaustive. The DNS is itself just providing one IP address back, so you don't know how many IP addresses there might be in the pool. And so in a similar way, I tried to describe that algorithm 15:29:42 ... Where when I'm evaluating the handling strategy to understand how I go and get a resource, I want to go through this sample set in a reasonable way 15:29:44 q? 15:29:46 ... And describing this around Robin was my attempt to do that 15:29:51 ... Certainly, maybe the language could be clearer. Um, but one of the things you're, um 15:30:01 ... question suggested was that the client, should potentially should, go through all of the endpoints in the set 15:30:22 ... And I think that's probably a step too far. But we as a group could talk about which of these possible interpretations are legitimate. I don't have a skin in fight, just a place where I started 15:30:24 Stephen Curran: Yeah, you've got this line in there. In other words, if multiple endpoints are available, only raise if all endpoints fail. So you actually have that in there that you should try all of them. Is that what you mean?... 15:30:27 Joe Andrieu: Oh, yeah... 15:30:32 ... I actually… I'm not sure we should have that 15:30:36 Stephen Curran: Okay. And that's also where this... 15:30:47 ... step one is just picking one of them, and step four is where you resolve it, but that's what confused me about… I thought it was all in step one, because this line says 15:30:57 ... keep trying them, except you don't try them until down here from my later interpretation of your comments. So that's was confusing. So 15:31:01 ... Um, I… so yeah, I think it might be the suggestions I have, which is 15:31:17 ... Do we assume that if there's multiple, they represent the same resource, just multiple places to get the same resource, and then what do we do with this comment, this line, which is, how do you decide whether it's a fail or a 15:31:26 ... Or keep trying. So that's clarification that could go there as… in whatever way you want 15:31:30 Joe Andrieu: Yeah, I'm curious from the from the group if anyone has opinion about... 15:31:32 q+ 15:31:33 ... Should we say you should check all of them? 15:31:38 Stephen Curran: Okay... 15:31:44 Joe Andrieu: Um, which is the current pros, which is not what I thought it was. I really could go either way, but whatever the sense of the group is, we should use that... 15:31:45 ack manu 15:31:49 Otto Mora: Okay, uh, C. Mano, thank you... 15:32:22 q+ 15:32:28 Manu Sporny: Um, it feels like if someone… Uh, lists three things there. that you should. try all of them. I'm trying to think of like, you know, how would somebody use this thing? And then I'm thinking, well, it might very much depend on. the service type, which I don't see a service type in here. Is that a… did we leave that out on purpose? 15:32:28 That's a little concerning to me. Is that ID supposed to be type?... 15:32:33 ... um 15:32:40 ... So it does feel like, you know, if you list multiple service endpoints, you should be attempting, you know, um 15:32:46 ... You should be attempting all of them. Yeah, this really feels like it depends on type 15:32:49 ack Joe 15:32:51 ... Thoughts here? Yeah, I'm a bit thrown off by the example 15:32:54 Otto Mora: Joe?... 15:33:13 Joe Andrieu: Um, yeah, we could tie it to type. Um, this particular example doesn't have a type value. Um, it gets absorbed under that ellipsis that's pulling a lot of heavy work. Um... 15:33:17 ... I think checking all of them before an error is not a bad strategy 15:33:24 q+ 15:33:26 ... Uh, but the reason this may not be type-specific is that the service endpoint allows multiples. And so it seems like 15:33:35 ack manu 15:33:36 ... Um, we should have a general rule for that. Um, we could push it into the types, but then each type would have to specify the same thing 15:33:40 ... Um… So… I don't know which of those might be preferable 15:33:45 Otto Mora: I know... 15:33:49 q+ KevinDean 15:33:56 Manu Sporny: it feels like if somebody is going to list multiple service endpoints, they're doing it for redundancy, um, meaning, like, you know, it's a load balancing redundancy thing, and each… and I would expect all of… they… they expect... 15:34:14 Joe Andrieu: Oh... 15:34:18 Manu Sporny: that resource to be available through each one. So as a general rule, if we don't look at type, we could say you have to try all of them. And then we can say unless they're the type overrides this rule. So there's always a general like, you know, without, you know, with it. Yeah, so you… Go ahead... 15:34:22 Joe Andrieu: Sorry. Sorry, let me jump in, Manu. I forgot. This is the default service handler... 15:34:28 ... For when there is no type 15:34:35 Manu Sporny: Yeah, okay, yeah, then it should check all of them. I think... 15:34:38 Joe Andrieu: Yeah, fair enough. We do have if it's typed, like that's the type specifies the handler strategy. So I think that loop hopefully is well represented in the pros. And then this was... 15:34:44 ... If we bump into a service endpoint that doesn't have it because it's legacy, then here's what you should try to do 15:34:49 Otto Mora: Okay, Kevin is in the queue... 15:34:50 ack KevinDean 15:34:52 Joe Andrieu: Sorry... 15:35:08 Kevin Dean: Yes, just a correction to something Joe said about DNS. If you do a DNS lookup on a name that has multiple IP addresses, you will get multiple IP addresses back. It is then incumbent upon the client... 15:35:16 q? 15:35:23 q+ 15:35:32 ack manu 15:35:34 ... to, uh, figure out how to deal with them, you know, in the event that one of them isn't accessible, it'll go to the next. But DNS itself will respond, saying, here's everything I've got, here's all the addresses, you deal with it 15:35:37 Stephen Curran: Okay... 15:35:40 Otto Mora: Uh, yeah, before that, Emmanuel was on the queue... 15:35:49 Manu Sporny: The, um… I'm building off of what Kevin just said. These are… these are… this is an algorithm that the client, um, the resolution client's executing, is that right?... 15:36:04 ... So, the way to interpret, Kevin, what you just said is, we are writing rules for the client, and we're telling the client, like, if you don't have a type, check all of them, is that… Correct 15:36:14 Kevin Dean: Yeah. Yeah, if your browser can't access address number one in the list, it'll then go to address number two. That's how the client B is expected to behave... 15:36:20 q? 15:36:22 q+ to mention ordering 15:36:23 ... So, if we've got multiple… Uh, uh, your URLs that match the 15:36:29 ... Service handling requirements for the client, the client 15:36:36 ... It should start with the first or start with what it thinks is the first and then fall back to the next and the next and the next if they're not available 15:36:40 ack Joe 15:36:40 JoeAndrieu, you wanted to mention ordering 15:36:45 Otto Mora: Okay, I see Joe. Go ahead... 15:36:52 Joe Andrieu: Yeah, the, um… so thanks for that clarification, uh, Kevin. The, um... 15:37:04 ... What I am seeing from Google's omniscient Gemini AI assisted response is that one of the things DNS does that we can't do 15:37:16 ... um, or that I think we shouldn't do, is vary the order of the response. So, um, I didn't think you got all of them, but Kevin's correct. Um, all the IP addresses come back, but the order gets cycled 15:37:25 ... Um, and we don't have that, so we just need to make sure that the language makes it clear that you should pick one 15:37:27 q+ 15:37:31 ack manu 15:37:34 ... Um, and not treat them as ordered, but then make sure you go through all of them. And I don't know that we have the pick one randomly. Uh, and the text 15:37:40 Otto Mora: Okay, Banu?... 15:37:46 Manu Sporny: Yeah, and, uh, plus one to that, and to… and that… that's aligned with the JSON-LD, you know, expression of this, which is it's a set, it's unord... 15:37:51 ... So he shouldn't presume order 15:38:02 Joe Andrieu: Yeah, and I wouldn't want the resolver trying to keep track of that... 15:38:10 q+ KevinDean 15:38:14 ... Although that's how DNS does it. Um, we just haven't talked about that kind of dynamic… Functionality, um… anywhere else yet 15:38:16 ack KevinDean 15:38:19 Otto Mora: Okay, Kevin... 15:38:24 That's what I meant by my early comment on this about why round-robin 15:38:37 Kevin Dean: Yeah, we should also remember that programmers are lazy. Speaking as a programmer myself, I definitely am. And they're not necessarily going to read the spec to see anything that says you should pick one at random. The lazy implementation is to go through the list from top to bottom... 15:38:49 ... And we should expect that would be the most common implementation. So it is really up to the… No. service handlers, uh, up to the… up to the DID 15:38:55 ... To make sure that the document hasn't been in order where, you know, the 15:38:59 ... The one at the top is the one that can handle the most requests. If you've got others, they may be backups 15:39:02 q? 15:39:03 ... We should not expect that the load will be evenly distributed 15:39:20 ... We can provide a shut-in. The DNS randomization is a nice feature of DNS, and it puts the onus, it takes the onus away from the DNS. Programmer to do randomization 15:39:25 q? 15:39:28 ... And it's a nice feature, but we can't do that in the DID document without messing up the hash 15:39:40 ... The best thing we can do is they should choose one at random 15:39:48 ... And then cycle through if that fails until they're exhausted 15:39:50 q+ 15:39:54 ack swcurran 15:39:58 Otto Mora: Steven... 15:40:11 Stephen Curran: Uh, quick question, just to confirm, Manny, that what I stated, uh, in this result, JSON-LD says that if you have it in square braces, that's a set and not… not… and unordered. Okay... 15:40:18 ... Okay. Hmm. Okay 15:40:20 Manu Sporny: That is correct. Yeah, you can explicitly state that the… that order matters, but I don't think we do that for service description, or for the service thing. I'm looking that up right now, but I'm pretty sure that's correct... 15:40:23 Stephen Curran: Mild... 15:40:30 ... Okay 15:40:33 Otto Mora: Okay... 15:40:40 Manu Sporny: Yeah, just confirmed it's unordered. Service endpoint is an unordered set... 15:40:46 Stephen Curran: Um... 15:40:49 ... This one 15:40:53 ... Uh, I think the two rationales on this one 15:40:57 ... is, um, Joe provides 15:41:03 ... Uh, steps on how to append a path 15:41:10 ... To the path of a service endpoint to get a resource path 15:41:17 ... Um, previous uses, whenever we combine. Um, a 15:41:21 ... a, uh 15:41:25 ... You know, uh… a base URL 15:41:34 ... with a relative is to use RFC 398652. Um 15:41:52 ... I'd be… in looking at this further, I mean, we've had lots of discussions on this, because this is strictly to do with PATH. and has nothing to do with fragments or parameters. Um 15:41:58 ... It seems to me it 15:41:58 s/This one/Section 6.1.7 #2\/3: Path Handling Avoiding RFC3986\/WHATWG URL/ 15:42:03 ... I would be intrigued to know the difference between Joe's algorithm and what 15:42:09 ... RFC 3986 would provide. Um 15:42:17 ... I… I'd much prefer that we would stick with, um 15:42:23 ... the libraries that people are likely to use, but, you know, I'm 15:42:25 q+ 15:42:28 ... Not gonna go further on that. Um, first of all, I need… is anyone on the queue for this one? 15:42:32 Otto Mora: No, not at the moment. Oh, Joe is now... 15:42:33 ack Joe 15:42:37 Joe Andrieu: Sure. Yeah, I just jumped on. I was letting you get out your opening bit... 15:42:42 Stephen Curran: Awesome... 15:42:56 Joe Andrieu: So there are two things that are happening with 3986 that I think are problematic, which is why I shifted to a simpler path-based expansion rather than a URL-based expansion. And I do think there are lots of libraries out there that handle path expansion... 15:43:15 ... And so, as long as we don't treat this as a, as a URL, as specifically as a relative ref, then, I think there there are lots of libraries that can do what people need it to do. The, the, the two problems that happen are one is, is the 15:43:19 ... The point of control of the con of the context that you're in. And a web page when you come across a relative ref 15:43:34 ... um, it's understood that the author of that HTML page arranged the code in such a way that that URL would show up in that page 15:43:47 ... There could be Javascript involved. It could be dynamic. It could be based on an Ajax. But the understood security model is that the HTML that's running in the browser that has the URL was the URL was written by the same party or controlled by the same party that wrote the HTML 15:44:05 ... And as such, the relative ref function was intended to allow the writer of that HTML to refer to any resource that might be in the domain that is the base for that HTML. In fact, you can go all the way to the root of the domain 15:44:11 ... And basically replace everything except for the authority part in the URL. So you can rewrite the path, you can rewrite the fragment, you can rewrite the query part. And so 15:44:17 ... Because we have a separation of the the authority for the place in which the did shows up 15:44:21 ... And the authority in which the, service endpoint shows up which is in the the document 15:44:36 ... Um, we no longer have a unified security context, so that the person who is, uh, defining the URL can understand and control what's happening in the DID document 15:44:45 ... So I think the ability for anyone writing a DID URL to change all of the parameters or all of the parts, rather than letting them simply append a path 15:45:01 ... Which lets us address this file server use case. It doesn't let them, like, go to the root of that file system, um, it doesn't let them perhaps masquerade as another user by, uh, putting in a query parameter that would shift the user, things of that nature 15:45:04 q? 15:45:07 ... Um, and… Uh, so that's context control 15:45:11 ... Um, and the complete rewrite. Those are my two concerns with just blindly using 3986. We are not, in fact 15:45:14 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Mmhm... 15:45:21 Joe Andrieu: using the relative ref in the way that it is in HTML. We are using that in JSON. When we refer to, like, a key, and we just want to have hashtag key... 15:45:28 ... You know, when we're in the DID document itself. The context of that document does allow relative refs 15:45:33 ... Um, to be used, we don't have to change anything, it's part of the media property, we get it for free 15:45:47 q+ 15:45:51 ... Um, but using the relative ref algorithm outside the context in which it was created, I think is pulling in a whole bunch of heavy lifting, um, that, frankly, I don't think is a good idea for us to expose to end users 15:45:57 ack manu 15:45:57 Otto Mora: Okay... 15:46:03 ... So whilst Stephen is looking that up, Manu has also his hand raised 15:46:21 Manu Sporny: Yeah, those are, that was a very interesting insight, Joe, about, you know, the way that a relative ref is used in a webpage is not the same way we're kind of using it here in all cases... 15:46:27 ... Uh, and, uh, and, and it resonated with me. The point resonated, uh, with me definitely. Um 15:46:29 s/TallTed \/\/ Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Mmhm...// 15:46:36 ... The only thing I'm concerned about is TAG coming back and saying, why aren't you using, you know 15:46:41 ... path normalization rules that are used in, um 15:46:50 q+ 15:47:03 ... that are defined in what WG and that sort of thing. And if that's our answer, I think that's a good answer. But I'm concerned I don't know enough of the details that maybe are in your head, Stephen, about what the concern is. Um, here is, um 15:47:14 ... So, so for example, the, you know, the, are we saying anything about dots or, uh, in the path or percent decoding? I think the answer is no, we're not on purpose, because it's something else that needs to do 15:47:26 ... path normalization. It's not this algorithm that does it, and we are expecting… and Joe, I don't know if this is true, but we're expecting, if a developer wants to do that, they're going to run the WhatWG 15:47:36