14:54:11 RRSAgent has joined #did 14:54:15 logging to https://www.w3.org/2026/05/07-did-irc 14:54:23 rrsagent, make logs public 14:54:50 Meeting: Decentralized Identifier Working Group 14:54:54 Chair: ottomorac 14:55:07 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026May/0003.html 14:55:07 clear agenda 14:55:07 agenda+ Agenda Review, Introductions (5 min) 14:55:07 agenda+ Special topic call summary (10 min) 14:55:07 agenda+ Dereferencing algorithm - High Level \[1\] (40 min) 14:55:07 agenda+ Next time: Getting to details 14:55:30 previous meeting: https://www.w3.org/2026/05/06-did-minutes.html 14:55:35 next meeting: https://www.w3.org/2026/05/14-did-minutes.html 15:01:25 Wip has joined #did 15:01:31 present+ 15:02:12 JoeAndrieu has joined #did 15:02:18 TallTed has joined #did 15:05:11 zakim, next item 15:05:11 agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot] 15:05:21 transcriber-bot, resume 15:05:21 scribe+ 15:05:24 swcurran has joined #did 15:05:30 present+ 15:05:31 Otto Mora: Okay, um, great. So... 15:05:34 ... Uh, we have a few topics today, um 15:05:42 ... We want to do a proposal from conversations that we had 15:05:45 ... Yesterday, at a special topic 15:05:49 present+ 15:05:53 ... Uh, meeting. We'll also do just a brief summary of the conversations. That we had the week before 15:05:56 ... And just, kind of, generally 15:06:03 ... Uh, yeah, present, like, the current status, and then… Then based on that, we can run to the proposal, and then 15:06:11 ... We want to talk generally about the referencing algorithm at a high level, and then I think Will will be helping us with that 15:06:18 q? 15:06:18 ... But, uh, that's the general gist of today. Anybody have any inputs? Or 15:06:22 ... Jump into that 15:06:38 ... Okay. So, um… Let me just, uh, I guess… I think… summary of… Special 15:06:41 Topic: Summary of Special Topic Call and Previous 15:06:44 ... Now, revisit 15:06:54 ... So, okay, so first off, the previous call of last week. was, um… Sort of, uh 15:06:58 ... Conversation around the refactoring of the dereferencing function 15:07:03 ... And its signature, um 15:07:07 ... We debated around that, and a significant portion of that was, uh 15:07:12 ... how to do that, and how to do path processing, how all of that would fit. Um 15:07:19 ... Steven Curran had submitted a detailed proposal for that, and we discussed that, and then also Joe had provided some inputs 15:07:24 ... And then we sort of landed on, hey, let's not create, like 15:07:29 ... really big PRs, like, really complex PRs, because it makes it kind of harder to 15:07:35 ... Uh, process those, and so let's start with, like, smaller chunks, more 15:07:39 ... Uh, concrete proposals that we can get through 15:07:43 ... And then yesterday, um 15:07:49 ... We spent some more time talking about that, and the need to start moving things, and uh 15:07:56 ... You know, we do need somebody to be more concretely taking on the editing role 15:08:05 ... And so with that, I think we… we're sort of, uh, considering, um, nominating two co-editors 15:08:10 ... Uh, namely Joe and Steven, uh, have, uh 15:08:15 ... Gracefully decided to volunteer, uh, their effort into this 15:08:22 ... And so, this will be kind of, uh, a way in which we can start to get some more progress 15:08:28 ... So, that's, uh, generally the idea here, uh, to nominate 15:08:31 ... Both Joe and, uh 15:08:35 ... even as co-editors of the DID resolution spec 15:08:40 ... And, uh, then we can start to get some more progress 15:08:44 ... And afterwards, then we talked about the 15:08:48 q+ 15:08:50 dmitriz has joined #did 15:08:52 ... dereferencing function signature, how we can maybe think about replacing that. Uh, Joe had voiced some concerns that 15:08:56 present+ 15:08:57 ... Maybe we shouldn't be forcing specific outputs, uh, and then Manu just worried that 15:09:02 ... You know, we also need return values, and that might degrade. Interrupt. Um 15:09:08 ... And then, uh, we just landed on… on Will, kind of helping us out with the high-level refactor, but 15:09:17 ... Well, keep me honest here, did I miss anything around, uh… Yesterday's call is not a fair 15:09:26 Will Abramson: No, that's great. I just wanted to sort of add, I think there was consensus yesterday that we are going to remove the dereferencing function signature... 15:09:34 ... We're going to remove the text that says you must implement this function signature, and we are going to have an algorithm 15:09:42 ... that has inputs and outputs, and those outputs will be optional. I feel like that's what we landed on, so we obviously have to execute that, but 15:09:52 ... Um, that's what we got. And then also Joe had some good context from his discussion with Marcus in IRW 15:09:56 ... Around the compromise around that, where we could define this function signature 15:10:08 ... And the HTTPS binding for it as, like, a helper thing that's not in the main algorithm, but it's like, here's how you could do it if you want to do it like that, to still support. the stuff that MOX is doing 15:10:14 ... So, we haven't actually talked to Marcus about any of this, but, um 15:10:17 ... That feels like a good progress in the direction we want to move 15:10:26 ... Uh, and then the last thing I put in… we said we would run a proposal today, so I put in some text. Is that text okay? Should we just run it? Just so we get it on the record 15:10:28 Otto Mora: Uh, do you put it in the chat? Or... 15:10:31 Will Abramson: Yeah, I emoted it in the chat... 15:10:33 Otto Mora: Oh, my bad... 15:10:34 Will Abramson: There we go... 15:10:37 Manu Sporny: Wow, where is it? I can't see it... 15:10:51 Will Abramson: Okay, great, yeah, let's run it on that... 15:10:54 Otto Mora: Let's run it then. Topic... 15:10:55 Topic: Proposal on editors 15:10:57 ... Those are my head first 15:11:01 transcriber-bot, pause 15:11:01 ... Yeah, and then transcriber box 15:11:01 scribe- 15:11:14 PROPOSAL: Make Joe Andrieu and Stephen Curran co-editors of the DID Resolution specification 15:11:15 +1 15:11:16 +1 15:11:17 +1 15:11:17 +1 15:11:18 +1 15:11:22 +1 15:12:03 smccown has joined #did 15:12:23 wilou has joined #did 15:12:29 here I am 15:12:36 KevinDean has joined #did 15:12:44 +1 15:12:45 present+ 15:13:10 I was distracted, from the vote .... I downloaded the latest .ics (cal) for this meeting and apparently my email client is spamming the WG email group. SORRY! I'm trying to figure out what it's doing 15:14:05 grace +0 15:14:23 s/grace +0/grace: +0 15:14:33 +1 for the new editors 15:14:42 wilou has joined #did 15:16:41 RESOLVED: Make Joe Andrieu and Stephen Curran co-editors of the DID Resolution specification 15:16:50 transcriber-bot, resume 15:16:50 scribe+ 15:16:55 q+ 15:17:00 ack Wip 15:17:02 Otto Mora: We're assuming, congratulations to both of you, newly minted co-editors. I'll be thankful for your help. Yes, Will... 15:17:14 Will Abramson: But, yeah, just to say, you know, thanks, and uh, we'll be in touch to add to the meeting. I do appreciate it. I think it will really help us move… the workforce... 15:17:19 Joe Andrieu: Cool, glad to help out... 15:17:25 Otto Mora: Yeah, congrats... 15:18:04 dmitriz has joined #did 15:18:04 TallTed has joined #did 15:18:04 transcriber-bot has joined #did 15:18:04 ottomorac has joined #did 15:18:04 dlehn has joined #did 15:18:04 shigeya has joined #did 15:18:04 cwilso has joined #did 15:18:04 cel has joined #did 15:18:04 hadleybeeman has joined #did 15:18:04 manu has joined #did 15:18:04 dlongley has joined #did 15:18:04 jyasskin has joined #did 15:18:07 Will Abramson: Okay, let me just get these slides and share them first. If not… Um... 15:18:15 ... Yeah, okay, so this is actually Manu's suggestion from last week, but, uh 15:18:19 ... We try to get some 15:18:19 Slide deck: https://docs.google.com/presentation/d/1oY6i-kmZ1lTrhL12MS5wft4GTHPYVm3SLw5EwgQQ510/edit?usp=sharing 15:18:22 ... So, let me put the slide back in 15:18:39 ... some clarity on at least the high-level steps for this algorithm. I think based on the. Um 15:18:40 ... the Google Doc that we did, where we looked at, you know, like, all the individual bits of Joe's proposal 15:18:45 ... There seemed to be good consensus that the 15:18:54 ... at least direction that Joe is heading in, in terms of refactoring that algorithm into some sort of much more chunked up steps 15:18:59 ... was a good direction. So, last week, Manny suggested, can we at least try and 15:19:11 ... get some agreement and some content on what those high-level steps are, right? Probably, inside those high-level steps, there are things that we will want to argue about. We are not going to do that today 15:19:17 ... I hope, right? Like, first, we want the steps, 1, 2, 3, 4, their names 15:19:22 ... Maybe what they do, and if we can, what goes into them and what comes out of them, right? 15:19:26 ... Um, so, I tried to do that, I mean 15:19:36 ... Actually, maybe this will be frustrating for some folks, but I ended up just really rehashing much of Joe's PR, but I did try to contrast with the current spec text 15:19:39 ... So, if I slideshow, will you still be able to see that? 15:19:40 Otto Mora: Yeah... 15:19:43 Will Abramson: Yeah, okay, so... 15:19:54 ... First, I want to highlight the existing spec text, right? Like, the existing spec text, so the DID URL dereferencing algorithm says, consists of three steps 15:20:01 ... Resolving the DID, dereferencing the resource, and dereferencing the fragment. The spec currently defines two algorithms 15:20:04 ... Derecessing the resource, then derefacing the fragment 15:20:09 ... And, like, the resolving that did happens inside the dereferencing, the resource 15:20:15 ... Uh, algorithm, which states today. I also just know, like, maybe this is a distraction, but 15:20:22 ... The function signature that we have been discussing is really the signature for this algorithm 1, the dereferencing the results 15:20:27 ... Your fragment doesn't return what you would expect from that 15:20:38 ... I think that kind of is a little bit about where this confusion comes in, because there's this big URL deration that really is just implementing the. Be referencing the resource output 15:20:45 ... Um, and then there's 326, or… I mean, there's a bunch of different PRs from Joe, but I think it's 326 15:20:52 ... Uh, and in that hour… in that, uh, PR, there's 5 steps 15:21:01 ... So prepare to resolve the URL, resolve the DID URL, determine the retrieval strategy, retrieve the results. And use the resource 15:21:17 ... Um, so we want to get to R5, like, on the group. We don't have to use the 5 here, or maybe it's not 5, right? But we want to get to something. Like this, I hope. Uh… And there is some good news. I think the first two 15:21:23 ... I mean, let's stop and talk about this, but for me, the first two, we are aligned on. Like 15:21:29 ... Both… both the current algorithm that we have today. and Joe's algorithm, and Steven's PR 15:21:36 ... all do this in some form, right? They first do some preparation, they validate the did URL 15:21:46 ... Joe added this resolver selection. I mean, the details don't really matter, but they do some steps before they can resolve. the same. But I think 15:21:50 q? 15:21:52 ... Uh, we're aligned there, but we can often check. And then secondly, they all resolve 15:21:59 q+ 15:22:02 ... the DID URL, with the caveat that some of them resolved the did, but they execute a resolution request, maybe we can say, and they get back. A date resolution result 15:22:08 ... So… Dallas, Paul's in Tokyo 15:22:10 ... Oh 15:22:12 Stephen Curran: So, quick question, just to verify. Oh, sorry, I... 15:22:13 ack manu 15:22:14 Will Abramson: Yeah, Manu is on the queue, but... 15:22:17 Stephen Curran: I thought because we were… yep, go for it. Sorry... 15:22:21 Will Abramson: Yeah... 15:22:24 Stephen Curran: The quick question I have is... 15:22:29 ... I want to be sure that when we're saying the did URLD referencing algorithm 15:22:32 ... Begins before we have 15:22:36 ... the DID doc that we're gonna use 15:22:42 ... And that step 2 is retrieval of the did doc 15:22:48 ... Are we agreed on that? That's part of where I think we've had confusion. We're all agreed that the did URL 15:22:56 ... Whether it's just a plain naked did, or has a question mark version time equals, or 15:23:01 ... a path or anything else. The first part of it is 15:23:08 ... get the did doc that matters, and that's what step 2 here is. Agreed? I'm happy with that 15:23:08 Will Abramson: Yeah, that's my understanding. I mean, I don't... 15:23:11 Stephen Curran: Beautiful... 15:23:15 ... I want it to be very explicit, so thank you 15:23:17 q+ 15:23:23 Will Abramson: Yeah, so the resolution result is the did doc plus the metadata that comes back. But most importantly... 15:23:24 ack manu 15:23:26 Otto Mora: Okay, I see my notes... 15:23:34 Manu Sporny: Yeah, plus one, that's my understanding as well. Um, so we should ask explicitly, does anyone disagree with this?... 15:23:44 ... And if you don't know yet, like, you're still trying, you're like, maybe there's something on the next slide, like, that's fine, but like, I want to make sure that we're pulling consensus as we go through this 15:23:47 Will Abramson: Mm... 15:23:53 Manu Sporny: Because if we have agreement on these two things, like, that's… Great... 15:24:01 +1 seems fine. 15:24:03 ... So is anyone disagree, or does anyone… is like, I don't know enough yet to have an opinion, but I might have a strong opinion later 15:24:17 Otto Mora: Yeah, I'm in… I'm in the… might have strong opinions later, Catherine, for sure... 15:24:19 Will Abramson: Hmm... 15:24:22 Otto Mora: Okay. Um... 15:24:30 Will Abramson: So, I do think this is uncontroversial. I mean, like, the controversial bit is this did URL piece. But I'm saying, like... 15:24:36 ... like… like, by agreeing to this, I think we're not agreeing to the did URL bit yet, like, that's not part of this 15:24:40 q+ 15:24:45 ... Discussion, or maybe… maybe it should be, but, like, for me, it's… there is this pre-step that you take the thing that you're dereferencing, and you do some preparation to it 15:24:46 q+ we are agreeing to DID URL bit :) 15:24:50 q+ to say we are agreeing to DID URL bit :) 15:24:51 s/Catherine, for sure/camp, for sure/ 15:24:54 ... Then there's this second step that you resolve and get back the did resolution result. And then you can continue. Okay 15:24:57 ... Steven? Yeah 15:25:00 Otto Mora: Yeah... 15:25:00 ack swcurran 15:25:08 Stephen Curran: Um, the only thing was, uh, I would highlight is, um, Marcus has definitely hammered into me that we dereference URLs... 15:25:20 ... And so, saying resolved it URL is… I think we agree on what you're meaning, um… But there you go. Um 15:25:28 ... Yeah, and that's it. No matter what, in order to get the did doc, it's a URL 15:25:33 ... It's not just a did. So, um, we're dereferencing 15:25:38 ... all the way, um, you might say retrieve did document 15:25:41 Will Abramson: Yeah, or execute resolution request... 15:25:44 Stephen Curran: Yeah... 15:25:45 Joe Andrieu: Uh, please, sorry, don't use retrieve... 15:25:48 Stephen Curran: Okay... 15:25:52 q? 15:25:54 Joe Andrieu: Like, I think it's important that this step is resolution. This is what didcore defines as what happens here... 15:25:55 ... And it would have a name conflict with the retrieval 15:25:56 Will Abramson: Mm-hmm, mhm... 15:25:59 Stephen Curran: Okay, that's fine... 15:26:01 +1 15:26:05 Joe Andrieu: Uh, parts, which… which maybe we need to rename anyway, I just, you know, don't want to introduce that. Dual naming right now... 15:26:09 Stephen Curran: And then the first step should be prepare to dereference the did URL... 15:26:15 Will Abramson: Do you agree?... 15:26:17 Joe Andrieu: I don't... 15:26:17 q? 15:26:20 Stephen Curran: Oh, okay... 15:26:29 Joe Andrieu: Uh, because this is dereferencing. Like, I think the first step of dereferencing is you have a URL and you need to prepare so that you can send it to Resolve... 15:26:31 Will Abramson: Yeah, so, um, I see you on the... 15:26:34 Stephen Curran: Okay, I see, yep... 15:26:42 Will Abramson: on the queue, I just want to highlight that this is… yeah, I… I mean, I know what mine is going to say, like, we are deciding on the did URL piece, um... 15:26:53 ... maybe you should say that, but… I still just wanted to get, like, there is some alignment here that there are these two steps, like, we… there is some details about the steps that maybe we still need to discuss about, but 15:26:54 Otto Mora: Mm-hmm... 15:26:56 ack manu 15:26:56 manu, you wanted to say we are agreeing to DID URL bit :) 15:26:58 Will Abramson: I guess the URL is an input. Anyway, neither... 15:27:01 Otto Mora: Man, yeah... 15:27:04 Will Abramson: Yep... 15:27:14 Manu Sporny: Yeah, so let's not get hung up here, and let's move forward. I'm asserting, like, Marcus is the only one pushing back that I know of on the URL as an input to all the algorithms, and I think we should just accept that and move on. I don't hear anybody else... 15:27:19 ... objecting to that. I'd love to hear on the call if anybody else objects to that, but, um 15:27:22 Will Abramson: Um… my... 15:27:29 ... Yeah 15:27:32 Manu Sporny: But… but we… let's keep going, because I think we're dangerously close to getting wrapped around the axle if we keep talking about this slide. Let's get to the other slides... 15:27:39 Will Abramson: Yeah, okay, yeah, yeah, good. We can go exactly, let's come back to that later, but uh… that's easy, right?... 15:27:48 ... Uh, okay, and then I have some, like, sort of some, like, informational bits, so we can try and understand what we mean about the next bit, right? So we have the referencing did URLs 15:27:52 ... The URLs might contain query parameters 15:27:59 ... Right? And there are known queried parameters that we have to decide how to handle in the dereferencing algorithm. The service 15:28:07 ... And the service type, and the relative ref, right? They're the only known query parameters that are part of the dereferencing algorithm 15:28:17 ... And, you know, my observation was they're all related to services in the DID document. Like, we also have version ID and version time, but they're really part of DID resolution 15:28:17 q+ 15:28:21 ... and one of the arguments why we should pass the URL, I think 15:28:24 q? 15:28:28 ... And then there's this weird one, which is really an option, and I put this in there because Joe's algorithm has completely removed it. There's this 15:28:34 ... option, which actually I propose, like, verification relationship, which is a way to, like, target verification methods 15:28:43 q+ 15:28:44 ... Uh, they're authorized for specific relationships in a document. And I just want to find out, if this is just getting confusing, maybe we just ignore it for now, and I'd be happy to remove it. Like, it's not like a 15:28:47 ... critical thing, I just thought it would be a useful feature. Um 15:28:53 ... And then… the other caveat is, like, we can't know all query parameters 15:29:01 ... that we're gonna have to handle, right? Like, in this algorithm, so we have to have some space to support extensions. Um 15:29:11 ... Yeah, and then just the existing spec text handles query parameters first in step 7. And even in, uh, 326 15:29:20 ... the query parameters are really the things that are handled first, at least service and service type. I know Joe handles relative breadth a bit differently. Is there any other questions? 15:29:21 ack swcurran 15:29:23 Otto Mora: Yeah, Steven is first... 15:29:28 Stephen Curran: Um, the only thing I'd like to add to this, and I don't want to go into any... 15:29:33 ... Great conversation, but… and so we can… we don't need to 15:29:38 ... dive on this, but Path should be part of… Um, this list 15:29:42 Will Abramson: this next, but I just wanted to separate them out, because I couldn't film the same slide... 15:29:47 ... Yeah, yeah, totally 15:29:51 Stephen Curran: And again, not path service, path. We need to handle a path, and the spec just needs, and I don't care if it's path service or not, but... 15:29:55 ack manu 15:29:59 Will Abramson: Yeah, yeah. I just wear them all. Uh, money?... 15:30:13 ... Mhm. Hmm 15:30:20 Manu Sporny: Yeah, just to speak to… and this is a final analysis, Will, to speak to, like, relative ref, I really dislike it. I think it was a mistake, and we should remove it from the spec, but, you know, I'm happy to keep it there for backwards compatibility or any of that stuff. I think the PAT stuff is a much better way to... 15:30:24 ... To deal with it. Um, and then the service and service type bits, I don't know how useful 15:30:35 ... And the verification relationship thing, I don't know how useful that… those features are. Like, we put them in a long time ago. I can't even remember why we did it 15:30:40 ... Um… I'm sure people have use cases for them, but I'm kind of like 15:30:48 ... why can't that just be a part of, like, what you do during dereferencing locally? Like, do we… do we really need 15:30:58 q+ to ask Stephen about path 15:30:59 ... you know, maybe we define other algorithms to get to that data. Anyway, just a thought, like, I don't know who's got, like, some absolutely critical 15:31:01 Will Abramson: Oh... 15:31:04 Manu Sporny: Use cases for service… and service type and verification relationship. Um, that's it... 15:31:07 Otto Mora: Uh-huh... 15:31:12 Will Abramson: Yeah, you said something confusing to me then, because you said, uh, why can't it just be part of... 15:31:20 ... what, like, the dereferencing that you do locally, but I think it just is part of dereferencing, right? We handle this query parameter. I mean, if we removed it, then 15:31:29 q 15:31:32 Manu Sporny: No, I'm saying, like, remove it as a query parameter, like, what's the worst thing that would happen if we removed it as a query parameter? Would people be totally unable to achieve their use cases?... 15:31:35 Will Abramson: Hmm... 15:31:43 Manu Sporny: Or would they just go about them in a different way? Like, I think the reason we put this in there is to, like, very specifically point out, like, a service, or a verification relationship, and be able to get, like, a subset of the did document out... 15:31:46 Will Abramson: Hmm, mm... 15:31:46 q+ 15:31:52 Manu Sporny: But I'm like, I can't even remember why we did that. Like, what use case was so important that we... 15:31:55 ... we felt the need to do that. Um 15:31:59 Will Abramson: Joe?... 15:32:05 q- 15:32:07 Manu Sporny: I've forgotten. I don't know if anybody else can remember, and if none of us can remember, then… and nobody's using it, then it's kind of like, oh, wow, we should probably remove that feature that... 15:32:11 ack JoeAndrieu 15:32:11 JoeAndrieu, you wanted to ask Stephen about path 15:32:18 Otto Mora: Uh, okay, so we have Joe. And then afterwards, Dimitri... 15:32:24 Joe Andrieu: Okay, um, on the verification thing, uh, relationship real quick, I, uh, I... 15:32:28 ... Um, I think I'm with you, Manu. It feels like it's 15:32:34 ... It's something the application who's dereferencing is going to know 15:32:39 ... Um, and needs to know, like, how you inspect the did document. Um 15:32:46 ... It doesn't seem to affect either resolution or retrieval. Um, so those are the two litmus 15:32:54 ... test that I would, um, consider for standardizing a service parameter that has, you know, that key value 15:33:02 ... Um, but I was curious, um, Steven, about your suggestion that path be here. Did you mean that there should be a question mark path equals blankety blank? 15:33:05 Stephen Curran: No... 15:33:09 Joe Andrieu: Um… okay, because that is what we're talking about here. This is about the query part of the DIDs... 15:33:12 Stephen Curran: Um... 15:33:17 Joe Andrieu: So… that's good. I think we maybe are aligned. I thought maybe we were misaligned, because I… I interpreted your comment that way... 15:33:21 Will Abramson: And you shouldn't read into the ordering of this, like, I could have put path first, right? This is just information... 15:33:25 ... If that was confusing you, Steve 15:33:28 q? 15:33:30 Stephen Curran: No, the only thing was, I was seeing it as handling the non-fragment parts... 15:33:31 Joe Andrieu: Oh, the path part... 15:33:33 Will Abramson: Totally, yep... 15:33:34 Joe Andrieu: Yep... 15:33:37 Stephen Curran: So that's all. And so PATH would be included as a... 15:33:41 ... As a thing that gets defined in this specification, that's what I was calling for, is making sure that 15:33:44 Will Abramson: Yeah... 15:33:46 +1 15:33:49 ... Mm-hmm. Dimitri? 15:33:52 Otto Mora: Zoom Meetings... 15:34:02 Dmitri Zagidulin: I can only take a guess, uh, at why the verification relationship. was added to... 15:34:07 ... Any sort of did client 15:34:11 ... Does have, or many of them 15:34:16 ... Do you have, uh, let's say a method, a function that says 15:34:21 ... gave me a key for a given verification relationship. Meaning 15:34:32 ... I'm fetching, uh, did, but really, I want an authentication key. Or, really, I want a, um, assertion method key to sign a verifiable credential 15:34:35 ... So, that function… that abstract function 15:34:39 ... is useful and does exist on most… on most did methods 15:34:47 ... So that would be my closest guess for why it was added. Now, does it belong on the crane parameter level? No, I don't think so 15:34:51 ... Oh, you added that. Oh 15:34:52 q+ 15:34:54 Will Abramson: Yeah, well, to be clear, it's not a… I added this this round, right? Like, it's, like, maybe a year ago, and it was exactly for that reason... 15:35:00 Dmitri Zagidulin: Oh, it's not a query. Ah... 15:35:02 q? 15:35:06 Will Abramson: But it's not a query parameter, like, I first proposed it as a query parameter, and instead, it's like an option that you can pass in currently, in the current spec tape, it's an option that you pass into the dereferencing algorithm to say... 15:35:10 ... to specifically say, like, I only want to find a verification method if it's part of this 15:35:12 Dmitri Zagidulin: Okay. Got it... 15:35:17 Will Abramson: But I agree, like, you can definitely… we don't… maybe we don't need to find that at all, like, people understand that, and… You know, this is just that, you know... 15:35:22 q- 15:35:29 ... Okay, great. Let's keep going, because we're out of time 15:35:39 ... Um… yeah, so then I just want to talk to the path too, right? Like Steven says, we absolutely want to have a way to handle the path. Uh, the current spec 15:35:46 ... is kind of hand-wavy about the path, right? Like, because we hadn't really figured out how to do it, and that was what Stephen tried to do with path service 15:35:54 ... To figure out a proper way to handle path. I just wanted to highlight some of the different ways that path handling might happen, right? There's this 15:35:59 ... Specific service types that are around or define how to handle a path 15:36:04 ... There's these property extensions of the DID document, like this linked resource property 15:36:13 ... There's, uh, you know, did document metadata, that's a did link resources approach, and then there's this other, like, again, hand-wavy thing that did method-specific 15:36:17 ... Things might define path handling 15:36:28 ... I think this is the question that really Joe has been trying to grapple with, like, given a path and a did resolution result, how do you identify and disambiguate the path handling approach? 15:36:36 ... Right, or, I mean, here he says, how do you determine the retrieval strategy for this given path? Um 15:36:44 ... So, I think that's the… the thing, like, how do you know what this path should be targeting? Like, where does it target in the resolution result? 15:36:51 ... like, is it a specific service? Should it be applied to a specific service in a specific way, or is it a 15:36:55 ... Document property extension, or is it applied to, like, some metadata? 15:36:59 ... Uh 15:37:01 q? 15:37:02 ... That's all I have on that. Let's anyone on the queue. I'll keep going 15:37:07 Otto Mora: Um… No, no, no one on queue... 15:37:17 Will Abramson: Yeah, so then I'm like, okay, so what is step 3 of this algorithm, right? So we've done step one, we've done some preparation, then we've resolved... 15:37:24 ... to get back the did resolution result, which includes, hopefully, the did document, right, unless it's failed. It includes the document 15:37:31 ... Uh, so in the existing spec text, right, steps 7 and 8 of the dereferencing results algorithm 15:37:36 ... Um, are handling the path and query parameters 15:37:40 ... Right, currently, step 7 handles just the query parameters, and then step 8, sort of 15:37:43 ... Hand-raised a little bit about how to do the path 15:37:51 ... And in 326, there is this step 3, which is, you know, determining retrieval strategy 15:37:59 ... Um… so, a retrieval strategy adds, like, okay, how do we actually retrieve this result? Like, if we 15:38:06 ... Uh, found that the… the object that is targeted by this path 15:38:13 ... or we found the retrieval… I think it's really, we found the retrieval strategy, how can we use that strategy to interpret the path, maybe? 15:38:20 ... Um, and then just to keep on, like, identify resources might not be HTTPS URLs 15:38:23 ... So, retrieval is not necessarily, like 15:38:28 ... known, right? Like, the type of the thing should be explicit about how you 15:38:38 ... how you use the hash in the… use the path in the did URL, combined with something in this thing that you've identified, to. execute a 15:38:40 q? 15:38:41 ... The retrieval of the results 15:38:47 ... Uh, I think this is the most complicated one that we're definitely gonna have to dive into deeper 15:38:50 ... But I wondered if we could just agree that the 15:38:57 ... the purpose of Step 3 is, like, handling the did path and query parameters 15:39:01 q+ to mention we missed this: the type of the service needs to specify the retrieval strategy 15:39:02 q+ 15:39:05 ... In order to identify the resource to be retrieved and how to. Go about retrieving it 15:39:11 ack JoeAndrieu 15:39:11 JoeAndrieu, you wanted to mention we missed this: the type of the service needs to specify the retrieval strategy 15:39:13 Otto Mora: Uh, both, uh, Joel first, then Adam... 15:39:22 Joe Andrieu: Okay, um, yeah, it turns out, I think this was a very big gap in, um, our thinking about how service endpoints worked... 15:39:30 ... Um, we have, for example, in the BTCR2 service endpoint 15:39:36 ... Where we advertise the beacons for getting, um, uh, updates, or for 15:39:43 ... for getting publishing of updates to a DID document. Um, we use a Bitcoin colon 15:39:51 ... Uh, URL, and the default retrieval strategy that is to construct a payment 15:40:00 ... address. Like, it's treated as a payment address, and you're expecting the wallet is going to populate a form that the user can just put in how many Bitcoin they want to send 15:40:06 ... But that is not how you would use it if someone used the service parameter that pointed to that beacon 15:40:18 ... And we did not define what you do, because we are just using that URL as a URI in BTCR2. Um, so that's sort of connected back to this work. Like, if someone put in 15:40:28 ... Uh, question mark service equals, you know, my beacon ID that's in a BTCR2 document. Uh, we have woefully underspecified how you would retrieve that 15:40:34 ... Um, and so that sort of just opened up the whole fact that for all of our service types 15:40:34 q? 15:40:39 ... Um, I think there were presumptions about how you might use it, um, and I think we need to 15:40:50 ... Um, sort of socialize that, hey, these different service endpoints may have different mechanisms for interacting with what the endpoint value is in that service type 15:40:51 q+ 15:40:53