13:55:15 RRSAgent has joined #did 13:55:19 logging to https://www.w3.org/2026/05/27-did-irc 13:55:19 rrsagent, make logs public 13:55:23 Meeting: Decentralized Identifier Working Group 13:55:28 Chair: ottomorac 13:55:40 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026May/0049.html 13:55:40 clear agenda 13:55:40 agenda+ Continue discussion on DID Resolution Algorithm Inputs 13:55:40 agenda+ Discuss PRs 13:55:40 agenda+ Will Abramson 13:55:40 agenda+ Pierre-Antoine Champin 13:55:42 agenda+ Otto Mora 13:55:45 agenda+ [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did/) ([View Calendar](https://www.w3.org/groups/wg/did/calendar/)) 13:56:01 previous meeting: https://www.w3.org/2026/05/21-did-minutes.html 13:56:50 next meeting: https://www.w3.org/2026/05/28-did-minutes.html 14:00:38 TallTed has joined #did 14:03:32 Wip has joined #did 14:03:36 present+ 14:04:10 present+ 14:04:30 KevinDean has joined #did 14:04:35 present+ 14:05:48 Topic: Agenda Review 14:06:01 manu has joined #did 14:07:39 transcriber-bot, resume 14:07:39 scribe+ 14:07:43 Otto Mora: Yes... 14:07:43 present+ 14:07:46 ... Sounds good. So, um, yeah, I don't have the 14:07:52 ... Minutes from last week, but we can maybe just provide a brief summary of 14:07:58 ... what transpired last week, and I think there's some PRs being created, um… Right, Bill 14:08:03 Will Abramson: Yeah, I mean, I can try and summarize... 14:08:08 ... Yeah, so… last week, we were focused on, um 14:08:19 ... like, I guess, loosely, step 3 of this dereferencing algorithm, the refactor. So I'll just get this back up, because… Um 14:08:23 ... So 14:08:40 ... The referencing strategy for did URLs 14:08:47 ... Um, and what happened? So we walked through a bunch of examples that Stephen put together. I mean, the outline has now emerged into the spec, so we have these five steps that we all discussed, I think, a couple of weeks ago, and kind of came to, you know, broad consensus on. And we were discussing, really, the. And I think we came to 14:08:51 s/get this back up/get the spec up/ 14:08:58 ... consensus on what steps through, you know, like, how we handle these different cases. For example, I think the key one was when there is a path on the DID URL 14:09:07 ... what we do is we look in the DID document, or really look in the DID resolution result for all, um, objects that identify themselves as path handling 14:09:13 ... And we collect them together, and then we use the path in the DID URL to select 14:09:18 ... The specific object that we're going to use to process the path 14:09:24 ... Uh, and if there is duplicates, or multiple are selected, then that is an error 14:09:40 s|The referencing strategy for did URLs| The referencing strategy for did URLs https://w3c.github.io/did-resolution/#determine-retrieval-strategy 14:09:41 ... And that's what we decided. And then I think the other one we decided if there's a service query parameter, then that would be processed first. So the service query parameter is targeting a specific service in the deduction by an ID. And 14:09:52 present+ 14:09:55 ... Even if there's a path, you use the service to select the — you use the service query parameter to select the specific service that you're going to use. Uh, and I believe we said… you either 14:10:01 q+ 14:10:03 ... ignore the PATH, or, you know, you use the PATH as that service you selected. Determined. So it might use the path, or it might not 14:10:13 ack swcurran 14:10:15 ... Yeah, so that's my understanding of it. Please jump on the queue if I've missed things. There's Steven there. I mean, since Marcus isn't here, it might be a good place to start 14:10:19 ... Um, I think we're ready for PRs on that section at least, so 14:10:21 ack swcurran 14:10:22 ... Steven? Oh, sorry, I just did your job 14:10:32 Stephen Curran: Yeah, I was just jumping on the queue to say I've been thinking through and planning it out. I should have a PR. By today. By the end of day... 14:10:35 JoeAndrieu has joined #did 14:10:35 Will Abramson: Right... 14:10:41 Stephen Curran: Um, that is the, um, that... 14:10:47 q+ 14:10:48 ... that you just walked through, which is all of the retrieval strategy selection, I believe it's called. And I've got, at this point, 4 different 14:11:00 ... I think 3 or 4 different, uh, I think it's 4, maybe 3. Anyway, uh, retrieval strategies, I'll have that PR in. built on top of 331, which we merged on Monday 14:11:02 q+ to mention interaction language 14:11:04 ... Uh, for discussion tomorrow 14:11:05 ack Wip 14:11:09 Otto Mora: Perfect. Well... 14:11:13 Will Abramson: Great, yeah, I just wanted to follow up and ask about, um... 14:11:25 ... I think one of the things we also discussed was how does, uh, something in a did resolution resolve? Identify itself as path handling 14:11:32 +1 14:11:32 ... And I believe where we landed was we are going to define a new type 14:11:36 +1 14:11:43 ... Uh, that would go in the, you know, like, the service has a type property, and then there's going to be a specific type that anything that's path handling would have to add to kind of flag itself as, hey, I handle path 14:11:50 I'm logging. I don't understand 'draft mintues', TallTed. Try /msg RRSAgent help 14:11:57 ... Uh, I was hoping for Alex, I've messaged Alex, he might join us tomorrow, or at least he's aware that this change is going through. This is going to require both, you know, the did-linked resources and the linked resources approach to make some changes. So be good to have everyone 14:12:00 I have made the request to generate https://www.w3.org/2026/05/27-did-minutes.html TallTed 14:12:07 ... I think that's a good approach, because… I'm bored with that, so 14:12:07 ... So I just wanted to ask you, Steven, really, is that something that is also going to be in your PR? 14:12:07 Stephen Curran: Yep, yep, yeah, that's fair... 14:12:12 Will Abramson: Great, great... 14:12:16 Otto Mora: Hmm... 14:12:18 ack JoeAndrieu 14:12:18 JoeAndrieu, you wanted to mention interaction language 14:12:18 Stephen Curran: Yeah, I've got it written out, I just have to go into a respec and put it in... 14:12:25 Otto Mora: Okay, and I believe... 14:12:34 Joe Andrieu: Yeah, I wanted to see if we could spend some time, uh, trying to nuance the language, um, of how we talk about retrieval strategy to address a pretty good point that Marcus brought up... 14:12:44 ... Um… If we have at the end of this calculation of the service endpoint something that's like a mail to. Uh, scheme 14:12:49 s/did URLs/DID URLs/g 14:13:01 ... It it doesn't I mean maybe technically it's right in some notion because it's a uniform resource locator So we're you know dealing with the resource. But it feels more like we're interacting with the resource when we execute a mail-to handler 14:13:06 ... Um, and so I think the language that I had 14:13:19 q? 14:13:20 ... And I'm not sure how to clean it up but I I resonate with Marcus's concerns. You know, proposed around retrieval strategy and that we're getting a resource and then using the resource. There is a little bit of dissonance there 14:13:27 q+ 14:13:32 q+ 14:13:32 ack Wip 14:13:33 Otto Mora: Okay? Uh, yeah, well... 14:13:45 Will Abramson: Yeah, I mean, I guess I'm wondering if Joe thinks we should be looking for other names than retrieval strategy, or at least taking some time to explore that. Um... 14:13:48 ... I can't remember what we said in the case, so 14:13:56 ... Um, so I have a service query parameter, and I'm targeting a service that is, like, a mail-to or something 14:14:04 q+ 14:14:07 q+ 14:14:10 ... And what did we say the outcome of that would be? Because this service wouldn't have a defined retrieval strategy yet, maybe, let's say. You know, like, there are services out there that don't have this concept of a retrieval strategy 14:14:12 q? 14:14:14 ... I think… Did we say we just returned the object, or the URL? Or maybe it was the URL, I'm not sure 14:14:17 ack manu 14:14:17 Joe Andrieu: Uh-huh... 14:14:22 Otto Mora: Mm-hmm. Manu?... 14:14:25 Manu Sporny: I'm wondering if we can say that... 14:14:34 Stephen Curran: Okay... 14:14:45 Manu Sporny: one of the options, you know, is to retrieve the resource, but that's not the only mechanism that you can use. Like, for example, I think... 14:14:53 ... You know, we're really talking about, you know, using the, the resulting outcome, right? So use, use the resulting outcome where one of those things might be dereferencing the resource, right? I think the current language 14:15:05 +1 to Manu 14:15:07 q+ dmitri 14:15:10 ... It seems like we're saying, oh, you always dereference a resource. And I think maybe we can change it to say like one of the things you can do is dereference a resource. And here's, you know, the retrieval strategy and all that kind of stuff for if that's the path you go down. But another path might be like, oh, it's mail to URL 14:15:16 q- 14:15:23 ... open an email client using that, right? It's not necessarily dereferencing, but you are using the result of, um, you know, the process. As one idea. That's it 14:15:30 Otto Mora: Okay, we got Steven on the queue. Uh… oh, sorry, sorry... 14:15:31 ack swcurran 14:15:31 Stephen Curran: I just said, I agree with Amanda. Yeah, I jumped off. So Joe can go ahead... 14:15:34 dmitriz has joined #did 14:15:34 Otto Mora: Okay, Joe... 14:15:35 ack JoeAndrieu 14:15:47 Joe Andrieu: Um, okay, uh, three things that'll come up. So, um, I… I think, to Will, your comment about if there's not a retrieval strategy, because there's a mail-to... 14:15:55 ... The mail to is a scheme on a URL that's going to be in a service endpoint property. That service block should still have a type 14:15:59 Stephen Curran: Mm-hmm... 14:16:02 Joe Andrieu: Now may only have the bear type and no specific type. Like it may say, hey, I'm a service... 14:16:09 ... Right? And in which case, we would define, what do you do with a service that doesn't have a secondary type? 14:16:15 ... Right? It's not a path handler, it's not a whatever. Um, it's just a type of service 14:16:17 Note that "service" is not a type. 14:16:29 ... Um, so I do still think it would be within that service to decide how you interact with whatever URLs, um, are appropriate for its service endpoint. Um, I think that… so that's one point. Next point, I think what we do 14:16:35 ... rather than returning a resource in those cases, although I think there is some nuance in which 14:16:51 ... What you're really doing is retrieving a representation of the resource. I've heard Pierre Antoine use that sort of language. But we invoke a handler. Functionally is like what the browser does, right? If I click on a mail to link and I don't have a mail to handler 14:16:57 ... uh, set up, then the browser will prompt me and say, well, how do you want to handle this? So it may be invoking a handler is, um 14:17:12 ... uh, language we can use. Um, but I do think, uh, this is a little pushback on what you said, Manu. I think when you have a mail-to URL, dereferencing it means invoking the handler. So I think, I think in the world of 14:17:20 So instead of retrieval strategy why use "handler strategy" 14:17:28 ... Dereferencing URLs, they process a mail to dereferencing in that manner. So I think the language still applies, even though what comes back isn't really the resource. Like, that's the weird thing. Like, when we think of HTTP or FTP, we think we get back this block of 14:17:34 Topic: Retrieval Strategy 14:17:36 q? 14:17:37 ... a binary something or text something, and that is the resource. But with MailTo and other sort of service-type, um, schemes, that's not quite right 14:17:42 Otto Mora: Uh, Dimitri... 14:17:45 ack dmitri 14:17:52 Dmitri Zagidulin: I think invoking a handler, like Joe said, is the best of the options that I've heard so far... 14:17:59 ... But to me, this is just more events that were going down the wrong path. Uh, saying 14:18:06 ... I don't think any other spec has the words, use the resource 14:18:14 ... Inspect shouldn't tell the client what to do with the resource. We in such generic terms 14:18:17 ... And… That's not a spec. That's just saying, yeah, do something 14:18:21 ... Uh, the invoking a handler 14:18:34 ... So, we're in browser territory. Now, we're gonna have to look through the browser specs on how exactly they do the handlers there for 14:18:38 q+ to note that mailto invokes a protocol handler 14:18:47 ack manu 14:18:47 manu, you wanted to note that mailto invokes a protocol handler 14:18:47 ... for resources and pretend like we're writing browser code, but we're not. All of this is just signs that we're going down the wrong road with. with this whole retrieval strategy. That's it 14:18:51 Otto Mora: Mm-hmm. Manu?... 14:19:03 Manu Sporny: Yeah, just, uh, digging around, um, on Mailto, um, so I don't think... 14:19:06 q+ to mention secondary resources 14:19:13 ... I don't think dereferencing applies there, right? So MAIL-2 is a scheme, it's a protocol scheme, and the way that I think most RFCs talk about it 14:19:30 ... is you invoke a scheme handler or a protocol handler. And so, you know, there's language around there being a handler, you know, involved there. So maybe, you know, playing off of what Dimitri said, maybe we are talking about handlers here. We're not talking about, um 14:19:35 q+ 14:19:44 ... you know, anything, uh… anything else. But yeah, I mean, like, you know, I don't know if we have something other than mail, too, right? So for, like, HTTPS 14:19:53 ... we are dereferencing, that makes sense. For mail 2, we're invoking, uh, you know, protocol, uh, handler, effectively. Um 14:20:06 ack JoeAndrieu 14:20:06 JoeAndrieu, you wanted to mention secondary resources 14:20:06 ... I'm trying to think of another class that doesn't fall into the scheme, the protocol schemes bucket, um, because all of those are… you invoke a scheme handler, you invoke a protocol handler, uh, and then that's… that's kind of it 14:20:06 Otto Mora: Mm-hmm... 14:20:07 Manu Sporny: That's it... 14:20:10 Otto Mora: So... 14:20:35 Joe Andrieu: Yeah, one other scheme that has that property, but there are hundreds of schemes. So I'm sure you know that there are tons more, but Bitcoin is also like a mail too. It should open in your wallet and, you know, open an interface for you to send money to that address... 14:20:45 Stephen Curran: Yeah. Okay... 14:20:48 Joe Andrieu: So it's also sort of not resource based. I think, Stephen, did you suggest in here a handler strategy? That may be a good way to rename that this section. So I'd be in support of that... 14:21:01 q+ to note all of those are scheme handlers (not resource based). 14:21:03 ... But I'm still fascinated, Dimitri. 3986 absolutely talks about secondary resources and what you have to do after you've gotten the first resource. So there is great depth in these systems about what you do with response you get back from your first couple of steps. And that's all we're doing 14:21:18 ... We're saying when you get back a DID document, the URL alone is not sufficient. And for linked resources and DID linked resources, it is completely unusable if all I have is the URL and you hand me an HTTP URL because I cannot guarantee the integrity of the object, and that's the whole point of linked resources 14:21:38 ... So we need to have some mechanism whereby the the referencing party that did URL client can figure out what to do with the with the result they get back from resolution. And that is going to be looking at the data and figuring out how to invoke what kind of handler 14:21:43 ... Which is using the the resource but maybe maybe it's you invoke the handler is what we're gonna say. That may work better and maybe more aligned with where you're coming from, Dimitri 14:21:48 Dmitri Zagidulin: Yeah, I think invoke the handler is much better language... 14:21:52 ack swcurran 14:21:54 Otto Mora: Thanks for that. Uh… Steven?... 14:22:11 Stephen Curran: Um, for another example, um, that is much more into the space we're in is Didcom, because when you get a Didcom-type service... 14:22:25 ... you aren't going to use it at that point. What you are doing is just getting that DIDCOM information, so when you start interacting with the other party, which you may do a thousand times after you, you know, after you do 14:22:39 ... Um… did URL dereferencing, you're just using that endpoint. So you're never going to use it right away. So again, that's a different one than what we're talking 14:22:48 ... I liked what I heard, so we said… so, just to be clear, I think we're saying, instead of retrieval strategy, we're saying. you know, handler. Um 14:22:54 ... Uh, handler selected, of which we've got 14:22:58 ... 4 or 5 of them. that are there, one of which is 14:23:09 ... You know, handle the object, process the object you get back, and that will depend on which object you get back, and what its service type is, and what you want to do with it 14:23:13 ... Is that what we're hearing? And so it's just that nuancing of that 14:23:21 q+ 14:23:22 ... The the overall approach is the same, but we're, we're getting away from retrieval as the only thing you can do 14:23:22 ack manu 14:23:23 manu, you wanted to note all of those are scheme handlers (not resource based). 14:23:27 Otto Mora: Okay. I don't know... 14:23:40 Manu Sporny: Yeah, plus one, that sounds right to me. Um, at the very least, I think we're talking about handlers. Um, Joe, I was somewhat confused by what you said. You said Bitcoin... 14:23:43 Stephen Curran: Okay... 14:23:59 Manu Sporny: you know, doesn't fall into the category, but it isn't… I mean, Bitcoin's a… is a protocol. Um, I think it has a protocol scheme, Bitcoin colon. You might be saying, like, no, like, the… the thing that we're talking about doesn't have that... 14:24:08 ... scheme handler in front of it, and therefore, you know, not every one of these handlers is going to be associated with the protocol scheme. Um 14:24:22 ... So, general question there, is everything we're talking about here, does it have a protocol scheme involved somewhere? At which point, these are protocol scheme handlers, and that's kind of what everything else 14:24:29 ... refers to them as. Um, and if that's not the case, then I think we just back off to, like, handler 14:24:31 q? 14:24:35 Stephen Curran: Mmhm... 14:24:38 Manu Sporny: but, you know, what kind of handler is it? Like, we… I… it feels like we need a descriptive word there for the type of handler it is. Um... 14:24:44 ... But if we can't figure out what it is, then just handler for now is fine, probably 14:24:51 Otto Mora: And you and, Manu, you mean BTCR2 in particular, right? Not just Bitcoin generally. You're talking about that that particular dimension. As a sample... 14:24:54 Manu Sporny: Well, I'm looking for an example. Yeah... 14:24:58 ack JoeAndrieu 14:25:00 Joe Andrieu: That's the intersection. Let me go ahead and answer it. Uh, there is a Bitcoin scheme... 14:25:09 this - https://github.com/bitcoinjs/bip21 14:25:17 ... Which is used like mail to where if a browser were to come upon it, the handler it should select is a wallet, and that wallet will open with the transaction so the individual can decide how much money they're going to send to that address 14:25:25 Sorry this is better - https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki 14:25:34 ... Um, but that is not the retrieval strategy or the handler strategy that you would use if you were, uh, given the Bitcoin. Endpoint from a, um… Uh, BTCR2 14:25:39 ... service endpoint. So, frankly, we didn't define it when we 14:25:45 ... Uh, came up with BTCR2, we weren't thinking that someone might 14:25:50 ... index that service, and put it in the URL, and say, hey, dereference this URL that goes to this service 14:26:01 q+ 14:26:07 ... What I think should happen if you do that is, uh, you know, it's up for debate. In fact, you know, I don't even control the spec anymore. So, um, what I would think you would do is you'd get back the chain of provenance of the edits to the DID that were anchored at that address 14:26:26 ... Because that's what the resolver is going to do. So I think you would echo retrieving the set of resources that a resolver does because it has a service endpoint. And so we can't just invoke a handler that it's Bitcoin because it would not do the right thing. And that's sort of the same problem with linked resources 14:26:40 ... Which is, a linked resource could provide a URL, it doesn't have to, it's optional, but it could provide a URL at which you can go get that resource. But that URL alone is not sufficient, so the HTTP or HTTPS, um 14:26:54 ... Protocol is not the only thing you need to do. The handler needs to know the data integrity components And possibly the encryption or the compression components in order to understand how to process that resource once it gets it back 14:27:04 q+ 14:27:10 ... So there is still a handler here that wraps around the get of the HTTP endpoint. And so one of the things I've been arguing for here is that whoever is handling this next step, right, to invoke the handler, they need more than the URL 14:27:18 q+ 14:27:25 q+ to ask are these "service handlers" or "service strategies"? 14:27:26 ... They can't just use the protocol. They need, at least for linked resources, they need the protocol. I mean, they need the data integrity elements, and for the Bitcoin thing, you need to know that this is a BTCR2 special handling mechanism. It is not just a Bitcoin. Colon URL invocation 14:27:29 ack swcurran 14:27:32 Otto Mora: Got it. Uh, Steven?... 14:27:33 q- 14:27:39 Stephen Curran: So, I think what we're doing here is putting a lot more pressure on the… underlying specs... 14:27:50 ... that define, oh, here's what you do when you get a service with this type on it. Um, here's what you do, you know, for 14:28:06 ... items within the DID doc or the DID metadata. Um, we have not pushed too hard on that before, so one of the things, like, like, I wanted was to put the, um, path service type in 14:28:11 ... this spec, and so certain ones would be in the DID resolution spec 14:28:16 ... Um, but allowing others to be put into extensions and 14:28:23 ... And as appropriate, moved into this specification, so that it, um 14:28:29 ... gets consistency in how… how types of things get used. Um, that's 14:28:39 ... But I think that's the path we're going down, which… this spec is just gonna say, hey, you got… you know, as a result of this, you're gonna have. an object that's been identified by the DID URL 14:28:45 ... handle it as defined in that specification. That's it 14:28:48 ack KevinDean 14:28:49 Otto Mora: Okay. Kevin?... 14:28:58 Kevin Dean: Yeah, just want to add that the HTTP is no longer just a... 14:29:05 ... get a resource protocol. There are, particularly when you're dealing with mobile devices 14:29:20 ... apps can register their own URLs, for example, Amazon, and clicking on that URL will actually open the app. It can go straight into the app and trigger. Uh, actions within the app 14:29:25 ... Before you actually complete the process that you intend to complete 14:29:26 q? 14:29:28 Otto Mora: Mm-hmm... 14:29:29 ack manu 14:29:29 manu, you wanted to ask are these "service handlers" or "service strategies"? 14:29:33 ... Uh, yeah, madam? 14:29:43 q+ maybe both 14:29:52 Manu Sporny: as a service. Yeah, plus one, that's a great point, Kevin. So what are these things called? Are they service handlers or service strategies? I'm guessing maybe not, because I forget, it's like resources doesn't actually express itself, is it? Um, yeah... 14:29:53 q+ to maybe both 14:29:58 ... And if so, you know, if we pick one over the other, like, what's the driving 14:30:08 ... reason. I do like strategy as a general term because it's like, you know, a way of doing something. Handler's fine as well 14:30:13 q- maybe 14:30:14 ack JoeAndrieu 14:30:14 JoeAndrieu, you wanted to maybe both 14:30:15 ... So, it's really the question is, are these things only about services, or 14:30:16 Otto Mora: Mmhm... 14:30:16 Manu Sporny: Something else. That's it... 14:30:19 Otto Mora: So… Oh, wait... 14:30:22 Joe Andrieu: Um... 14:30:40 ... Yeah, I think it… I think, actually, it's probably both on different elements, uh, Manu, in that I think we're gonna use the data that we have back, the data in the DID URL, the data in the DID document, the data in the metadata. To determine the, uh, handler strategy 14:30:44 markus_sabadello has joined #did 14:30:50 ... And then, they… they use the resource bar is invoke the handler, right? So you're gonna execute the handler. Um, so 14:30:54 ... I think it's… it's just two different steps 14:30:59 q+ 14:31:03 ... That's it 14:31:04 Otto Mora: Perfect... 14:31:07 ack both 14:31:07 present+ 14:31:07 Joe Andrieu: Right. So figure out the strategy and then find a handler that can execute that strategy... 14:31:12 Otto Mora: I think I know what you're relating to. The both thing ended up on the queue... 14:31:14 Joe Andrieu: That was me, sorry... 14:31:15 ack manu 14:31:16 Manu Sporny: Yeah, I mean... 14:31:19 Otto Mora: I don't know how that happened. Anyways. Yeah. It's interesting. I've never go ahead... 14:31:31 q? 14:31:32 Manu Sporny: I guess a plus one, Joe, to what you said, um… do we feel like we have enough language to kind of work it out in the PR at this point, or do we feel like it's gonna… Leave the conflict... 14:31:36 ... In the PR 14:31:40 bigbluehat has joined #did 14:31:41 q+ 14:31:49 Joe Andrieu: Just off the queue. I think it feels good to me. Steven, do you think you could write it without confusion?... 14:31:56 Stephen Curran: Um, yeah, I can certainly take a try at it, and I think this has been helpful. I think, um... 14:32:04 ... to clean it up a little, we'll see, but I've certainly not been able to do a PR without tons of controversy before, so 14:32:08 ... Oh, wait! No, I did one the other day that was very uncontroversial. So okay, I'll try 14:32:10 present+ 14:32:11 Otto Mora: Okay... 14:32:13 ack Wip 14:32:14 Stephen Curran: And... 14:32:15 Otto Mora: The… the big ones are definitely easier, but yeah, when we get into the details, that's... 14:32:16 Stephen Curran: Yeah... 14:32:19 Otto Mora: Well... 14:32:40 Will Abramson: Uh, yeah, so, I mean, maybe last point on this, then we can move on to a different discussion, but, um… I just wanted to… seems like we all have clarity, but maybe people could just tell me, then, the five steps. I mean, I really… I'm looking for step three and step four. What do we call these things? Currently, we call 14:32:40 them... 14:32:44 q+ 14:32:45 q+ determine handler strategy, invoke handler 14:32:50 ... Determine retrieval strategy, I'm hearing. That's gonna change to maybe determine path handling, and then retrieve the resource would be. Execute handler 14:32:53 q? 14:32:54 ... Question mark 14:32:55 q? 14:33:00 ack swcurran 14:33:02 Otto Mora: Mm-hmm. Um… Stephen?... 14:33:02 q- 14:33:07 Stephen Curran: I'll defer to Joe, because I think he's saying what I'm gonna say, so go, Joe... 14:33:12 Otto Mora: Go ahead... 14:33:17 Stephen Curran: Oh. Perfect... 14:33:23 Joe Andrieu: Sorry, I was muted. I think, well, let's just determine a handler strategy and then invoke handler become the names for four and five. If I got my number in right... 14:33:26 Will Abramson: Yeah, both... 14:33:29 q? 14:33:29 sounds good to me 14:33:32 q+ 14:33:32 Otto Mora: Okay. Yeah. Go ahead. I think that... 14:33:37 ack swcurran 14:33:38 ... Yep, analysis, yeah. Hopefully you have… Steven? 14:33:41 Stephen Curran: Okay, I do have one more... 14:33:44 ... Remembering, as well, that 14:33:53 ... you know, we can define things in this, you know, the URL, the referencing section, but when a 14:34:14 ... So, I think… um, a, uh, client, if you will, retrieves just the DID doc, they still can do all they want with that DID doc, but, you know, they're gonna… we're gonna want them to do it in the same way as if they had added a DID URL and referenced a specific service they want to use, and so on. Um, you know, this idea that we're 14:34:31 ... doing specific things, the specs underlying what that service type means, how you're supposed to use it. Those are equally important. And so we do need to stress to the community when you define an extension 14:34:46 +1 to raise the awareness for defining handling strategy 14:34:47 q? 14:34:49 ... Here's the good practices in doing that. And as well, putting certain things into the resolution spec that we want to be handled very consistently across all implementations. I think those are sort of things we should think about as we go forward on this. That's it 14:34:54 ack JoeAndrieu 14:34:55 Otto Mora: Uh, Joe? Uh, yeah... 14:34:56 Joe Andrieu: No, that was just a plus one... 14:34:59 Otto Mora: Oh, okay... 14:35:07 ... Okay, great 14:35:10 ... Uh, next topic was, uh 14:35:15 Topic: Continue discussion on DID Resolution Algorithm Inputs 14:35:17 ... the actual… I think it's the actual inputs… um… to the 14:35:29 ... algorithm, right? I guess that's sort of, I think, the next big one. I don't know, Joe, if you wanted to first touch upon that, maybe. Just generally, I think we 14:35:32 q+ 14:35:32 ... There was a conversation about that last week, right? 14:35:35 Joe Andrieu: Sure... 14:35:37 Otto Mora: Whether it was a video or a rail or a vehicle... 14:35:40 Joe Andrieu: Sure. So... 14:35:48 ack JoeAndrieu 14:35:48 ... Right now, we have, um, Resolve taking a DID 14:36:04 ... Um, and we have, in my view, unfortunately, taken all the parameters that were in the DID and forced the client to process them, and then pass them back as options. And I think that step is a step we can get rid of, and it is a step which creates the possibility of 14:36:09 ... Bugs and errors, um, and, and confusion 14:36:20 ... And I don't think it creates any real value for us. Once we acknowledge, and this was actually fairly early on. that version ID and version time 14:36:26 ... Must go to the resolver because it could affect the selection of the did documents 14:36:40 ... Um, so I think… I think we should clean that up and make it… So that we are doing the the least amount of processing on the client as possible. Then really we've we've never been resolving just dids even though we spoke about it that way 14:36:54 ... And I think the most we can reduce it to is to strip off the fragment. Like, I think we're all in agreement that you don't send the fragment to the resolver, just like you don't send the fragment to the web server 14:37:09 ... But I'd very much like to to not do any other processing on the client if at all possible for most of the use cases is just send that whole did URL to the resolver with the information that you need if the client has. reasons or, um 14:37:18 q? 14:37:30 ... reasons to override any of those properties or to add properties that aren't there, such as you have a DID URL that doesn't have a version time, and your VC is of a particular time, and so you want to bound resolution to that version time, then the client is the one who understands that, and they can certainly 14:37:43 q+ 14:37:44 q? 14:37:45 q+ 14:37:47 q+ 14:37:48 ack Wip 14:37:49 ... in the mechanism that we've, you know, sort of modeled after the HTTP headers, we can add an option that, uh, lets that sort of version ID parameter get passed. I think that's still, you know, uh, positive. But I'd really like to get rid of that, um, what feels to me an extraneous processing loop on the client side 14:37:53 Otto Mora: Uh, yes, Will?... 14:37:57 Will Abramson: Yeah, I just wanted to say, like, I don't think we're gonna be, um... 14:38:01 q+ to agree and that our resolver will be implementing accepting full URLs 14:38:09 ... Actually, it doesn't matter, I won't say that. I think I'm broadly in agreement with this approach. I think I agree that 14:38:25 ... the like. it makes the client's work simpler. I'm just thinking, like, when I'm doing DigiURLD referencing, I guess the client only cares about the query parameters that it knows about, right? So it only needs to process the ones that it knows how to process, and all the others it just would ignore 14:38:35 ... Is that right? I think that makes sense to me. And also, I wanted to add, I think we're saying that if the client does specify options 14:38:35 q- later 14:38:39 +1 to options overriding 14:38:41 ... then those options override any options that are also in the URL. But that is 14:38:45 ack markus_sabadello 14:38:48 Otto Mora: Okay, uh, I see Marcus is next... 14:38:53 ... Marcus 14:38:56 Markus Sabadello: Okay, yeah, as I said before... 14:39:06 ... I'm really against making this change. I think it's not backward compatible. It's a huge breaking change to change the inputs of the 14:39:22 ... of the function, um, that would break a lot of existing implementations and existing DID methods. We've always been telling people that we resolve DIDs, we don't resolve DID URLs, we resolve DIDs 14:39:27 ... And the result is a deep document and that's as simple as it can possibly be. Didn't really understand 14:39:37 ... chose explanation of how what the client would do instead or how 14:39:38 So how do we deal with versionTime? 14:39:40 ... how this is problematic or how it would change 14:39:46 q? 14:39:49 ack manu 14:39:49 manu, you wanted to agree and that our resolver will be implementing accepting full URLs 14:39:50 ... But I think it would be a big mistake to make such a breaking change 14:39:54 Otto Mora: Mano?... 14:40:17 Manu Sporny: I guess a couple of points. Plus one to what Joe said, I think the feature is not really buying us anything. I know that our implementation will, our resolver implementation will support DID URLs being passed in its entirety... 14:40:18 s/Mano/Manu/ 14:40:23 ... Uh, and the driving reason for this is that, you know, we're looking at, kind of, the interface and developer 14:40:37 ... uh, developer experience. Um, and, you know, when… if we just look at HTTPS, like, we pass the entire URL. Most clients pass the entire URL 14:40:39 q+ 14:40:48 ... to the libraries that we use today, including fragments, right? I mean, like, developers typically just, like, shove the entire URL in there, they don't do any kind of processing, and they expect to get back 14:40:54 ... you know, something reasonable, and I think we should follow the same pattern that, you know, has been established 14:41:11 ... on the web for many, many years now. Okay, so that's point one is that, you know, our resolver will implement this. We think it's good for, and by we, I mean, you know, Digital Bazaar 14:41:20 ... thinks it's good for the developer experience, so the developer doesn't have to think about, like, processing all the query parameters, and which ones they understand, and which ones they don't. You could just throw the whole thing 14:41:32 +1 14:41:34 ... Uh, at the… at the server, and we do expect people to not even strip the fragment identifier off of there. They're gonna, you know, they're gonna pass to the library, hopefully the library strips it out. Um 14:41:45 ... Uh, before sending it up to the server. Um, okay, so… and, and, you know, to get through REC, all we need is another implementation to do that, and we've got, kind of, demonstration of, of interop, uh, on that 14:42:04 ... So that's the first point. Second point, uh, is this a breaking change? Uh, no, I don't think it is. Uh, we defined an abstract interface and did core. Um, we were not allowed to, like, you know, specify, you know, what, uh, what the concrete, you know, interface was. It was outside of our charter 14:42:22 ... Uh, did resolution has not met 1-0, we can break anything we want to in the spec, right? I do think Marcus has a point in that, like, people have implemented this, um, but all of the people that have deployed this into, uh, you know, the, the, the world and have clients that implement it, they're just sending up 14:42:37 ... DIDs with options. So that's not gonna break, right? That… that will continue to work, even in the… even in the new things. The… the danger here is that those resolvers might get a DID URL… DID URL in, and they're gonna have to do something, but 14:42:42 ... I don't think it is a it's it's a tall ask 14:43:02 ... to ask those implementations to update themselves, because they're going to be updating themselves anyway to make sure that they're in line with the DID resolution specification, and we're not talking about a tremendous amount of work to, you know, update those things. So, I think for those reasons, it's fine to make this change 14:43:16 ... disagree pretty strongly with the… with the notion that, you know, it's a breaking change in the spec sense, um, and I think, you know, we should give, you know, DID… DID implementers, DID resolver implementers 14:43:20 ack markus_sabadello 14:43:22 Otto Mora: Mm-hmm... 14:43:24 Manu Sporny: uh, you know, some credit here, they'll… they'll update their implementations. We're not asking them to do something that's really difficult to… to change, right? Um, that's it... 14:43:27 Otto Mora: Marcus?... 14:43:41 Markus Sabadello: Uh, to comment about the analogy with HTTP and, uh, and the web, uh, I know that in HTTP you pass the path and, uh, and the query, but... 14:43:48 ... When you resolve it. That's dereferencing, that's not resolving, so in my mind, saying that 14:44:06 ... did URL, and you passed a path and the query in the resolution process, to me, the analogy would be a little bit like passing a path and a query to a DNS resolver, right? When you dereference an HTTP URL, then the first step is resolving the domain name to the IP address 14:44:10 ... And you wouldn't pass the path and the query to the DNS resolver 14:44:14 ... And so in TEEDS and TEED URLs, we've always had the same 14:44:15 q+ 14:44:23 ... kind of separation, where resolving the… the DID means to… to resolve the DID, and then, uh, the URL and the path is, uh 14:44:28 ... is then the dereferencing process, which comes after that, and then 14:44:43 ... Really surprised to hear that these things are changing now. I think some of the other working group members have been arguing for a long time that the deeds should just be about 14:44:47 That analogy breaks with versionTime 14:44:51 ... getting the deed document, and getting the public keys, and the service endpoints, and everything else should be a separate step. That's the 14:44:54 s/And so in TEEDS and TEED URLs/And so in DIDs and DID URLs/ 14:44:56 q+ to say the deep dive on these matters is what we were chartered for 14:44:58 ... That's the separation, that's the layering that we've always had, and in 14:45:13 ... I mean, that did one recommendation. We have defined these interfaces, so I don't really understand either why it would not be a breaking change, because we have these functions with inputs and outputs 14:45:20 ack manu 14:45:21 ... Already in the in the recommendation, not just in the in the TD resolution draft and everybody has been implementing that for a long time 14:45:25 Otto Mora: Okay. Um, I believe, yeah, Manuel... 14:45:44 Manu Sporny: Yeah, I think the, and Steven said this in the chat channel, where the HTTP URL analogy breaks down is that we have included things like version time and a bunch of things that affect resolution, right? Like that's why... 14:45:56 q+ 14:45:59 ... all of a sudden it matters. You know, when you do, like, a DNS query and a DNS resolution, like, the HTTP URL query parameters don't come into play at all, right? Um, however, with our spec, it does, for better or worse, and that is why 14:46:12 ... you need those things to be passed through, and whether they're passed as options, or whether they're in the URL, passed as a URL parameter, they are used by the resolution process 14:46:30 ... And again, to push back on the whole, like, you know, this is going to break things and people are going to be surprised. Like, I think we're not giving implementers enough credit. Like, this is not a difficult change to make in their libraries 14:46:45 ack JoeAndrieu 14:46:45 JoeAndrieu, you wanted to say the deep dive on these matters is what we were chartered for 14:46:46 ... you know, not gonna break, um, uh, I don't think it's gonna break the ecosystem in any kind of significant way. And if it does, we'll hear about it, right? But I don't think that's gonna happen. And that's what, you know, CRs, CRs for, uh, is to get that, to get that feedback. Uh, that's it 14:46:49 Otto Mora: Okay, thank you. Joe?... 14:47:11 Joe Andrieu: Uh, yeah, I want to talk to the breaking change aspect as well. Um, I do think in the first round of our work, when we came up with DidCore, we were… we explicitly avoided the deep dive on the protocol that would be resolved. We called it a contract, not even an API... 14:47:26 ... And I think that this group was chartered specifically to do this kind of deep dive. Now, I appreciate that it's frustrating that it took this long for the working group to get enough eyeballs on the spec to understand 14:47:38 ... you know, where we might want or need to change some of these things. Um, but we've made quite a few changes once we've gotten to this point in the conversation. And so I think what matters more right now is having a coherent 14:47:45 ... Spec that implementers can understand and implement easily. And I think 14:47:50 ... Since we haven't even gotten to candidate rec yet. Believing that breaking software that's out there is, you know 14:48:05 ... a crime or malicious or otherwise sort of negative, I think anyone who has implemented the spec today should be well aware that this is not yet standardized and that it will change. In fact, I would bet that this specification says that itself 14:48:20 ack markus_sabadello 14:48:20 ... Uh, are already out there in the field. Um, and the status of this document. So, uh, I think we should figure out if it doesn't prove anything, and make a decision, regardless of whether or not it's a breaking change, to certain implementations who 14:48:25 Otto Mora: Practice... 14:48:39 Markus Sabadello: Again, I agree that whatever we have in Peach Resolution was never a standard, and everybody has to be aware and has to expect that things might break or might change... 14:48:44 ... in the in the did resolution specification. But it's a it's a fact that in the in the did core 14:48:52 s/Practice/Markus/ 14:48:57 ... one standard, we defined a resolution function, which takes a DD as an input, and it doesn't take a DDRL as an input. We even defined. Error codes, um 14:49:03 ... Yeah, that, uh, like, the invalid deed error code, right? So today, if you 14:49:09 ... If you invoke a resolver that's conformant with 1.0.0 14:49:20 ... and you pass a DTURL, then a conformant resolver would return an error that says invalid DIT, because a DTURL is not a valid DIT, and if we change that, we 14:49:28 ... I don't know, what does that mean? It means we're defining a new resolution function that takes a different input and behaves 14:49:30 s/the invalid deed error code/the invalid DID error code/ 14:49:35 ... differently, I… I don't get how that would not be a breaking change, and I… Don't get how 14:49:41 ... how it would simplify anything if we 14:49:50 ... if we say now we define a function that takes a DID URL plus options as an input, how would that be simpler than passing a DID plus options, say? 14:49:52 q? 14:49:55 ... I really don't understand the explanations 14:50:02 q+ 14:50:06 ack Wip 14:50:10 Otto Mora: Uh, Will? Yep... 14:50:13 Will Abramson: Sure, um... 14:50:26 ... Yeah, Marcus, I do appreciate that you don't understand the perspective, but I think, well, the simpler approach is that me, as someone who comes across bids in the wild and did URLs 14:50:40 ... no longer needs to worry about passing those DID URLs, I can just pass it to a DID resolver through a standard interface, and get back a DID resolution result. And only then 14:50:46 q+ 14:50:46 ... do I need to check the DID URL to see if there are any query parameters in there that I understand? As a, you know 14:50:58 q+ 14:51:03 ... I think that is simpler. I agree it changes the abstract interface that we defined in did core, but I don't think that is an argument that this is a spec breaking change really. Like I think there was no tests against that interface. It was just a 14:51:07 ... A placeholder for this work, which is the work of defining the 14:51:20 ... way that we do digit resolution and digit URL dereferencing, in my opinion. And I also speak as an implementer who has developed a library that does digit resolution 14:51:24 ... I would be happy to make this change, I don't think it's gonna be, uh 14:51:34 ... Much effort on my part. And I ought to think like other implementers who don't want to make this change, I think they're still going to to work 14:51:47 ... Like, like, DIDs are DID URLs. The only thing that will fail is when people are expecting resolver interfaces to support DID URLs, and they don't yet support them. And I think if you're not willing, if those influencers aren't willing to support them, make it at least 14:51:52 ... Well, they will throw an arrow, won't they? They'll throw, like you said, invalid did error 14:51:58 ... um… I don't think it's a huge failure date 14:52:04 ... I also think, like, the invalid did error message is 14:52:12 ... is for, like, or should be for, when the DID itself is invalid, not when the DID is a DID URL 14:52:23 ... I mean, it's a side comment, but I think, you know, like, that is kind of misleading, because a DID URL contains a DID, and that DID might be valid. I'd rather know if the DID itself is invalid 14:52:28 q? 14:52:38 ... Anyway, last thing I'll say is Marcus, what everybody really, we as a group need to make a decision against this. I agree that there is strong feelings on both sides, but tomorrow, I hope you're going to be able to join us because we will be running a 14:52:42 ... a poll, and, like, documenting this decision, and moving forwards, because this is taken 14:52:55 ... I mean, there's been a lot of discussion going on, but this is the last thing that we need to get through that discussion and finalize, you know, getting to finalizing the spec, right? We're already a month over our charter 14:53:04 ack markus_sabadello 14:53:04 ... Um, we have 5 months left, we really need to be wrapping up the spec, you know, getting to final review, and, like, tidying, just on tidying up 14:53:06 Otto Mora: Mm-hmm... 14:53:07 Will Abramson: That's all... 14:53:10 Otto Mora: Marcus?... 14:53:13 Markus Sabadello: Okay... 14:53:22 ... Okay, I wanted… I'm trying to understand the argument about making it easy for a client if 14:53:38 ... if I understand correctly, the idea is that if you pass the… if you pass the whole DTURL to a resolver, it makes everything easier for the client, because the client wouldn't have to parse the DTURL and understand. certain parameters, but 14:53:48 Right now, they have to convert all parameters into options. 14:53:48 ... But I don't see how anything in the current design. Makes this hard for clients, because if you want to 14:53:59 ... deal with… if you're dealing with DDRLs, then you can do exactly what you just said. You just pass the DDRL to a dereferencer, right? If you 14:54:09 ... if you're dealing just with deeds, you… as a client, life is easy, because you can pass the deed to a resolver, and if you're dealing with deed URLs, then 14:54:21 ... life for a client is also easy, because you pass it to a dereferencer, which does not have to be a remote service, right? Just to… just to explain that again and again, nobody says that a dereference is an external 14:54:22 q+ to say it creates a threat we can remove 14:54:26 ... remote service with an endpoint or anything that the reference I can also trust the 14:54:27 q? 14:54:32 ... a library. But again, if you're if you're worried about developer experience, then 14:54:39 ... Then yeah, use a dereference library, pass the entire DPURL to a dereference library, and 14:54:48 ... And your application doesn't have to… do any complicated processing. I think that's already… In the specification, I 14:54:55 ack manu 14:54:56 ... Just don't get how this is an argument for… for making the change about the. The resolution function 14:55:00 Otto Mora: I know... 14:55:20 q+ 14:55:25 Manu Sporny: Just real quick on that point, Marcus, from a developer experience perspective, if I'm using a client, I don't want to have to think about all of the different parameters that might come into play and might need to be split out and might need to be put in options because I don't have all of that knowledge in my head... 14:55:29 zakim, close the queue 14:55:29 ok, ottomorac, the speaker queue is closed 14:55:42 ... It is not something that as an application developer I want to be exposed to. I just want to shove a DID URL into the library and have it do the appropriate thing. Unfortunately, I think we're starting to repeat ourselves now. The thing I put myself on the queue for 14:56:08 ... is to look at DID version 1.0, right? This is the resolution section. And, you know, this is going back to the is this a breaking change or not? We we do explicitly say their exact implementation is out of scope for this specification. So we define the inputs and outputs DID resolution URL exact implementation is out of scope for this 14:56:08 specification 14:56:23 ... We also say that, you know, details of how this process is accomplished outside of the specification. We do say, you know, all conforming resolvers implement the functions below, but we also say they have the following abstract forms 14:56:43 ... Right? Like, this section was a massive hand wave, and I know all of us can remember that it took… we had formal objections because it was so abstract. The formal objections were basically, you guys have not properly defined this, right? And so, again, like, is this a breaking change? 14:56:52 q? 14:56:59 ... no, we had a giant year-long formal objection about how abstract this thing was and how, you know, wishy-washy we were being about, you know, the definition of this stuff. So I'm just pushing back on that point of, like, is this a breaking change? Like, eh 14:57:05 ... I think the only place that argument sticks is with implementations that exist today that did something. Yes, but I think we're saying, like 14:57:27 ... you know, we're… we're trying to suggest to the ecosystem that a better way is to just simplify what applications have to do, application developers have to do, and just have them shove a dead URL at the libraries, um, and then the libraries, or the people that have all of the important details in their head 14:57:33 ack JoeAndrieu 14:57:33 JoeAndrieu, you wanted to say it creates a threat we can remove 14:57:35 ... They're the ones that will parse the URL out and use the appropriate query parameters and so on and so forth. That's it 14:57:38 Otto Mora: Mm-hmm. Cool... 14:57:45 ... You're on mute, Joe 14:58:08 Joe Andrieu: That the client misparses the options. Yeah, sorry, I was muted. I do think we're getting in the territory, repeating ourselves, and we're at the top of the hour, so I'll try and be short. But I want to introduce where this came from was trying to threat model, did resolution, and looking at what the back and forth were between all 14:58:08 the components. And quite simply, there's a threat... 14:58:19 q? 14:58:20 +1 to take the burden off of the client 14:58:21 ... And we have lots of responses that we could do for that. And the response that I favor is don't make the client do that. Like we can completely remove that threat. Um, and that's my motivation. Here. That's it 14:58:27 ack markus_sabadello 14:58:28 Otto Mora: Mm-hmm. And then Marcus has the last word on this. So go ahead, Marcus... 14:58:41 Markus Sabadello: I don't know why any of you think that the client has to parse options or parameters, or why the client needs to decide which parameters it understands or doesn't understand... 14:58:47 ... I fully agree that it should be possible for a client to just pass the DQRL to a library 14:58:54 the current spec requires parsing the query parameters 14:58:57 ... And the current design fully supports that. That's the dereferencing function. So I'm sorry, that's really not an argument for making this kind of change 14:58:59 q? 14:59:12 Otto Mora: Okay, well, I think, yeah, we've laid out both sides, and then… We can meet tomorrow to... 14:59:23 ... Uh, more, uh, take a decision as a group? 14:59:23 ... Thank you all 15:01:12 I have made the request to generate https://www.w3.org/2026/05/27-did-minutes.html TallTed 15:03:59 Wip has left #did 15:09:17 scribe-