14:55:35 RRSAgent has joined #did 14:55:40 logging to https://www.w3.org/2026/05/14-did-irc 14:55:48 rrsagent, make logs public 14:55:54 Meeting: Decentralized Identifier Working Group 14:55:59 Chair: ottomorac 14:56:02 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026May/0046.html 14:56:03 clear agenda 14:56:03 agenda+ Agenda Review, Introductions (5 min) 14:56:03 agenda+ Special topic call summary (5 min) 14:56:03 agenda+ Determine Retrieval Strategy \[1\] (40 min) 14:56:03 agenda+ Next time: Threat Modelling (5 min) 14:56:19 previous meeting: https://www.w3.org/2026/05/13-did-minutes.html 14:56:33 next meeting: https://www.w3.org/2026/05/20-did-minutes.html 15:00:58 present+ 15:01:53 present+ 15:02:45 KevinDean has joined #did 15:02:51 present+ 15:04:27 swcurran has joined #did 15:04:30 smccown has joined #did 15:04:34 present+ 15:05:02 zakim, next item 15:05:02 agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot] 15:05:58 Wip has joined #did 15:06:02 present+ 15:06:10 zakim, next item 15:06:10 agendum 2 -- Special topic call summary (5 min) -- taken up [from agendabot] 15:06:15 Yesterday special topic DID Working Group focused primarily on reviewing PR 331, a pull request introduced by Will Abramson to establish a high-level scaffold for the DID resolution and dereferencing algorithm. The objective of this PR is defines the necessary steps of the process without initially diving into the complex details of each specific sub-algorithm. The intent to unpack specific steps—such as determining retrieval strategies—in subsequent specialized calls. 15:06:24 https://github.com/w3c/did-resolution/pull/331 15:06:42 I have made the request to generate https://www.w3.org/2026/05/14-did-minutes.html TallTed 15:06:49 A significant portion of the discussion centered on Steps 4 and 5, which involve retrieving and using the identified resource. Dmitri Zagidulin expressed strong opposition to these steps, arguing that the dereferencing specification should ideally end at returning a URL rather than prescribing how a client should "use" or "retrieve" the resulting data. However, Joe Andrieu and Manu Sporny countered that providing a framework for these final stages is essential because the DID architecture often involves complex retrieval strategies—such as blockchain-based mechanisms—that go beyond standard HTTP GET requests. They cited RFC 3986 to support the idea that fragment processing and secondary resource retrieval are historically part of the dereferencing narrative. 15:07:04 present+ 15:07:17 q+ 15:07:25 The meeting concluded with a technical debate over terminology and error handling. The group considered adopting a "signal an error" approach for the algorithm to maintain flexibility across different implementation environments, rather than strictly prescribing a return metadata structure. Regarding terminology, members deliberated on the best name for a DID URL that has had its fragment removed. While "Base DID URL" was initially proposed, the discussion shifted toward "Absolute URI" to align with the formal syntax defined in RFC 3986, though some members expressed concern that this term might be confusing for developers. No final decision was reached on the naming, and the group was encouraged to provide further feedback on the PR before the next session. 15:07:44 transcriber-bot, resume 15:07:44 scribe+ 15:07:48 Otto Mora: a bit of that, what that was. So, just wanted to provide that, and then I'll enable transcription... 15:07:54 ... Now, and I see we have Ted, so I'll acknowledge Ted. Go ahead 15:07:58 ... Let me cut 15:08:01 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, just quickly, uh, so you know, those long lines that you pasted into IRC, they're fine for humans... 15:08:06 ... But they won't look right in the minutes when you finish them 15:08:06 ack Ted 15:08:09 Otto Mora: Are they getting cut off, or just completely... 15:08:20 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, well, they'll get cut off, or rather, they'll get wrapped onto a new line, but they won't have the dot dot dot that starts, so… The minutes won't do the right thing... 15:08:25 ... it's easy to clean up if you appear, Antoine can hack on the IRC log later 15:08:28 Otto Mora: Okay... 15:08:28 q+ 15:08:31 ack Wip 15:08:34 ... Okay, um, well 15:08:42 Will Abramson: Yeah, I think the last thing to say, just on that is, you know, if you haven't already, please take a little bit of time to review 331, um... 15:08:42 ack TallTed 15:08:46 ... I mean, I think it's pretty fine 15:08:51 s/you appear, Antoine/you or Pierre-Antoine/ 15:08:52 ... Uh, and hopefully we can merge it soon. I mean, Marcus is having some pushback about this did and did URL 15:09:00 q? 15:09:03 ... question, and I do want to just kind of take that out of this PR. I want to get this PR in, so I'm happy to accommodate him, unless people really think we shouldn't. I think we need to put on the agenda 15:09:08 ... A call, where we are going to make a decision about that, and then just move forward, but 15:09:14 ... I don't want that to derail getting this PR. The only thing I have on them 15:09:22 Otto Mora: Uh, maybe we jump right into the PR? Sound good?... 15:09:26 Will Abramson: Oh, let's jump into the retrieval strategy, I think... 15:09:31 Topic: Determine Retrieval Strategy 15:09:31 Otto Mora: Oh, okay, alright. So… okay, so we just... 15:09:38 ... Determined retrieval strategy, and uh… you have the floor above 15:09:52 Will Abramson: Yeah, actually, I'm gonna… I mean, I was gonna prepare something, but Stephen, uh, messaged me with some good stuff, so I think I will just hand over to you, Steven, and we can go… Steven's got a bunch of examples that we can just talk through... 15:09:59 ... And hopefully get everybody on the same page around, you know, what we mean by this step. Um 15:10:03 ... I don't know, it's a good introduction soon 15:10:08 Stephen Curran: Okay, um, sounds good. Um, so what I did was, um... 15:10:14 ... I'm gonna share my screen and, um, share a presentation so people can see my screen now 15:10:17 Otto Mora: Yep... 15:10:26 Stephen Curran: Um, so, in thinking this through, I thought it would be really good to go through a combination. So, when you get to bid URL dereferencing. Um, you have... 15:10:32 ... A combination of 4 things, any of which may or may not be present 15:10:38 ... Um, you've got a fragment, you've got other parameters, and I 15:10:46 ... Called them other parameters because they would not include those that were relevant to resolution 15:10:57 ... Now, we… I don't know if that… people agree with that, but there… there are certain ones that are, um, like version… version ID, version time, that are resolution 15:11:04 ... parameters, and then there would be other parameters, and so I'm separating those into two groups. There's the path 15:11:08 ... And then there's metadata, so when you resolve 15:11:16 ... A did, a bear did, you get metadata. And that metadata 15:11:25 ... comes into play in dereferencing, and the big example of that is did link resources, DLRs 15:11:30 ... And they are driven pretty much entirely by metadata. They don't 15:11:36 ... um, work on what's in the… in the DID doc, they work on what's in the metadata, so 15:11:40 ... Does that sound good to everyone, that we've got these four things? 15:11:43 Joe Andrieu: What about the div document?... 15:11:48 q+ 15:11:51 Stephen Curran: Good point, the document is always there... 15:11:55 ... How about that? 15:11:58 Will Abramson: Yeah. Yeah, I mean, I think I have this comment too when I was reviewing Steven's thing, um... 15:12:01 Stephen Curran: Okay?... 15:12:04 Will Abramson: I think… I think I agree, the did document is always there, but I… I think... 15:12:08 Stephen Curran: Yeah... 15:12:10 ack Wip 15:12:13 Will Abramson: I think we can still go through this, but I think there is some cases where what's in the did document is going to impact the examples you have here. Yeah... 15:12:18 Stephen Curran: Oh, absolutely. 100%, did not matter. So, this is the style that I wanted to do, which is, I've got... 15:12:30 ... each of these in combination, and I just wanted to make sure, and even today, Will and I were talking about it, it wasn't always clear exactly, and Joe's question right there was 15:12:38 ... was perfect for what I'm trying to get to, is make sure we're… we're all agreeing that, um, here's what happens when this occurs 15:12:45 ... So, in this case, I've got a bear did, no components. The dereferencing outcome 15:12:57 ... I'm hoping I can edit… yeah, I can edit this. So, my plan was to go through these and just say, okay, the dereferencing outcome is a did doc, that's not quite the font I want, but hey 15:13:01 ... Um, hopefully people can see that. The retrieval strategy, I might call it DIDDOC 15:13:12 q? 15:13:13 dmitriz has joined #did 15:13:14 ... And… I don't really have any notes. Any… so, this is the style I want to go through, and they're going to get a lot more interesting as we go through, and if it gets 15:13:17 ... repetitive or doesn't work, we can stop, but, um 15:13:28 q+ 15:13:29 ... Uh, give me a chance to try this and see if this works. So, did Doc as the dereferencing outcome and retrieval strategy as well. Any 15:13:35 ... Any comments on those two, and any notes to add? Oh 15:13:36 ack manu 15:13:49 Manu Sporny: I guess, Steven, I'm… yeah, I'm fine to go through this, uh, process and see where it gets us. Um, what about the, like, the options? Where do we know things like that?... 15:13:50 Presentation Link: https://docs.google.com/presentation/d/1pez4sEyJ11fawmbYKcyjlNQqII3cePbB/edit?usp=sharing&ouid=109116496535883458301&rtpof=true&sd=true 15:13:53 Stephen Curran: Yeah, um, Will and I had that, so I'm glad you called that up. Um... 15:14:00 ... in the URLD referencing, this is… it actually does cause an interesting 15:14:05 ... um, break, if… if the did URLD referencing calls 15:14:11 ... did resolution, it has to pass the options in, so those options have to come from somewhere 15:14:14 q+ 15:14:18 ... As far as I understand it, the options are identical. two parameters 15:14:28 ... Um, so you could express them as parameters or not. Where I think it gets super interesting is what happens if you pass a 15:14:38 ... A… an option that is intended for dereferencing. Um, but… Um, it only 15:14:45 ... it only goes into the resolution part of it. I think that's kind of interesting. Um, Joe? 15:14:51 Joe Andrieu: Yeah, I think this touches a little bit on the did URL, um, dynamic... 15:14:55 ... Um, because I would think you would have the whole did URL available 15:14:57 q+ 15:14:58 Stephen Curran: Hmm?... 15:15:04 Joe Andrieu: But you parsed it out in some weird way that I… I'm not sure why, other than maybe you're following what the current. Uh, Spectus... 15:15:07 Stephen Curran: Sorry, why did you say I've parsed it out in some weird way?... 15:15:13 Joe Andrieu: Because the did URL was not one of the components in your previous slide, you only picked certain options... 15:15:22 Stephen Curran: The did URL contains these things. It contains the did, and these... 15:15:26 ... Potential options, and these additions 15:15:29 Joe Andrieu: It also contains… it also contains the parameters that you excluded in off other param... 15:15:39 Stephen Curran: Okay, so, so, um, you would include RP, what I called RP. So, originally, I had 32 options... 15:15:46 ... Um, I… I deliberately removed, um, RP just to get it down to 16 15:15:53 ... But I get your point, that RP is, um… so, I call those resolution parameters 15:16:01 ... and agree that those would probably come through to did URLD referencing, although I can think of a way 15:16:09 ... We could make it easier on the world by excluding those from the rest of the referencing. But 15:16:12 markus_sabadello has joined #did 15:16:16 ... Um… these are exactly the types of things I'm trying to tease out in this conversation 15:16:24 ... Um, so, uh, good that you raised that. I agree that, um, and I was very deliberate, obviously, in separating out just not 15:16:35 ... parameters, but other parameters separate from resolution parameters. So, I have deliberately excluded those. As we go through this 15:16:38 Otto Mora: Okay, and then Manu has a handout... 15:16:39 ack manu 15:16:41 Stephen Curran: Yep... 15:16:46 Manu Sporny: Um… let's see… sorry, now I'm… I got... 15:16:53 ... distracted by, uh, something that was said. I guess I'm 15:16:55 present+ 15:17:11 Stephen Curran: Yes... 15:17:16 Manu Sporny: I'm… so we… yesterday, we talked about, like, these five things, and when we're talking… when you're talking about, Steven, this framework, are you talking about this framework within the framework we talked about yesterday? There are five things, and did URL difference is the… what was it, the fourth thing, or the… Third 15:17:16 thing, I forget... 15:17:19 Stephen Curran: It… well, what I'm… what I'm trying to tease out is what are the retrieval strategies?... 15:17:28 Manu Sporny: Okay, that's fun. I'm just trying to… I'm trying to understand, like, the mental model of what we're going through, so… so we're not talking about... 15:17:33 Stephen Curran: Nope... 15:17:37 Manu Sporny: Uh, step one, preparing for resolution, or step two, resolution. We're talking about steps 3, 4, and 5?... 15:17:40 ... Okay, thank you, that's very helpful 15:17:43 Stephen Curran: Yes. And, and… and it… sorry, and yeah, and so... 15:17:51 ... We've already done resolution. We have the did doc, which Joe pointed out is not listed here, but it will be in all of them 15:17:55 ... We have metadata, which comes from doing resolution 15:18:05 ... Um, we've removed, rightly or wrongly, the resolution parameters, and we have the rest of it left. I left fragment in, Joe, um 15:18:14 ... Will suggested maybe leaving Fragment out, but I think if interplay with other things is kind of interesting, and I, again, wanted to tease out some things, so I left it in 15:18:14 q- 15:18:24 ... Okay. If we just have a fragment, um, again, I think our answers… and if somebody else could take notes in here and do this, that would be helpful 15:18:27 Otto Mora: Mm-hmm... 15:18:30 Stephen Curran: Um, did dock and the retrieval strategy would be the same, did doc... 15:18:35 ... I would highlight that we always use, sort of, a VM 15:18:44 ... uh, a verification method in the examples, but it can be any JSON LD. Um, ID 15:18:50 ... I believe that is correct, that I could put a service in here, hashtag files 15:18:58 ... and I would be referencing a… a service. With the identifier files 15:19:02 ... Everyone agrees that it's not always just the VM that I'm dealing with 15:19:14 ... Okay, and retrieval strategy is in both of these did not 15:19:24 ... And then, um, the note would be something like, um 15:19:31 ... Uh, result is expected to 15:19:40 ... I'm sorry, uh, the caller? I don't want to use another term. What am I going to call? Client? 15:19:44 ... Is expected to focus on the 15:19:51 q? 15:19:56 ... Identified node of the DIDOC. That would be, for me, the note that would go in. Okay 15:19:58 ... Um, now we have a 15:19:59 Will Abramson: I think Benjamin's got his hand up. Oh, he did have his hand up... 15:20:00 Stephen Curran: Yep... 15:20:03 Will Abramson: Do you have his number?... 15:20:11 Benjamin Young: Yeah, I did. It's… it's fine. It was about the fragment identifier thing, um, which maps to the media type. So, for Jason LD... 15:20:14 ... Um, yeah, it can be any… any subject, as 15:20:17 Stephen Curran: Good point. Oh!... 15:20:24 Benjamin Young: As Steve was saying, but, uh, if the media type is different, then. That should probably be called out somewhere, that... 15:20:27 ... You're gonna lean on the foundational 15:20:31 ... you know, the thing you inherited from, which would be JSON LD 15:20:31 Stephen Curran: Um... 15:20:34 Benjamin Young: In this case... 15:20:37 Stephen Curran: So, um, this is... 15:20:43 Benjamin Young: If you were doing application JSON as a response type, then you would not have that, because there's no knowledge of. identifiers... 15:20:47 Stephen Curran: Okay... 15:20:51 Benjamin Young: So it's… it's… it's a… it's a media type thing that might need definition. Um... 15:20:54 Stephen Curran: Okay... 15:20:59 q? 15:20:59 Benjamin Young: But it is dictated by the response type, because clients should have all that in hand before doing anything with a fragment... 15:21:03 Stephen Curran: Yeah, that's really interesting... 15:21:11 ... Okay, I'm really sorry about the format of this, I generated it, obviously, and it's a crappy format 15:21:20 ... Okay, um, here we have a service type files, um… The referencing 15:21:29 ... outcome is, to me, it is the same as the previous, in that I'm gonna get a DIDDOC back and focus on the service type 15:21:29 q+ 15:21:31 q+ 15:21:40 ... Actually, I'm asking that. Um, I'm gonna circuit… focus on the service type identified by file, so it's as if I had just done hashtag file. But that would 15:21:44 ... eliminate Benjamin's comment, because it would 15:21:47 ... focus specifically regardless of JSON LD 15:21:54 pdl-asu has joined #did 15:21:55 ack manu 15:21:56 ... Um, still did, doc, is the dereference outcome. Um, really looking for comments here from others 15:21:59 Otto Mora: Okay, so Manu was first, Will, and then Ben... 15:22:04 present+ 15:22:08 q+ 15:22:13 Manu Sporny: Um, I mean, the dereferencing outcome… well, I don't like this feature. I think we should remove it. Um, I… I know we put it in there... 15:22:25 ... a while ago, but it really doesn't feel like it's, um, very useful. Uh, I'm sure there are use cases for it, but, like, it complicates things, um 15:22:26 bigbluehat has joined #did 15:22:29 ack Wip 15:22:44 Will Abramson: Um, yeah, I don't know. I wondered, I think really what you're meaning here, maybe I'm just gonna edit this, is, like, service, not service type. Okay... 15:22:46 q+ 15:22:46 present+ 15:22:46 ... Yeah. Okay 15:22:49 Stephen Curran: Nope, nope. I definitely wanted service types, because it brings up the second point, which is what happens if you have two of them. So, yes... 15:22:55 Will Abramson: Yeah, yeah, sure. So, service type… yeah, so, I mean, maybe then I'll just change this to file service, because that kind of confused me... 15:23:06 ... Um, but I wanted to talk about this, how it contrasts with, like, Joe's version, like, I think, I mean, I see Joe's on the queue now, but… when I read Joe's PR 15:23:14 ... For him, this would turn into, like, a retrieval strategy based on the service. That is identified here 15:23:18 ... Rather than in the current spec text 15:23:27 ... it is DidDoc as a retrieval, and you are targeting specific, you know, like, I think maybe you're, like, filtering the services. In that document, based on the service type 15:23:32 ... I don't have a comment on which way it should be, but that's the current two proposals 15:23:38 Stephen Curran: Yeah, that's what the current spec does, is it would filter it onto that, and then depending on the accept type. It would either be a... 15:23:43 ack bigbluehat 15:23:47 ... the URL, or… I don't know what… anyway, I modified the document. Um… Who's next? 15:23:51 Otto Mora: Uh, Ben was next, and then, uh, Joe, and then Marcus... 15:23:59 Benjamin Young: Thanks, I'm on IRC now. I'll use the proper cue. Um, yeah, you said Steven a bit in passing about... 15:24:12 q+ 15:24:12 ... Uh, this being like the fragment thing I mentioned, um, it would not be, however, because it's a query parameter format, so this is a… Kind of a different animal. Just wanted to call that out 15:24:17 Stephen Curran: Agreed it's a different animal, but what is the result? Is it… is it the same?... 15:24:20 Benjamin Young: Yeah, so… as… right... 15:24:23 Stephen Curran: Or… or is the result actually different? That's what I'm trying to tease out... 15:24:37 Benjamin Young: Yeah, as you just discussed it, I think it's been… Seen as a, like, filtering mechanism. On the… on the DID doc. To, like, sub-select in some… strange-ish way, um... 15:24:40 Stephen Curran: Exactly... 15:24:43 Benjamin Young: And that… and that… that pushes it… I mean, by design, as... 15:24:50 ... written here, it's a… it's a quote-unquote server-side action. It's a… it's a query parameter, so 15:24:57 ... Historically, those are used in the, like, sub-resource, uh, mental model. Um 15:25:03 ... But I, you know, whether or not that's wanted, whether or not that's a good idea, I don't know. But if you were to 15:25:06 ... do the same thing with the fragment. It does 15:25:11 Stephen Curran: Yes... 15:25:14 Benjamin Young: It would look different, but it would answer the question about who's doing what, when, and what to respond with, which would be the entire document... 15:25:23 ... And then the… whoever's receiving the entire document may or may not use that fragment identifier to. Do whatever that thing is 15:25:30 ... That thing being the fragment identifier wants to do, or is pointing to. Whereas here, this is all, like 15:25:34 ... Pushed to the quote-unquote server. Um 15:25:39 ... And the response is gonna be up to the server for how it implements that 15:25:46 Stephen Curran: Which I read as up to this specification to say... 15:25:48 ... Um, Joe. I think Joe… oh 15:25:51 Benjamin Young: Yeah, for sure, but it's more like API design. And then, yeah, I'll show you... 15:25:54 Stephen Curran: Yeah, yeah, agreed... 15:25:57 Otto Mora: Okay, Joe?... 15:26:02 q? 15:26:06 Joe Andrieu: Yeah, I think that the dereferencing outcome here is. A resource... 15:26:13 ... Retrieved from one of the service types that have file service. Um, as a type 15:26:18 ... According to the retrieval strategy defined by file service 15:26:24 ... And if there are multiple, we have two options 15:26:29 ... Either you let the dereferencing client here, um, pick one 15:26:33 ... It has the DID document, has all the metadata, it knows 15:26:40 ... why these different things, uh, differentiate themselves, at least to the extent that the TID document enumerates those differences 15:26:50 ... Um, and so they could pick one, so we could enable that sort of round robin issue. I have one issue with that, but that is one way to think about it. The other is to just have an error, if there are multiple 15:26:58 ... Um, my concern about the round robin is today we don't have a way to indicate 15:27:03 ... That multiple service endpoints should be seen as logically, um 15:27:09 ... Uh, pointing to the same resources. So you might… right, a naive, uh 15:27:15 ... use of the DID document could put in multiple service endpoints, all of which return on the… whatever 15:27:21 ... file services algorithm is. Um, but they are not intended to be the same resource 15:27:29 ... Right, I have one file service that has all my pictures, and one file service that has all my. Um, uh… audio 15:27:35 ... And those two really aren't interchangeable, so treating them in a round-robin way is probably 15:27:42 ... Um, not the right model, but we could add something like a group ID, just to make something up, I don't think it's the right term 15:27:50 ... Um, that could say that, hey, these services are all equivalent, and they are meant to be treated as equivalents, and then I think that makes it easy 15:27:59 ... or easier, at least, for the client to figure out, hey, which of these should I dereference? Um, which of these should I retrieve, I should say? 15:28:05 ... Um, but I think it would be simpler if we just say, hey, if you get back multiple services, that's an error 15:28:10 ... But I can appreciate this other use case, it's sort of like a round-robin DNS kind of pattern 15:28:16 Otto Mora: Mm-hmm... 15:28:18 ack markus_sabadello 15:28:21 ... A… uh, Marcus? 15:28:37 Markus Sabadello: Uh, yes, in the current algorithm, the service type, and also the service parameters, they essentially filter the services in the document, as others have said... 15:28:42 ... Uh, so this would select the services with the type of file service 15:28:50 ... from the T document. In the current algorithm, you can also use both together, so you could use service if you want to 15:29:01 ... identify a service with a specific ID, and you could add service type if you want to make sure that it's also the type that you want 15:29:06 ... And what you get, then, is that the document filtered by those 15:29:15 ... service IDs and service types, and the result of dereferencing this would depend… in the current algorithm would depend on the 15:29:21 ... the accept option, right? So there's a dereference option called accept 15:29:30 ... where you specify the media type that you want to get back, and uh… what… and that could be a DID document, so the 15:29:37 ... result of the referencing could, uh, dereferencing this could be the document with just the filtered services 15:29:43 ... Or there's also the case where you want to get a list of your rice, right? If the accept option is 15:29:47 ... text slash URI list, then the result of this would be a list of 15:29:51 q? 15:29:55 ... of your eyes. And then… and then after that, the client, or the caller, or the application 15:30:01 ... Or whatever we want to call that, we'll do something application-specific or service-specific 15:30:06 ... with the… with the service endpoint, right? It could 15:30:18 ... it could download a file over HTTPS, it could initiate an OpenID Connect flow, it could 15:30:18 ... look up something from the Bitcoin blockchain, in the case of a Bitcoin 15:30:22 ... URI. But, uh 15:30:29 ... Yeah, in the… in the current algorithm, as I said, the outcome of this depends on the… The accept option 15:30:40 Stephen Curran: Okay, so that's… just to highlight before anyone continues, Joe and Marcus gave very different answers. So, Joe said it's the resource... 15:30:42 q? 15:30:43 ... That is referenced by the service 15:30:47 ... Marcus said it's a DidDoc filtered 15:30:52 q+ 15:30:53 ... or a list of URLs from the… from the selected service type. Very different 15:30:53 ack manu 15:30:56 ... Otto, back to you for managing the queue 15:30:59 Otto Mora: Alright, uh, that's my new next... 15:31:12 Manu Sporny: Yeah, I mean, a plus 1, I can see how, you know, what Joe said or what Marcus said could be the result of. You know, the algorithm that's… that's run... 15:31:17 ... When you have this, um, type of query parameter, um 15:31:29 s/Alright, uh, that's my new next/Alright, Manu next/ 15:31:32 q+ 15:31:37 ... it feels like the application could just do this themselves. Meaning, like, I don't think we're really providing a tremendous amount of functionality that the application couldn't figure out how to do it itself, given it did dock, right? 15:31:48 ... Um, and the question is, like, why are these URLs useful? Like, we are putting a query parameter in here because we're expecting an application to potentially record this or use it 15:31:53 q- 15:31:54 ... Um, uh, when doing a query, it does not seem 15:32:05 q+ 15:32:10 ... it doesn't seem like something that we need to specify for interop in the spec, because at the end of the day, you're just looking for all the file services, right? And if you have the DID document, more than likely an application can figure out how to do it 15:32:17 ... Um, if they know what the… well, I mean, if they have the DID document. So, um 15:32:23 ... Unless someone knows of a concrete use case here, or like a real significant deployment 15:32:30 ... or a… I cannot implement my application without this feature, I think we should 15:32:41 ... Cut it, because we're gonna spend a lot of time talking about what Joe said, or what Marcus said. It's gonna burn time. It's not really gonna have a useful outcome 15:32:46 ... At least, I'm gonna assert, it's not gonna have a useful outcome, because I don't know what the… what the absolute 15:32:52 ... must solve use cases for this… this feature. Um, I'll stop there 15:32:52 q+ 15:32:58 Otto Mora: Give me a second here... 15:33:00 ... Uh 15:33:03 Will Abramson: Joe, do you think you could join IRC?... 15:33:06 ... It's just… complicated 15:33:09 Joe Andrieu: Um, yeah, I thought it was in there, but maybe not. Hold on... 15:33:12 Will Abramson: Well, just with the queue, it's kind of complicated when... 15:33:13 Joe Andrieu: Oh, right, I'm queuing up over there, sorry... 15:33:16 Otto Mora: Sorry, sorry... 15:33:18 JoeAndrieu has joined #did 15:33:19 ack dmitriz 15:33:20 ... Okay, did you want to react, Steven, or did we just go next first? 15:33:23 ... Dimitri 15:33:26 Stephen Curran: No, uh, go ahead. This is a good conversation. This is exactly what I was hoping... 15:33:26 q+ 15:33:30 Otto Mora: Meatri... 15:33:35 Dmitri Zagidulin: Uh, yes. So, a couple of things going on here. One is... 15:33:43 ... Uh, that query parameter is not useful by itself. It was put into the spec to always be used in conjunction with 15:33:53 q+ to say "remove relativeRef" :) 15:33:54 ... relative ref. So, the reason we're, uh… the reason it's complicated, and the reason we're confused whether it's a filtered did doc or a list of URLs, is that 15:34:01 ... It was put in just to be used with relative ref before we had a standardized pathing algorithm 15:34:08 ... So, I agree with Manu that this should be cut. I suspect we'll get pushback from 15:34:16 ... Some folks hear that we should keep it, which is fine 15:34:18 q? 15:34:19 ... Uh, but in that case, just be clear that it's not a standalone parameter 15:34:27 ... But I personally think that, uh, we should drop it and just rely on a standardized pathing algorithm 15:34:31 ack Wip 15:34:36 Otto Mora: Oh, well... 15:34:46 present+ 15:34:49 Will Abramson: Yeah, I… I think I could see dropping it being a good path. I mean, I really liked what Manu was saying around, like, why… why are these dig URLs useful?... 15:34:51 +1 to dropping 15:35:00 ... And I think the answer is these digital URLs are useful when we want to use them to reference the resource that somebody else can then retrieve. Alright, like, I put a URL in my website 15:35:08 ... So that some other client is going to retrieve that resource that I'm referencing. Whereas I think maybe some of these use cases, even when I was managing some of these things 15:35:13 q? 15:35:13 ... It's really just, like, me in my system trying to, like, filter or 15:35:20 ... process the bid document, but, like, I can just do that, and I don't need the spec to tell me how to… how to. pass JSON 15:35:21 ack markus_sabadello 15:35:27 Otto Mora: Uh, Marcus?... 15:35:32 Markus Sabadello: Um, so I... 15:35:40 ... I disagree with Dimitri that this is only useful with relative rev, that's, uh, that's 15:35:44 ... Okay, so this has been suggested originally 15:35:47 ... About 2 years ago, um 15:35:53 ... To… to select services by type, and then do something 15:35:57 q+ 15:36:00 ... With them, and yes, you can use it with relative ref, and you can also use it without relative ref 15:36:06 ... I also disagree with Dimitri, unfortunately, that the file service 15:36:12 q+ to note that just because we drop something doesn't mean someone else can't support it. 15:36:14 ... proposal is somehow a replacement for this. I don't think it is the standardized path 15:36:20 ... processing that we have discussed, I think is something else, as far as I understand it, it 15:36:26 ... Doesn't really have a capability to select a service. By type, and uh 15:36:32 ... I would like to keep it, I mean, the question is, if people are asking 15:36:38 ... is this useful or not? We… we have… we have discussed this, and it has been 15:36:44 ... Proposed to add it, and there are a lot of discussions and a lot of arguments in the 15:36:51 ... in GitHub, and in meeting notes, and so on, why we wanted to… To add this, and uh 15:36:58 ... And so the fallback, I think, should not be to delete it. The fallback should be to just leave it as is 15:37:00 ack JoeAndrieu 15:37:05 q+ to note " and " was also a good idea at a point in time for HTML :) 15:37:08 Otto Mora: Oh... 15:37:15 Joe Andrieu: Um, yeah, plus one for removing it, um, and also probably removing relative ref... 15:37:17 This is where serviceType was originally proposed: https://github.com/w3c/did-resolution/issues/85 15:37:21 ... Um, my… my concerns with it is, I think it's… it's a security 15:37:30 ... error in our design. Uh, I think to Manu's point, any place that you might use service type, with one exception, which I'll get to 15:37:34 ... Um, you could just specify the service by ID, and that would uniquely point to that one. It feels like 15:37:42 ... when you have service type, it lets someone who's creating a URL to sort of go fishing around in a DID document when they're not even the processor 15:37:46 q+ 15:37:50 ... Um, and so that… that feels weird, and that's where we get these possible multiplicities. If we just have servers, we don't have the multiplicities 15:37:53 q? 15:37:59 ... And we don't have to deal with the fact that these may not be intended to be the same resource, but the system could be confused into giving 15:38:07 ack manu 15:38:07 manu, you wanted to say "remove relativeRef" :) and to note that just because we drop something doesn't mean someone else can't support it. and to note " and " was 15:38:09 ... The, um, uh, directing a particular resource to the outcome when that's not what was, uh, expected. Um… So that's it 15:38:11 ... also a good idea at a point in time for HTML :) 15:38:14 Otto Mora: Mm-hmm. Bye... 15:38:27 Manu Sporny: Um, right. Uh, let's see, uh, I'm also plus one to removing relative ref. I'm in many of these parameters, I think we created them... 15:38:32 ... During a time where we were unsure about what the ecosystem 15:38:43 ... could look like or was gonna turn into, uh, and now that we're getting ready to kind of lock this stuff in, I'm not convinced that these are useful 15:38:48 ... Um… features to have in the specification, uh 15:39:11 ... Uh, so to, you know, um, to, you know, make it fairly obvious, like, at some point in the development of the HTML spec, everyone thought the blink tag and the marquee tag were, like, really good ideas. Like, we need to get the person's attention on the site. How are we going to do that? Oh, let's put a scrolling marquee across the top of the 15:39:11 thing, right? Like, we went through a whole standardization process, it was added to the spec 15:39:22 ... It was broadly implemented in browsers, and then, you know, 5 or 10 years later, everyone was kind of like, hey, yeah, that was actually probably not a good idea, right? 15:39:33 ... Um, I'm not saying that, you know, service type is exactly the same, but it's in the same vein. Like, I still haven't heard anyone say 15:39:39 ... What the concrete use case that they absolutely need, you know, this feature for is 15:39:42