13:54:07 RRSAgent has joined #did 13:54:12 logging to https://www.w3.org/2026/05/13-did-irc 13:54:19 rrsagent, make logs public 13:54:29 Meeting: Decentralized Identifier Working Group 13:54:37 Chair: ottomorac 13:55:18 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026May/0045.html 13:55:19 clear agenda 13:55:19 agenda+ Will Abramson 13:55:19 agenda+ Pierre-Antoine Champin 13:55:19 agenda+ Otto Mora 13:55:19 agenda+ [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did/) ([View Calendar](https://www.w3.org/groups/wg/did/calendar/)) 13:55:43 previous meeting: https://www.w3.org/2026/05/07-did-minutes.html 13:55:56 next meeting: https://www.w3.org/2026/05/14-did-minutes.html 14:00:45 Wip has joined #did 14:00:54 present+ 14:03:36 TallTed has joined #did 14:05:29 Topic: Agenda 14:05:52 transcriber-bot, resume 14:05:52 scribe+ 14:06:01 Otto Mora: Um, review the… continue the presentation on that, uh... 14:06:05 ... Uh, high-level algorithm that, um 14:06:06 https://docs.google.com/document/d/1xcoslzqA6Wr_CHhvvhZ4wKupEE32HZ69hp2AE1rJMjs/edit?usp=sharing 14:06:14 ... Will had prepared, and so… that would be… that would be the main topic, unless somebody else wants to… Uh 14:06:19 ... Discuss any other agenda item, or 14:06:24 ... Yep. Yeah, let's go ahead, uh… well, let's 14:06:30 Will Abramson: Yeah, well, I mean, I can talk about where we're at, or where I think we're at, um... 14:06:45 ... So I… I got in a PR and merged it that fixes the formatting, so at least now, hopefully, we have a formatted spec we can work on, so changes won't. FPS students 14:06:45 Topic: Status and High Level Algorithm 14:06:51 ... you know, some of the PRs before doing big format changes. Hopefully fix that 14:06:54 https://github.com/w3c/did-resolution/pull/331 14:06:56 ... Um, and then, yeah, I put in this PR331 14:07:06 ... Which, I don't know if anyone's had a chance to look at it, probably not, I only got it in… Yesterday, I think 14:07:07 JoeAndrieu has joined #did 14:07:15 ... Uh, and I know in the discussion on that, PR, that. I think there are still some things that 14:07:23 ... We haven't finalized. I have put in that PR just a spec text. People could review and then provide comments 14:07:28 present+ 14:07:29 ... on things that we might still need to discuss. I think, in particular, from 14:07:38 ... last week's call, we didn't really get a chance to properly discuss Step 5, use the resource. I know, Manny, you mentioned that 14:07:45 ... That's probably the bit that you would argue about, so we should definitely get to that today. Um 14:07:52 ... Yeah, and then I also note, like, Marcus is kind of pushing back about this, did URL, did 14:07:58 ... issue, which I expected, but I kind of hoped that the way I wrote the PR is… it's 14:08:03 ... Just not trying to address that issue head on, and maybe that's a mistake, or 14:08:06 q? 14:08:07 q+ 14:08:10 ... I just wanted to get this scaffold in so we can move forward, and then we can have a discussion about did versus did URL 14:08:16 ... Um, and make a decision about that, but I didn't think that was this decision that we're trying to make here 14:08:26 ... So, maybe I'll pause there, and if anyone has any… if they've had a chance to review the PR, great. If not, then… I mean, we can go back into the, um 14:08:31 ack manu 14:08:31 ... slides as well, I'm happy to do that, if that's more helpful. Right 14:08:35 pdl-asu has joined #did 14:08:36 Otto Mora: Mm-hmm. Adam?... 14:08:41 present+ 14:08:48 Manu Sporny: Uh, just a general plus 1 to PR331. That is exactly what I was hoping we would be able to. Um... 14:08:56 ... put into the spec. It's… it's short and sweet, and talks about each step, and 14:08:59 ... that's exactly what we need, I think, um, to move forward 14:09:07 ... So, my guess is, uh, we should all review, you know, over the next week, and then merge 14:09:14 ... Um… how long… yeah, we should merge after a week before the next 14:09:17 ... Special topic call, if there are no objections, of course 14:09:28 ... And then the expectation is that we would then, uh 14:09:28 q+ 14:09:28 ... Specify the algorithm 14:09:30 ... for each one of those as separate PRs 14:09:32 ack Wip 14:09:37 Otto Mora: Hmm. Well... 14:09:44 Will Abramson: Yeah, I think that's exactly right. Um, I mean, I'm hoping that on this call today, uh, we can... 14:09:50 ... kind of review it, or, like, talk about some of the bits that I was less confident that we had a consensus on 14:10:02 ... and at least in the group who's here today, get through that, because I'm hoping tomorrow, I haven't managed to do this yet, but we can always start talking about step 3. The retrieving of the resource 14:10:12 ... Oh, no, determining the retrieval strategy, so that when we do merge this PR, we've already made some headway on, like, the most. contentious piece 14:10:18 ... I think step one and two 14:10:24 ... I don't think we need to discuss today, unless people feel like we want to go deeper and unpack that 14:10:29 ... Uh, so maybe we can, like, revisit, um 14:10:38 ... Step 4 and 5, just talk about that, because that's kind of where we were at toward the end of last call. We were kind of running out of time 14:10:42 ... Uh, so step 4 is, um 14:10:46 ... Retrieve the resource, and 14:10:54 ... Um… now, there was some discussion last time about whether we should retrieve the resource at all, right? Whether it's 14:10:59 ... not the responsibility of the QRL dereferencing algorithm 14:11:04 ... to do this retrieval. I mean, currently, in the 14:11:09 ... spec, we don't do the retrieval, we just create the URL, and then 14:11:14 ... Append a fragment to it, if there is a fragment, and return that 14:11:26 ... I don't expect somebody else to fetch the URL, but that does expect or depend that the. thing that is returned is a URL. Um 14:11:27 q? 14:11:28 dmitriz has joined #did 14:11:29 ... So 14:11:33 present+ 14:11:33 ... But I don't know if anyone's on the queue 14:11:35 Otto Mora: Um, no, we don't have anyone... 14:11:41 Will Abramson: So I think, I mean, my personal opinion is I think we should be retrieving the resource, um... 14:11:48 ... and I think I agree with what Dimitri was saying, like, it's not that did your LD referencing specs 14:11:52 ... Role to define how to retrieve the results 14:12:05 ... it is… so I tried to capture that. Maybe I can read out what I wrote for retrieve the resource. I wrote, the next step is to retrieve the resource identified by the DID URL using the determined retrieval strategy 14:12:09 ... Retrieval strategies may be defined in external specifications 14:12:13 q+ 14:12:17 ... It is up to the client to determine if they are able to retrieve the resource. Using the specified strategy 14:12:20 ack manu 14:12:21 Otto Mora: Okay... 14:12:35 Manu Sporny: Yeah, that sounds fine to me at a high level. My only, the only nitpick there is, you know, there would be information. Extra information probably needed... 14:12:39 ... By the retrieval strategy, um 14:12:43 so, that sounds a bit better. but then why are we even mentioning it. (the retrieval strategy, retrieving it) 14:12:50 ... you know, to pass to the client. Um, and here, it's not clear if the client is dereferencing. It's like… it's like there are two clients here, right? Like, one of them is the… the 14:12:56 ... dereferencing client, and the other one is the retrieval strategy client. Um 14:13:06 ... Uh, for lack of a better, you know, words to put it into. And so that's a little confusing, um, I mean, not… overly confusing 14:13:12 ... Um, and plus one for saying, like, we don't specify how to do this. Um 14:13:13 q+ to ask about multiple clients? there is only one client 14:13:25 ... there may be an exception to that, where we're like, hey, if it's HTTPS, then use HTTPS to retrieve it. Like, the retrieval strategy… if a retrieval strategy is HTTPS, then 14:13:25 q? 14:13:30 ... follow, you know, the HTTP spec to do the retrieval. Um 14:13:34 q+ 14:13:35 ... I'm not sure where Pat's service fits in 14:13:44 q+ 14:13:44 ... here, I'm guessing it's determined the retrieval strategy. So, those are the open questions that I have, right? I mean 14:13:52 ... I would like to avoid defining things in detail, but I think that's what you already have set up 14:13:57 ... Uh, and we should be able to hand off to external specifications. That's it 14:13:57 ack JoeAndrieu 14:13:57 JoeAndrieu, you wanted to ask about multiple clients? there is only one client 14:14:03 Otto Mora: This is… So... 14:14:08 Joe Andrieu: Um, yeah, Manu, I'd appreciate if you could unpack why you think there are two clients, because there's just one client... 14:14:13 ... And it is doing dereferencing, which includes… Um, calling Resolve 14:14:19 q+ 14:14:20 ... So, I didn't follow why you think there are two here. Um, but also, I think PathService is not 14:14:24 q- 14:14:27 ... Uh, included here, because this is not changing the spec in that way yet. That's a different conversation 14:14:30 ack Wip 14:14:35 Otto Mora: It will... 14:14:35 q+ to note "two clients" 14:14:42 Will Abramson: Uh, yeah, I promised I wanted to queue also to talk a little bit about the path service piece. Like, I think, to me, that is... 14:14:50 ... The, like, outputs from step 3 retrieve the resource, and, like, what goes into step 4, use the resource, is the most 14:14:56 ... uh… unknown for me in this sort of flow, like, what does it mean 14:15:02 ... To… what is the outcome of determining the retrieval strategy? 14:15:14 ... that then helps Step 4 know how to retrieve the resource. I think it still feels a bit underspecified, but I think one of those retrieval strategies. Would be path service 14:15:18 ... And I guess the question is 14:15:29 ... is it path service, or is determining the retrieval strategy actually already interpreting past service and constructing the URL? So it's just passed to the retriever resource 14:15:38 ... My sense is that the retrieval strategy is path service, and then step forward compiles the URL and retrieves, but 14:15:41 it is not up to the DID Resolution/Dereferencing client to determine the retrieval strategy 14:15:45 that's mixing way too many layers 14:15:47 ... Um, as I said, that's the most unknown to me, and I think that'll come clear when we unpack Step 3 in more detail 14:15:51 ack manu 14:15:51 manu, you wanted to note "two clients" 14:15:56 Otto Mora: Okay, uh, Manu... 14:16:03 Manu Sporny: Yeah, to, uh, Joe, to an attempt to, uh, answer your question, um... 14:16:11 ... There's determine the retrieval strategy and retrieve the resource. And 14:16:24 ... I am… it could be all bundled into one client, and we could say, like, this is… this is… the client is capable of doing all of these things. That's one approach, and I think that might be what you're suggesting 14:16:36 ... Uh, the other approach is, well, you know, there's, like, subroutines that you could potentially call to determine the retrieval strategy and collect all the information 14:16:42 ... needed by the retrieval strategy, and then to retrieve the resource. Like, there's a… for example, there is a 14:16:48 ... difference between an HTTP client retrieving the resource and a, like 14:17:04 ... on-blockchain mechanism to retrieve the resource, right? Those are two different clients. There's an HTTP client and a blockchain client, and the logic between both of them is, like, not really shared when you're retrieving the 14:17:09 q+ to yes, we are only defining a single client doing dereferencing. the additional implementation details are not what we are standardizing 14:17:11 ... the resource, and both of them may need different information, like the HTTP client probably only needs an HTTP 14:17:16 ... uh, URL, um, but it may also need, like, a media type. Um 14:17:19 present+ 14:17:20 I have made the request to generate https://www.w3.org/2026/05/13-did-minutes.html TallTed 14:17:32 ... Whereas the retrieval strategy for a blockchain thing, you know, might need, uh, you know, a number of different addresses and beacons and whatever, so that retrieving the resource, you know, can be performed. So that's why I'm thinking, like 14:17:36 ... Is that a part of 14:17:45 ... the dereferencing client, or is that, you know, code that the dereferencing client can call, and do we need to make the distinction? 14:17:52 ... Those are kind of open questions in my mind. Um, I don't have a strong preference for one over the other 14:18:00 ... Um, other than, you know, we… over the couple… past couple of months, it's been… Very clear that, like 14:18:09 ... The retrieval strategies matter here, meaning they use… some of them use totally different information to get, uh, to retrieve the resource 14:18:09 ack JoeAndrieu 14:18:09 JoeAndrieu, you wanted to yes, we are only defining a single client doing dereferencing. the additional implementation details are not what we are standardizing 14:18:14 Otto Mora: Mm-hmm. So... 14:18:23 Joe Andrieu: Um, yes, I do think that all we are standardizing here is what the client of a resolver needs to do before... 14:18:31 ... during and after resolution. I think it is the additional complexity of how you might break any bit of this software into different components 14:18:32 q+ 14:18:42 ... that has, I believe, anchored the confusion in the current spec. Like, you might use a JSON parsing library. We're not going to break that out and specify that you might do that 14:18:53 ... Um, I just don't think it's the right level of detail. Um, but to the point about an HTTP URL is sufficient for you to understand the strategy, that is unfortunately not accurate, and I've 14:19:00 ... I feel like I've said this many times, and it's a little bit frustrating. When you have a data integrity anchored URL, like you have with, um 14:19:07 ... linked resources and did link resources, the URL fundamentally is not sufficient to know if you have the resource 14:19:13 ... Um, so we cannot reduce the output there and say, hey, you've got an HTTP URL, now you know what to do 14:19:21 ... The whole point is the DID architecture allows you to access data that may not be anchored. to URLs other than did 14:19:31 ... So, the notion is that whoever's resolving this needs to be able to interpret the did URL, and interpret the did document, and make enough sense out of it 14:19:43 ... in order to perform whatever the retrieval requires. And in some cases, it might mean talking to Bitcoin, in other cases, it might mean applying an algorithm after you get what you think might be the resource 14:19:48 ack Wip 14:19:54 Otto Mora: Doing well... 14:19:58 Will Abramson: Uh, I just wanted to say, like, I think... 14:20:07 ... Definitely, there's going to be work in this spec to define, like, what we mean by a retrieval strategy, and, like, what 14:20:12 KevinDean has joined #did 14:20:13 ... Like, what's the minimum required for somebody to define such a thing? 14:20:18 present+ 14:20:18 ... So that the referencer can know, oh, this is a retrieval strategy 14:20:26 ... And, you know, I do these steps to retrieve the result. And those steps might just be 14:20:34 ... executing, like, HTTP GET on the URL, but it might be all sorts of other things, and, like, I think the ways that 14:20:40 ... we've explored that that is possible, is through a type, right? Like, the type… it might be a type of service, or it might be a type of 14:20:46 ... Like, extension, um, like, linked resource, or it might be 14:20:56 ... I mean, I don't know if the metadata, like, did link resources has the type, but there's different ways in which you can add retrieval strategies to 14:21:02 ... your DID document, or your DID resolution result. And we just need to have some common way 14:21:08 ... That those retrieval strategies can signal to a client, or like a 14:21:15 ... Performing dereferencing, that they are retrieval strategies, and they should be considered. Um 14:21:21 ... I think that's all just work that we need to do. And we can talk about that tomorrow, uh 14:21:30 ... But assuming we have that, I mean, maybe I can just read out as well, um, step 3. My language? 14:21:39 ... because I do want some good, you know, feedback on this, and if these are fine, like, I think they are trying to be quite high level and not controversial, you know, I'm not trying to get into all these details 14:21:46 ... Uh, but just flagging that we will have to get into them at some point. So, step 3 is called Determine Retrieval Strategy 14:21:53 ... Uh, it says, after successfully resolving the did document and accompanying metadata 14:22:01 ... The next step is to determine the appropriate strategy for retrieving the resource. identified by the DID URL 14:22:05 ... This involves analyzing the content of the did resolution result 14:22:10 ... Including the DID document and its metadata, along with the path and query 14:22:16 ... components of the URL to determine the method for retrieving the result 14:22:24 Otto Mora: Well, might it help if we just screen share the text?... 14:22:25 Will Abramson: Sure, yeah, I can do that... 14:22:28 Otto Mora: Maybe just... 14:22:33 Will Abramson: Oh, yeah, I only have one screen today, though, so it's not… Too crazy... 14:22:38 Otto Mora: I'll keep tabs on… on the hands. No worries... 14:22:49 q+ to note, do we have issues w/ the current PR? 14:22:52 Will Abramson: Yeah, actually, I don't think I can easily do that... 14:23:00 ... I mean, everyone could bring it up, right? Like, it's 331… I can drop it in the minutes again 14:23:03 Otto Mora: Yeah, I'll… let me try, hopefully... 14:23:07 PR is here: https://github.com/w3c/did-resolution/pull/331/changes 14:23:15 ... Mm-hmm. Here 14:23:21 ... So yeah, so from… from step 3, right, do I just highlight it? 14:23:28 ... Determined retrieval strategy here, right? This one? 14:23:31 Will Abramson: Yep... 14:23:38 ... Yeah, I mean, I just wanted to get a sense of that that's the text we have, or… I mean, I think Manny was on the queue 14:23:39 ack manu 14:23:39 manu, you wanted to note, do we have issues w/ the current PR? 14:23:43 Otto Mora: Go ahead... 14:23:44 q+ 14:23:46 Manu Sporny: Uh, yeah, I guess the question is, do we have issues with this PR? I'm like... 14:23:54 ... I think it reflects in general. I mean, there are details we can add to it, but like… Would anyone object if we merged this thing? 14:23:57 q+ 14:24:00 ... And if so, what are the objections, and what can we change, and that sort of thing 14:24:01 ack Wip 14:24:05 Will Abramson: Yeah, I... 14:24:11 ... The main thing that I wanted to talk to you, really, about, Manu, is, like, step 5, and 14:24:19 ... And… is that the right name? I mean, I know that's something that you had some concerns over, like. Right 14:24:26 Manu Sporny: I'm not gonna block the PR, like, you know, like, we can figure that out later. Like, if people don't want to implement that step, they won't implement it, right? And so... 14:24:28 bigbluehat has joined #did 14:24:32 Will Abramson: Mm-hmm... 14:24:36 Manu Sporny: I think it's much, much more important to get the first couple of things that we agree to, and get the algorithms in there, and then, you know, we can… we can, uh... 14:24:48 present+ 14:24:52 ... once we get that foundation in there, like, it becomes much, much easier to… like, if we're arguing about item 5, like, that's where we spend, you know, most of our time, and the other ones are in the spec, and we've got them sorted, we're in great shape 14:24:54 Will Abramson: Mm-hmm, mhm... 14:24:57 Manu Sporny: Right? So… so we can talk about it later, I guess. I don't really... 14:25:07 ... you know, it's fine. Like, if we're going to retrieve the resource, if we as a group decide, like, that is something we're going to define in the spec, then that's… that's fine. I'm not gonna, you know 14:25:13 Will Abramson: Hmm... 14:25:16 Manu Sporny: block the group from wanting… you know, if we have consensus to do that, that's great. So I don't think we need to talk about that today. I'm more concerned about, like... 14:25:20 ack dmitriz 14:25:21 ... Can we get the base layer in there now, and then start getting into the details? 14:25:26 Otto Mora: Dimitri... 14:25:37 Dmitri Zagidulin: So I, uh… just like Manu, uh, I would not… I'm not going to formally object or block the PR, but I do want to go on the record... 14:25:43 ... That I think this is absolutely the wrong architecture and the wrong direction to go. We should not be 14:25:54 ... Like, look at what we're saying. Use the resource, or retrieve the resource. This is absolutely not the point of the domain of the dereferencer. Whether or not 14:26:00 ... the client wants to use the research afterwards is up to them. It is not up to us in our spec to say it 14:26:01 q+ 14:26:05 ... Uh, this… this feels… this feels redundant, and 14:26:16 ... overly prescriptive. Uh, same thing, we should not be retrieving it in the spec. Client can retrieve or not retrieve as they see fit 14:26:17 q+ 14:26:20 ... I think, uh, I think the spec should end at returning the URL 14:26:23 ack Wip 14:26:27 Otto Mora: Well... 14:26:35 Will Abramson: It does, interesting. And it seems like your moral perspective, like, the… or, like, at least the general district as it is today... 14:26:46 ... But, to me, I mean, when you just Google about dereferencing and stuff, like, the point of dereferencing is to get the result, isn't it? Like, that's my understanding of dereferencing 14:26:50 Dmitri Zagidulin: Yes, but notice that no dereferencing spec says use the resource afterwards... 14:27:04 Will Abramson: Yeah, well, but, like, all that's happening there, or, like, one of the reasons that you have that step, if you ignore the name, is it's about handling the fragment, so, like, finding the secondary result in the resource that you've retrieved... 14:27:07 Dmitri Zagidulin: Also, notice that's not in the... 14:27:12 ... In the, uh, resolution, uh, or order referencing specs, like 14:27:17 ... That's optional and up to the client afterwards, whether to do the fragment resolution 14:27:24 Otto Mora: Is it just an… is it just a name, though? Like, maybe... 14:27:28 ... I wonder, like, is it just a optionally process 14:27:34 ... Post-processing, something like that, optional post-processing, or just… I don't know if… yeah, maybe 14:27:46 Dmitri Zagidulin: My point is, where does this stop? Do we put in the spec, then go on with the rest of your program, or then go on with whatever you were intending? Like, why do we need to say that? They're gonna do it anyways... 14:27:47 ack manu 14:27:48 Otto Mora: Yes... 14:27:52 ... Let's… That is 14:27:55 Manu Sporny: Um... 14:28:06 ... The way I'm interpreting this, Dimitri, is not a prescriptive thing. So, so, uh, one thing you said I think is not correct, which is 14:28:15 Dmitri Zagidulin: Yes... 14:28:18 Manu Sporny: Um, when you define a media type, you have to define what the fragment means in fragment processing. So, so that is definitely in specs that are out there... 14:28:20 Dmitri Zagidulin: I'm... 14:28:23 Manu Sporny: Um, and in some cases, it's pretty prescriptive. I'm not saying we should... 14:28:29 Dmitri Zagidulin: Hold on, hold on. Hold on. But that's in the media type spec, not the resolution spec... 14:28:42 Manu Sporny: Sure. Yeah, yeah, yeah. So, so, what I'm saying is that there are specs that define that, and this spec… this spec is more akin to the… let's look at HTTP, you know, dereferencing... 14:28:45 q+ to clarify what 3986 actually says 14:28:52 ... That spec says media type matters, and if you want to know about fragment processing, go over here and do it, but it does talk about, like, if fragments exist 14:28:59 ... Right? And you should process them. And I think that's the… that… I think that's as far as 14:29:14 ... we're suggesting anyone should go in this spec. It is not going to be a prescriptive description of, like, this is exactly how you do fragment processing. It's… my hope is that we're going to basically say, hey, fragments exist, and this is where you process them 14:29:25 ... uh, you will, you know, have to… you know, how you process that fragment is highly dependent on the media type and yadda yadda. So we do the exact same thing that the HTTP 14:29:37 ... specs do today, which is… which is, uh, establish that, yes, it exists, and there is a part of this process that you do fragment processing, and all of the details. Or elsewhere 14:29:47 Dmitri Zagidulin: Yes, it does, it does. And if your concern is to remind people that fragments exist, maybe we can just do that. Maybe we can, instead of saying... 14:29:50 q+ 14:29:51 ... Retrieve it, and then use it. We can just say, hey, fragments exist, don't forget to process it 14:29:53 ack JoeAndirieu 14:29:59 Otto Mora: Okay, Joe?... 14:30:09 Joe Andrieu: Um, yeah, I'm surprised how strongly you're opposing this. I think I understand that your sense is, hey, we've got this resolution endpoint, that's what we're talking about, talk to it... 14:30:18 ... What you do with your results is your business, and I can appreciate that, um, except for two things. Um, one is, I don't think people know what to do with that resource 14:30:27 ... Uh, at that level, because they don't yet have guidance about how to deal with all the different things that they might need to do to actually get the resource 14:30:36 ... So we've created an insanely complicated system that has multiple different layers at which you might use different information to go get the actual resource 14:30:49 ... And so I do think we need to explain that. Um, but the other thing is, looking at 3986, it absolutely explains about secondary resources and what a client needs to do to finish, uh, dereferencing 14:30:57 ... And so, to say that fragments aren't discussed in the base definition of URLs, and the fact that you might go from a primary resource to go get a secondary resource 14:30:58 q- 14:31:03 ... the fact and how they talk about it is really how we're trying to talk about this. Like, it says things like 14:31:10 q+ 14:31:11 ... Um, uh, just because there is a fragment doesn't mean the retrieval's gonna happen. Like, the spec absolutely, 3986 talks about retrieval 14:31:16 ... Um, and they're trying to give guidance for when someone is using this weird thing called a fragment, which is different 14:31:21 ... Um, how do you apply that fragment in the processing of that URL? 14:31:22 https://datatracker.ietf.org/doc/html/rfc3986#section-3.5 14:31:23 ... That's it 14:31:25 ack JoeAndrieu 14:31:25 JoeAndrieu, you wanted to clarify what 3986 actually says 14:31:28 Otto Mora: Mm-hmm. Okay, uh, balance?... 14:31:31 ack manu 14:31:41 Manu Sporny: Yes, plus one to what Joe said. That's why I'm kind of like, eh, no, it really does talk about fragments. And it does matter that, you know, there's… there are details there that are in other specs, but I think as Joe said... 14:31:47 s/Um, how do you apply/from how do you apply 14:31:52 q+ 14:31:59 ... we're just trying to give people a framework to think about the tail end of this. That's my personal opinion, is that's probably where we're gonna end up. Like, the first couple of steps are very concrete. Like, this is, you know, these are the inputs, these are the outputs, you're gonna get 14:32:05 ... you know, you're gonna pass in options, you're gonna get a DID document out, you're gonna use the URL, and we're gonna be very prescriptive 14:32:14 ... In the beginning. Um, but towards the end, I think around determine the retrieval strategy and retrieve the resource 14:32:21 ... We may not… we are probably not going to be able to get very detailed there, because those are 14:32:27 ... Potentially did, you know, um, uh, did method-specific things 14:32:35 ... Um, and so we may keep those at a fairly high level. I… and the details matter here, and I think we'll get into the details later 14:32:40 ... But all that to say, I think these steps are the framework in which someone should think through 14:32:49 ... How, you know, you get to the thing you were originally wanting to get to in the… in the beginning 14:32:50 ack Wip 14:32:56 Otto Mora: Mm-hmm. Well... 14:33:09 https://pr-preview.s3.amazonaws.com/LegReq/did-resolution/pull/326.html#dereferencing-algorithm-use-the-resource 14:33:10 Will Abramson: Yeah, I think that's right. I mean, step 5, use the resource. I don't imagine there is going to be any details there, right? Like, it probably… maybe the paragraph needs to be tweaked, but if you have a look at. like, Joe's initial attempt at this... 14:33:18 ... it… there is no steps, or… I mean, there is a step, but it's just, like, describing this at a high level. You know, it's basically saying 14:33:31 ... You've now, like, dereferencing is now complete, you've got this resource, you know, apply the fragment, use it in your context 14:33:31 ... Uh, it's not saying how to use the resource 14:33:39 ... But just that, you know, you've done. And I guess it's like, I mean, without putting words into Joe's mouth, it's like saying, like. Maybe this doesn't return 14:33:45 ... But, you know, it is ended, I think, right? Like, this is the final step 14:33:50 ... You might have to apply a fragment, but then you've got this thing, and you can do with it what you want 14:34:04 ... Uh, then the other thing I was going to say is, like, I think absolutely some people might end at step 4, or, like, for example, if we want to support. Marcus is, um 14:34:08 ... You know, this function signature, uh, as, like, a 14:34:20 ... optional thing that, you know, people might implement. Um 14:34:20 ... that people could even bind to, right? Like, that really is ending at step 4. Um 14:34:28 ... just naturally. I mean, that's what happens today in the spec, even though the function's called dereferencing, it really. It's only about dereferencing the resource 14:34:39 ... and then you get the results back, and then you use the resource, right? You apply the fragment, and you do stuff with it. But that's… uh… Anyway, I don't know if that helps at all 14:34:46 q? 14:34:49 Otto Mora: Mm-hmm. Um... 14:34:52 Will Abramson: Yeah, so... 14:34:54 Otto Mora: Don't have anybody on the queue. I don't know, Dimitri. Go ahead... 14:34:57 Will Abramson: I can keep going. I mean, um... 14:35:01 ... So, I mean, it's just good, I'm not hearing, like 14:35:13 ... I think we're generally in agreement. I mean, Dimitri, I think I'm hearing the most pushback from you, which is fine, um… But not enough to block this. Um… yeah 14:35:18 ... So that's great. I mean, obviously the PR will be open, and we'll try and merge it before Wednesday 14:35:24 ... Uh, but please, in the meantime, do read all the text and have comments on it. Like, I also 14:35:35 ... um, put some sort of text, you know, like, when I created the PR, like, I did my review of, like, status of it, and raised some. questions, um 14:35:41 ... One of the questions I have, which may be more general and doesn't need to go into this PR, um 14:35:48 ... but is about, like, error handling. I mean, this was from my slide deck, actually, but we didn't get to it 14:35:50 section 3.5 of the url spec explicitly says "As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place." <- that's the opposite of our instruction saying "retrieve it" 14:35:59 ... I think because in the current spec, it has this function signature, we have very explicit, defined errors. That are raised, um 14:36:07 ... You know, with specific types and all that, and that's because, in part, so that the function signature can return 14:36:14 ... in, like, a structured way, what errors occur from it. I think in this new approach, when you're imagining that it's the client doing dereferencing 14:36:18 q+ 14:36:24 ... we perhaps wouldn't specify in as rigid a way, like, which types of, like, the exact structure of the errors. Like, I don't know, I would be interested in what people think about how we 14:36:29 ... Humble errors, and, you know, thinking about what happens in the current spec today 14:36:31 q? 14:36:33 ... Um, whether we should keep that or change it 14:36:34 ack manu 14:36:38 Otto Mora: Bottom... 14:36:45 markus_sabadello has joined #did 14:36:50 Manu Sporny: I'm saying this without, you know, refreshing what happens in the current spec today, but in the VC data model and BCOM specs, we have algorithms, and we basically say... 14:36:59 ... Or raise an error of this type, and we have a section that talks about the types of errors, the common errors that could happen 14:37:05 ... Um, so, you know, and it's unified across, um, BC 14:37:11 https://w3c.github.io/vcalm/#error-handling 14:37:15 ... data model, data integrity, and VCOM. Uh, it works fairly well, I think. Um, so let me link to some sections here 14:37:19 q+ 14:37:19 ... This is the section on error handling. Um 14:37:27 ... And, uh, we use problem details objects, which is an ITF, you know, RFC to do it, RFC 9457 14:37:34 ... Um, and then, uh, we, uh, also… let me try and find 14:37:36 https://www.w3.org/TR/vc-data-model-2.0/#problem-details 14:37:39 ... um… VC data model 14:37:45 ... We've got, you know, problem details objects here, um, and then… parsing 14:37:49 ... Uh… well, let's 14:37:55 https://www.w3.org/TR/vc-data-integrity/#processing-errors 14:37:56 ... let me… let me try and find an algorithm where I think it's in, like, data integrity. Um 14:38:01 ... Here are the processing errors and data integrity 14:38:06 ... And then, uh, proof generation 14:38:07 https://www.w3.org/TR/vc-data-integrity/#add-proof 14:38:18 ... And in these high-level algorithms, um, which some of what we do in did resolution might be higher resolution, or, you know, might be, um 14:38:29 ... uh, kind of abstract algorithms, um, we say an error must be raised and should convey an error type of, and then we specify the error type, and we link to the appendix, so 14:38:29 q? 14:38:36 ... I suggest that's how we do it, because it works fairly well, and we may already be doing that in the. Did resolution spec 14:38:39 ack Wip 14:38:43 Otto Mora: Well... 14:38:43 q+ 14:38:46 Will Abramson: Great, yeah, no, that is... 14:38:46 https://w3c.github.io/did-resolution/#dereferencing-algorithm-resource 14:38:51 ... I mean, very much how we are doing it in the data resolution spec, if you see here 14:39:01 q+ 14:39:02 ... I think the difference is, currently, in the dereferencing algorithm, when in the resolution, we say we return an error in a specific, like, metadata structure 14:39:09 ... Whereas, I think there, you're just saying you raised an error. Um… Um 14:39:16 ... And then if the function that we might wrap around, it wants to return it, then it can figure out how to do that later on, right? 14:39:19 ... I think that makes sense to me, to be maximum 14:39:20 q? 14:39:26 ack markus_sabadello 14:39:28 Markus Sabadello: Uh, yeah, yeah, exactly. I mean, we… we have had... 14:39:40 ... Error always as one of the properties in the metadata that's returned, and we have had that both in 14:39:48 ... in the data resolution algorithm and in the DTO dereferencing algorithm, right? So both can… can return errors 14:39:54 ... Resolution algorithm… oh, sorry, both can return metadata, right? The resolution algorithm 14:40:04 ... returns the resolution metadata, and the DTRL dereferencing algorithm returns DTRL dereferencing metadata, and both of them have 14:40:11 ... A property called error, and in the current specification, the algorithm 14:40:17 ... says which error to return in certain situations, right? Are we 14:40:21 ... Are we discussing changing that, or I 14:40:25 ... Sorry I changed late, but I don't really understand why 14:40:30 ack manu 14:40:31 ... Um, if what we want to change about the error handling 14:40:31 q+ 14:40:37 Otto Mora: Madam?... 14:40:46 Manu Sporny: Um… I, I somewhat have the same question, um, Will, you might be… So... 14:41:02 ... either we are very strict about the data structure that's returned, like, you know, there's a function signature, and there's a return type, and we're very, very strict about the return type that's returned. That's one way that we could do it, and I think that's the way the current spec is written 14:41:16 ... Or, if we want to loosen it up a bit, we can say an error is returned and not specify how that error is returned. But we definitely say the error has these properties, and yadda yadda. And I think the only difference between the two 14:41:27