13:56:21 RRSAgent has joined #did 13:56:25 logging to https://www.w3.org/2026/07/08-did-irc 13:56:35 transcriber-bot has joined #did 13:56:47 rrsagent, make logs public 13:56:53 Meeting: Decentralized Identifier Working Group 13:57:08 Chair: Wil 13:57:39 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jul/0006.html 13:57:39 clear agenda 13:57:39 agenda+ Will Abramson 13:57:39 agenda+ Pierre-Antoine Champin 13:57:39 agenda+ Otto Mora 13:57:39 agenda+ [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did/) ([View Calendar](https://www.w3.org/groups/wg/did/calendar/)) 13:57:52 previous meeting: https://www.w3.org/2026/07/02-did-minutes.html 13:58:12 next meeting: https://www.w3.org/2026/07/09-did-minutes.html 13:59:06 TallTed has joined #did 13:59:18 transcriber-bot, connect 13:59:44 Wip has joined #did 13:59:49 present+ 13:59:58 transcriber-bot, connect 14:01:45 JoeAndrieu has joined #did 14:01:52 transcriber-bot, connect 14:01:54 scribe+ 14:02:04 Otto Mora: Okay. Okay, thank you... 14:02:05 transcriber-bot, pause 14:02:06 scribe- 14:02:16 present+ 14:02:32 present+ 14:04:43 danpape has joined #did 14:07:16 Topic: Agenda Review 14:07:19 transcriber-bot, resume 14:07:20 scribe+ 14:07:26 Will Abramson: Let's resume, right?... 14:07:31 ... Yeah. Okay, cool. Yeah, so welcome to, uh, today's 14:07:38 ... Working Group Special Topic Call 14:07:53 ... Today, I mean, really the focus is around trying to get to CR. There are two outstanding PRs that I want us to review and discuss. Uh, I think there are some comments on Marcus… from Marcus on one of them that 14:08:11 ... you know, we're gonna need to figure out how do we want to handle that. Uh, I hope to be able to merge them today, but we'll see. And then, if there is time remaining, uh, I think it's best placed to review Joe's outstanding PR and any comments on that from the group around the digital URL dereferencing algorithm 14:08:22 Topic: DID Resolution CR Issues 14:08:23 ... But yeah, focus today and tomorrow is just going to be how do we get to CR spending as much time as is useful on that. Um… Okay. So, I'm gonna go on 14:08:29 ... So 14:08:34 ... I mean, CI issue is probably wrong, actually, CRPRs, but 14:08:38 subtopic: https://github.com/w3c/did-resolution/pull/345 14:08:42 ... Let me do the easier one first 14:08:54 ... So, 345 is, uh 14:09:10 ... A PR from Otto, which addresses issue 341, which was a kind of remaining tag review issue that I think we forgot to, we missed when I was trying to capture them all. So as I was reviewing the tag design issues, this one sort of, I was like, we haven't handled that. And it's really. About… we have this hedgy text that Jeffrey was saying, you 14:09:10 know, this 14:09:23 ... This needs to be a bit clearer. Otto's put in a PR that basically just removes the hedgy text and follows the advice of Jeffrey, which is to 14:09:26 ... uh… take things out of the notes, and make it normative, I believe 14:09:29 ... I don't know if you want to say anything about that 14:09:32 Otto Mora: Yeah, no, you got it. That's essentially what it does... 14:09:39 ... Uh, it implements the text change that we had agreed, uh, I think about 2 weeks ago. And, uh 14:09:45 ... Yeah, I mean, I see approvals from both, uh, you and Marcus, but, uh, obviously 14:09:50 ... Maybe one more approval or a final blessing here would be 14:09:50 KevinDean has joined #did 14:09:54 Will Abramson: So it's got 2PR, I think Manny's just approved it. Yeah. Great. I mean, okay. So... 14:09:56 present+ 14:10:02 ... If anyone else has any comments, jump on the queue, but otherwise, I mean, I'm of mind to merge this, maybe I'll do it after the call. um 14:10:05 looks good 14:10:06 ... That's great. We can just move on 14:10:11 ... Okay 14:10:13 present+ 14:10:24 ... Uh, yeah, so actually, just before I move on, the last quick comment on that, I don't think I've heard back from TAG, but I did, um, you know 14:10:34 ... review where… tell Type where we're at, and then just recently, I just pinged them and said, look, we have this one remaining issue, uh 14:10:39 ... when we merge this, are you happy for us to move to CR? So hopefully they're going to get back to us and say, yes, that's great 14:10:44 ... But I think we do need tags or a blessing that their review is complete, right? That's my… Understand 14:10:51 subtopic: https://github.com/w3c/did-resolution/pull/346 14:10:55 ... Okay, well, that's fine. I'm sitting, and I'll 14:11:08 present+ 14:11:17 ... updated feedback from them. So, okay, let's move on to 346. So 346 is really trying, Otto, again, took this one on, which is great. He's trying to execute the resolution that we passed last week, which was focused on moving DID resolution to CR with DID URL Dereferencing marked at risk 14:11:30 ... And when we reviewed this text, really, the editors, like Joe and Stephen, and I think many of you weren't there, actually, but we just looked through the spec and realized there are a few other sections that are, like, heavily 14:11:37 ... Did URL dereferencing dependent? I mean, obviously, did URL dereferencing is woven throughout the spec, and I think 14:11:44 ... that obvious tag will have to realize that, and I think that's fine, because we have this top statement that says, you know, did URL be referencing? 14:11:49 ... feature is at risk, and if we do remove it, we are going to have to do some surgery to the spec 14:11:56 ... the… the… oh, that… Sections that we marked as at risk 14:12:02 ... that really Marcus is querying are the did resolution architecture section 14:12:08 q+ 14:12:08 ... And the did URL dereferencing result section. I'd love to hear from people 14:12:21 ack manu 14:12:22 ... what they think, or, like, how do we move past this without just… you know, I don't think we can completely overrule Marcus. I mean, maybe he is right, we didn't have a discussion about what to do with the DID resolution architectures section in the group 14:12:30 ... But I really was hoping to get this merged. So yeah, that's tricky 14:12:42 ... Yeah 14:12:45 Manu Sporny: Uh, I did a quick, uh, read-through of the sections Marcus is saying we should not mark as at-risk. Uh, they are largely non-normative, though we do have a couple of normative, like, should statements sprinkled throughout... 14:12:55 ... Um, which, you know, I don't like, I don't think we should be doing, but… but whatever, right? They're not… I don't think there are any musts, uh, in either section 14:13:03 ... Um, and for that reason, I'm fine removing the at-risk issue markers. Um 14:13:07 ... Because, you know, whether or not they're marked at risk or not 14:13:26 ... If we change did URL dereferencing, there is a chance that those other sections are gonna have to change as well, right? So I don't, you know, I disagree with Marcus saying like we shouldn't mark it as at risk. There's no downside to marking it as at risk 14:13:31 q+ to speak for at risk for resolution architectures 14:13:42 ... You know, as at risk, we're just saying, hey, like there, this section might change heavily, um, and people should pay attention to it, um, but if markets is gonna block, uh, you know, us being able to get these, uh, you know, get the CR based on this, then. Find, like, remove the language and, um 14:13:54 ... And we, you know, we will have marked the ones that are really, you know, likely to change. as at risk, and we can… we can move on from there. So 14:14:06 ack JoeAndrieu 14:14:06 JoeAndrieu, you wanted to speak for at risk for resolution architectures 14:14:06 ... Anyway, all that to say, I think it's fine for removing the at-risk markers for the things that, you know, Marcus is objecting to, um, if it gets us into CR 14:14:10 Will Abramson: Yeah, thanks, Manu. I do hear that. It's important to get to CR. Joe?... 14:14:26 Joe Andrieu: Yeah, unfortunately, Manu, I disagree. I'm the one who asked that we put that section at risk. It has language in there that I would formally object to. We define things that violates our fundamental security model... 14:14:30 ... I really think we need to, at a minimum, put it at risk 14:14:40 q+ 14:14:44 q+ 14:14:50 ... And we're going to have to talk about those sections if Marcus is going to fight to put them in. But we define things like proxy in your resolver, which is not supported by our security model. We have no consensus mechanisms by which we could secure that architecture. And the presumption is you need to trust your resolver 14:15:03 ... And I think the conversation that Marcus wrote was intended to be, these are ways that things can be done, which is true, but they are not things that are part of our recommendation 14:15:10 ... And so I think we really do need to keep that section at risk. And I didn't hear Marcus's objection to saying he's going to stop CR. I'm hearing him say he wants us to have a conversation about it 14:15:13 ack manu 14:15:19 Will Abramson: Yes. I mean, I think that was his main concern. He just saw the spec and didn't realize the exception would get marked at risk. Manu?... 14:15:38 Manu Sporny: Yeah, and, you know, acknowledge Joe, that's, you know, a legitimate concern. I don't think you can, I don't think you can, I mean, you can formally object over anything, right? And you can object over anything, but like objecting over marking something is at risk is a bit... 14:15:47 ... I don't 14:15:59 ... No, no, no, no, I'm not talking about you, Joe. Yes, I heard you understood fully. I'm talking about Marcus. If Marcus is like, no, I am blocking our transition to CR, at that point, I think you can just override and basically be like, we are just putting an at-risk issue. Marker in here, like… you know 14:16:07 Joe Andrieu: No, I mean, I will object to this content. This is... 14:16:08 Manu Sporny: If you want us to talk more about it, we can talk more about it during CR. If you want us to talk about it right now... 14:16:11 Joe Andrieu: Oh, okay, sorry... 14:16:14 Manu Sporny: You know?... 14:16:19 ... what's the point, right? Like… anyway, so I don't… I don't think it's… let's just have a discussion with Marcus tomorrow, hopefully he's on the call 14:16:28 q+ 14:16:36 ... Um, and if not, let's leave it in there, and, you know, if folks want to object to it, we can say, hey, yeah, when we tried to transition to CR, there was an objection over marking a section as at-risk. And then, you know 14:16:37 ack Wip 14:16:43 ... I don't think that… I think the response to that is like, okay, we… like, you know, it's, uh… you can talk about it in CR. It's marked as at-risk. That's it 14:16:50 Will Abramson: Yeah, great. I mean, uh, I think we're all on a similar page. Uh... 14:17:08 ... I spoke to Marcus today, actually, and he said he's at this event. I'm hopeful he's going to come tomorrow, but if he's not, I think we just should… I think I take Manu's point that we should move forwards. I mean, I think we could get Marcus on board that this did resolution 14:17:16 ... architecture section… I mean, I think I've agreed with Joe, really. This is… this is currently a section that just says, here's different ways that you could do this architecture without any real, um 14:17:25 ... thought around the ways in which we want people to do this architecture, right? It's just, here are all the different variations, and there's no, sort of, like 14:17:42 ... guidance around which variation is good or bad. And I think my understanding, maybe talking with Joe and some others, is that really this did resolution architecture section can be, I mean, as we mentioned there, right, can hopefully be replaced by the resolution threat model 14:17:49 ... which is gonna, sort of, review the architecture, right, like with the DFD diagram, and then have some 14:18:13 ... analysis, security analysis over that architecture. And… I mean, I think some of the sections in this architecture section, right, about, uh, I think it's the proxying section, maybe isn't even going to be in there. I'm not sure, I'd be interested to see how that plays out, but 14:18:21 ... I think… I think we on the group think that's a bad idea, and we shouldn't be talking about it in… like, in this section, it's just like, here's just one way you could do it, and we don't say whether it's good or bad, or what the risks of doing it are, we just say, you know, you can do it like that if you want. um 14:18:27 ... So, yeah, I think I like Manu's suggestion. I mean 14:18:43 ... I take Marcus's point, we haven't talked about this as a group, right? So maybe Marcus just feels like it's gone out of nowhere, we should chat about it. I do also see that, you know, just want to get to CR. We think we're all in agreement that this section is going to be under discussion in CR 14:18:44 ack ottomorac 14:18:49 ... I guess pretty, it doesn't matter too much either way. Anyway 14:18:50 Otto Mora: Yeah, I mean, um... 14:18:53 Will Abramson: What's up?... 14:19:01 Otto Mora: Yeah, I mean, I'm just echoing that I understand where Marcus is coming from, but I do agree with Joe's view on this, that... 14:19:04 ... It is a 14:19:22 ... Uh, something that, you know, is definitely going to be subject to change, and we do want to show. to the outside world, I guess, that we are… You know, kind of taking the work to do the resolution threat model, which is important, so 14:19:32 ... Uh, even though, yes, okay, his point, yeah, formally discuss it in the call, okay, fine, but I do agree with Joe's positioning here, I think it is correct. Uh, I guess, yeah, that's it 14:19:55 Will Abramson: Yeah, so I think I'll add maybe just to close unless anyone has anything else. I think we can say now that we are going to discuss this again tomorrow and I will message Marcus to say that, right? But if he can't make the call, I think we should just overrule and leave these... 14:20:01 ... sections in. I mean, the other section that we've not talked about is section 10, so maybe we can just briefly discuss that, like 14:20:05 q+ 14:20:10 ... Uh, again, this is… this is non-norm… I don't think there's any normative statements in here, um, so maybe it's… it's not as important, and we could just get rid of this at-risk marker for now 14:20:14 ack JoeAndrieu 14:20:14 ... I mean, it's obviously entangled with digital URL dereferencing, so it's definitely going to be under discussion in CR 14:20:20 ... I mean, maybe, like, you know, if that's the easiest path to just move forward, perhaps we do that 14:20:23 ... Joe 14:20:26 Joe Andrieu: Yeah. Two things. One is to correct some notion about normative... 14:20:31 ... Any section in here that is not marked as non-normative is normative 14:20:34 ... Um, so whether or not it has shoulds or may, this section is normative 14:20:46 q+ 14:20:47 ... And it would be very easy for a later edit to add a normative thing. So if if we intend for sections to be non normative we need to mark them as non normative 14:21:00 ... that might be one step towards including, you know, the resolver architectures as, you know, a compromise direction, if ultimately that's where we went. Um, but this is at risk because it's part of dereferencing. So 14:21:13 ... Um, right now, I do not believe we have group consensus, and I think we had a resolution to the effect that, um, we are not going to have a dereferencing function as a call, and this was the result of that function 14:21:16 ack manu 14:21:19 ... So I think this is just all bundled up in, you know, we're still figuring it out and trying to come to terms over what dereferencing is 14:21:22 Will Abramson: Mario?... 14:21:44 Manu Sporny: Yeah, plus one to that. I do think we need to go through and explicitly mark sections as informative or normative. That is, you know, editors typically do that much earlier in the process than this. And what that does is it adds... 14:22:03 ... piece of text underneath that section that says this section is informative, uh, and Joe's right. This doesn't have it written as that, and therefore this section is normative, um, even though it does not have any normative, um, statements in it, and also plus one to, like, we have not agreed. that this is, you know, the output here, and so it 14:22:03 should be marked as at risk 14:22:08 Will Abramson: Okay, um... 14:22:19 ... Yeah, so… yeah, I was kinda hoping we were gonna get to merge this today, but I think that's not possible, but we can review it again tomorrow, and uh 14:22:36 ... You know, hopefully get through this. I hope Marcus is on the call and we can just talk through this. I mean, one of Marcus's pushback is as all, you know, as he's been saying throughout this, for instance, like, there are people who are depending on this did resolution result. He thinks if, I mean, not to put words in his mouth, but I think he 14:22:36 thinks that if we remove this, we're going to harm Interop 14:22:52 ... But I think I am more in agreement with the rest of the group, which is, you know, we haven't really agreed this. It's all on discussion. I think we have passed some resolutions which impact this, particularly around HTTPS binding 14:23:10 ... I think there is maybe a compromise that we were exploring, but then just didn't quite get to around. Leaving the HVS binding section in as informative. I'm not sure, but I think all of this needs more discussion and that's part of the problem, right? We don't want to have any more discussion. We want to just 14:23:16 ... get something that we're happy with, which is just a resolution algorithm. into CR, right? So 14:23:32 ... Uh, yeah, I mean, personally, I don't care how often I'm in favor of marking this section at risk and just moving forwards, but I can appreciate that, because it came as a surprise, so… this discussion. Hopefully we can have that tomorrow. Um… Okay 14:23:38 ... Uh, any final comments before we move on to Joe's panel? 14:23:46 Otto Mora: No... 14:23:53 Topic: DID URL Dereferencing Algorithm 14:23:56 subtopic: https://github.com/w3c/did-resolution/pull/344 14:24:07 Will Abramson: So it's issue 3, 4, I mean, PR 3, 4, 4, sorry... 14:24:20 ... Yeah, I don't know how it's best to go to this. I don't know, Joe, if you have things you want to, like, lead the group through, or we can just go over it. Maybe I can share my screen and we can review the comments. I'm not sure. Or does anybody? 14:24:24 Joe Andrieu: Yeah, I would just… I would just review the comments. I don't… I… Don't have a better way to go through it... 14:24:27 Will Abramson: Good. Uh, excuse me... 14:24:35 ... So… this 14:24:42 ... You should see my screen, although, also, I'm not looking at the queue, so maybe you could do the queue 14:24:44 Otto Mora: Yeah. Yeah, I got you... 14:24:50 Will Abramson: Yeah, so this is… let me look at the preview, um... 14:25:02 ... First, maybe we can just ask, has everybody had a chance to review this algorithm from Joe? Or are there folks who still haven't had a look at the spec text that Joe's proposing yet? 14:25:10 Manu Sporny: I've glanced at it briefly, but have not had a chance to look at it in detail... 14:25:14 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): I have definitely not reviewed it, but that's not a blocker... 14:25:25 Will Abramson: Yeah, well, that's fine, but I wonder if maybe it is worth, you know, you just sort of walking through the steps. I mean, I can have a go, but you probably know a bit more intimately than me... 14:25:28 Joe Andrieu: Uh, through the content? Yeah, I could walk… yeah, we could do that. Um... 14:25:31 Will Abramson: It's here, right? Section 365. Oh, it's actually the whole... 14:25:34 Joe Andrieu: Well, go ahead and go up to the first one because those are also edits. Um... 14:25:47 ... There was a there was a different style than what I had written before. So and there were some elements missing about prepare for resolution. So those are changes 14:25:51 ... For example, and prepare for resolution, we validate 14:26:04 ... And that did URL. Then we select a resolver. So that's something that hadn't been in the current documentation. And then remove the fragment. That's currently what we do. Um 14:26:07 Will Abramson: Yeah, so this will have to be updated, right, to be just a DID, I think... 14:26:12 ... Yep, yep. Yeah, yeah, yeah 14:26:17 ... Right. Yeah, yeah, yeah, sure 14:26:20 Joe Andrieu: Correct. Based on current, like, right, so these have all been things that have happened since IPR. Um, I'll also have to pull in the at-risk markers, right? So there's… there are some just logistical edits that... 14:26:29 q+ 14:26:35 ... if if if people have easy edits, I'm happy to take them as suggestions. But just yes, I'm aware that those those things need to be updated. But the the main difference in that 1st one is explicitly saying, selecting a resolver is part of that process. Um, but 14:26:55 ... And then the second one is you resolve the did by calling, and interpreting the response repeat as necessary. The reason I know there's a comment from, Stephen about why are we repeating? And that's because for some algorithms 14:27:06 ... Um, for some DID methods, we know that, in fact, it is an iterative process. Um, DIDBCCR2 is this way. Um 14:27:19 ... Because you may not know what data is needed to resolve until you're doing the resolution and you may not know all of it until you go through the entire process. So you have to look at the response and resolve and see if there's a next step or not. And if there is a next step, you have to keep going. Keep going on it 14:27:24 ... Um, so 14:27:31 Will Abramson: Yep, great... 14:27:34 Joe Andrieu: happy to get changes to make that clearer if the language is unclear, but I just wanted to speak to the question Steven had, um, even though he's not here, we'll... 14:27:38 ... I sort of socialize why that difference is there 14:27:42 ... Okay, determined handling strategy. So this was updated to address 14:27:58 ... What I think our current consensus might be, there are issues around query parameters, and so I do not include that here. But I embrace the group having a conversation about how do we want to deal with query parameters in the DID URL 14:28:11 ... and whether or not they should be how they should affect determining the handling strategy beyond services. So the the 1st one and I wish we could see the diagram. Um 14:28:16 Will Abramson: Uh… Or maybe I can... 14:28:18 Joe Andrieu: I put those in for you, Ted. Uh, you had mentioned how useful that is, and I don't disagree as a requirements guy. I'm like, hey, I've got tools that could make that... 14:28:22 Will Abramson: This one, uh, this one, this one. Uh... 14:28:25 Joe Andrieu: So that's the easy one This is the more complicated one but, there is an effort to try and give a visual explanation of what I'm about to walk through... 14:28:28 Will Abramson: Well, maybe I can... 14:28:45 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, I appreciate the effort. I'm just looking at these quickly and noticing contrast definitely needs to be checked with the tool. I'm pretty sure that the top two colors will want white text if they're going to stay those colors. The other thing is these seem to have colors... 14:28:52 ... That are meant to be interpreted as something, and that being the only difference, and that's… That cool 14:28:53 Joe Andrieu: They only indicate for the eye to follow that line... 14:28:56 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Okay... 14:29:01 Joe Andrieu: There's no semantic difference... 14:29:07 ... So I… and I appreciate the accessibility point, and… Let me… yeah, let me see if I can recolor 14:29:09 ... They're intended to be pastels, but I agree. We should check it with a tool 14:29:10 Will Abramson: Yep... 14:29:13 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): We don't have to hammer on that right now. It's just a thing to have in mind... 14:29:16 Joe Andrieu: Yep, I appreciate that... 14:29:19 Will Abramson: I mean, is it worth going over the algorithm through this diagram, or do you want to go back to the text?... 14:29:25 Joe Andrieu: Sure. This may be easier. So first of all... 14:29:34 ... Um we check if there's a service query And if there is, that's what we use. Um so if there's multiple service parameters then that exits to an error 14:29:42 ... So we produce some kind of error, and I just have raise errors or the exit for any of these that hit an error 14:29:45 ... And then second, as you use a service selection algorithm 14:29:49 ... Um 14:29:58 ... And that basically says match to the service algorithm that has the same ID as the value of the parameter, right? It's a very simple algorithm. Um, and 14:30:06 ... And if that selection algorithm has a handler strategy. Um, then we use it 14:30:15 ... If it does not, I created a default service handler strategy, which deserves debate and input 14:30:34 ... It was an attempt to say, Hey, we've got a bunch of services out there that didn't realize that they should be defining a handler strategy. Btcr. 2 is one of them. And so if someone attempts to access a service that's in a Btcr. 2. That's really meant to just be a beacon 14:30:47 ... and not be dereferenced, well, then what do we do? And I… so we came up with a strategy, we can look at that strategy, and argue about it if we like. Um, but that's… both of those, then, you're done with the service, uh, loop 14:31:02 ... So if there isn't a service query parameter, then we look to see if there's a path handler. And that basically means seeing if there are any objects in the did document, and I believe we should include the two metadata documents 14:31:18 ... to look, and I think that's what's in the text, um, to see if any of them have a type of path handler. So if they have a type of path handler, they're saying, yes, we are a path handler. Um… And then we use the path value in the path handler 14:31:25 ... Um, to pick one of them. Um, and hopefully there's only one. If there are two, that creates an error. Um 14:31:33 ... We can talk about that path handling path matching algorithm, but it was designed to hopefully work with how, Steven was thinking about it as well 14:31:47 ... If there are no multiples, then does the path handler have a type definition? That would explain how you do the path handling. For example, is it a path handler and a path service? Then you 14:32:04 ... would use the past service handling strategy. Um, if it doesn't have a secondary type that explains how you would do the handling. Then, we raise an error 14:32:09 ... Um, because we… although we have identified it as a path handler, it didn't identify how you actually do the handling 14:32:16 ... But if it does, we set the handler to that and that gets us to the inbox there. Sure. No, no 14:32:19 Will Abramson: Is it a good time? I have a question, but maybe we'll let you go through it all. I don't know what's best... 14:32:23 Joe Andrieu: By all means... 14:32:37 Will Abramson: Yeah, so my question is really… I think it was Steven that raised this in the issues, um… in the comments, rather, and he's saying… so say we go… like, we just… we have a DID URL, but really that DID URL is just a DID, right? We're starting this DID URL... 14:32:45 ... did your LD referencing process, and the DID document that's returned from Resolve contains a path handler 14:32:48 Joe Andrieu: Yep... 14:32:51 Will Abramson: uh, like, contains this… a service, for example, with a path handler type. What… what should happen?... 14:32:53 ... Right 14:32:56 Joe Andrieu: Um, so there is a path handler. You would use a path handler, path matching algorithm... 14:33:02 ... And if there is a path handler that matches on an empty path, you would use that path handler object 14:33:04 Will Abramson: Okay... 14:33:07 Joe Andrieu: To continue, and if that path handler object has a handler strategy. Um, then you would use that... 14:33:13 Will Abramson: Yep. Right, but if there isn't a match... 14:33:25 ... it's gonna be an error. Like, what I'm saying is, like, that… in that case, or I think what Steven was really saying, in that case, there is no way for that DID to be referenced to just a DID document 14:33:29 ... Doesn't seem like it 14:33:39 Joe Andrieu: Um... 14:33:43 ... Yeah, that's an interesting, uh, point, and uh… Actually, in my brain, I had… I stopped 14:33:55 ... Going through the algorithm to see if he might be wrong, because the easier solution may simply be to identify where, when we raise an error 14:34:01 ... Maybe we should always default back to the did documents path handler 14:34:05 ... I mean, uh, handler strategy 14:34:10 Will Abramson: Yeah, so, I mean, in this case, it would be effectively if you don't manage to identify a path handler. Um... 14:34:14 ... You would fall back to the document, right? 14:34:22 Joe Andrieu: Right. And that may be the right strategy for all of them. So maybe it's raise error and then go to use default document strategy. Maybe that's a better… Strategy... 14:34:25 Will Abramson: uh... 14:34:29 ... Yep 14:34:31 Joe Andrieu: Right now, I'm thinking it is better, like, because what else do you do? You raise an error, and then you end, and then you got... 14:34:31 Will Abramson: Yeah... 14:34:32 Joe Andrieu: um... 14:34:35 Will Abramson: Yeah, I agree, actually, because you're gonna have a DID document when you get here, aren't you. So, yeah... 14:34:36 Joe Andrieu: Right... 14:34:39 Will Abramson: Uh, the other question... 14:34:59 Joe Andrieu: So if you fail any of the fancy dereferencing, I think it probably is appropriate. I want to think through that from a security perspective or unexpected consequences, but it feels right on first blush to me... 14:35:03 Will Abramson: Yeah, the other question I had is this path handling matching? Is… is this… like, say, like… is this, like, the… this is the largest path, right? So, like, say if I… I am just this slash path... 14:35:16 ... and then I… there's a path service and slash service, or whatever it is, like, would that just match? Because that's the largest… path, like, it's one, and it's the largest one. I don't know 14:35:20 Joe Andrieu: If, if you had, um... 14:35:33 Will Abramson: It's interesting... 14:35:45 Joe Andrieu: Uh, a URL with a slash as the path, and you had a service operative slash service? Um, in the current algorithm, that would match... 14:35:48 ... Um, I'm not sure it should 14:35:52 ... Um, but that was my interpretation of… of how I thought Steven was trying to do it. Um, I'm happy to revise if we think there's a… if it shouldn't… if it can't match the whole thing 14:35:55 Will Abramson: Great, thanks... 14:36:09 Joe Andrieu: Um, should it match at all, is a reasonable question. Um... 14:36:10 ... I'm pretty sure what, um… Steven was imagining… is that you… in your PATH service, you 14:36:13 Will Abramson: Hmm. Okay... 14:36:17 Joe Andrieu: Um, are saying, hey, uh, this… this token is like a folder. And everything below this folder is accessible via this path service... 14:36:23 ... Right, so if you have slash images, and slash images is your path in the service object 14:36:34 ... then, you know, pathImages slash avatar.png is legitimate, and it would use that service handler, unless there's a specific override for a path handler whose path is services slash avatar.png. Um, but if it's an incomplete match. Maybe that should not be a match 14:36:38 Will Abramson: We'll have something to think through. um... 14:36:42 q? 14:36:47 ... So again, I'm not managing the queue auto, so if there are other people who have comments, otherwise 14:36:47 Joe Andrieu: Okay... 14:36:50 Will Abramson: Uh, Joe, just keep going, I guess... 14:36:54 Otto Mora: Uh, I see Ted. I see Ted in the queue... 14:36:55 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Oh, that was old... 14:36:56 Joe Andrieu: Okay... 14:36:57 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Sorry... 14:36:57 ack TallTed 14:37:00 Otto Mora: I don't know if it was… that was… oh, okay... 14:37:05 ... Okay 14:37:10 Joe Andrieu: So those are the two sort of advocated strategies. I want to be clear that the rest is all fallback. Um... 14:37:18 ... For then the next two are explicitly for legacy reasons So are there any document properties that define a handling strategy? 14:37:38 ... Such as linked resources. And if there are, then you have to process them. And if there are multiple, then we treat that as an error 14:37:48 ... That's sad, but I'm not sure how better to do that other than to put it into some sort of matching algorithm, but we don't know what those strategies are matching on. That's sort of the problem with the legacies. We don't know that they have a path property that we could plug into the path. Matching. Um 14:38:06 ... But if there are no multiple effective properties, then you use that defined by the property. So if someone has linked resources, then you should go use the linked resources handler. And if you don't know what that is, that's going to be an error. But the handler is. Uh, should be the linked resource handler 14:38:17 Will Abramson: And just to clarify, multiple affecting properties would be like, I have a DID document with, like, linked resources as a property, and linked objects as a property, right? Like, two separate named properties that... 14:38:20 ... I know as a dereferencer both affect dereferencing in different ways 14:38:23 q? 14:38:23 ... Is that correct? 14:38:27 Joe Andrieu: That's right. And so, you know, if we think about did linked resources and linked resources... 14:38:31 ... Um, this is basically saying, if you mix them, we're gonna error out. Because 14:38:41 ... Those two features were independently developed, and it's… it's not clear to me even today which one you would… Try to apply 14:38:48 ... I mean, theoretically, you would do some sort of 14:38:55 ... Uh… secondary salience question 14:39:02 ... For example, with linked resources. We do have a path property. So you could say, hey, if that path matches. That's part of the algorithm. Um 14:39:21 ... But I don't know an easy way to bubble that up. Um 14:39:28 ... And I don't know for linked resources if it has a similar anchor. In other words, is there a way in did link resources to say, hey I do have a did link resource object but does it apply to this did URL? I don't know if anyone can speak to that 14:39:32 ... Um 14:39:38 ... But we could potentially put into this algorithm that the 14:39:49 ... We are actually, if we find properties, we then check to see if those properties apply. Then we do the test on multiple affecting properties 14:39:53 ... Because at least with linked resources, you can know if it applies or not 14:40:00 ... So I think that is a constructive addition to this 14:40:19 ... So a simple step in there between those two yellow diamonds, that is, add a check for saliency. And I might try and find better language when we write that up. But hopefully that's clear to the group that we're talking with right now 14:40:31 ... All right, moving on to the green. Metadata properties. Is checked after did document properties. If the group 14:40:41 ... So, we could merge this with the one above it, and say, find any properties in the documents metadocu… metadata and treat them as a single bundle 14:40:45 Will Abramson: Right, because at the moment, this is kind of having a hierarchy, a little bit... 14:40:48 Joe Andrieu: I guess edit... 14:41:06 ... That's right. And what was important to me was to have a hierarchy. Um 14:41:10 Will Abramson: Yep... 14:41:20 Joe Andrieu: But I don't... 14:41:20 q+ 14:41:23 ... I don't know that that's a distinction. Like, I do… I very much want service 14:41:29 ... to be a get out of this process. mechanism 14:41:41 Otto Mora: Mm-hmm... 14:41:42 Joe Andrieu: Uh... 14:41:42 Otto Mora: I do see Manuel on the queue... 14:41:45 ack manu 14:41:48 Joe Andrieu: But I'm curious if people agree that we want to elevate the document properties above metadata document properties. Or should we revise this to put those together? Because they're basically both the same. Um, you know… You've got some properties. Um… do we have multiple properties? Then either use the handler if we have a single 14:41:48 property, or we use… or we do an error... 14:41:51 Manu Sporny: Yeah, just because you asked for an opinion, Joe. It does feel like... 14:42:06 Will Abramson: Yeah, that's interesting... 14:42:10 Manu Sporny: the DID method specific handling strategy might need to take, at least to me, gut says it's more important than the metadata-based one, but I could easily see someone, you know, arguing the opposite... 14:42:11 Joe Andrieu: Oh, interesting. The blue one that I haven't gotten to yet, you think should go before... 14:42:26 Manu Sporny: Yeah, because, I mean, like, it feels like metadata is just stuffing the handling strategy into the kind of, like, you know, deepest, darkest hole in all the choices... 14:42:57 +1 to the diagram being very helpful 14:42:59 ... Um, but I can see how someone would be like, but no, that's exactly, you know, where it should go, and that's, you know, and, you know, we did that so it doesn't get in the way of anything else. I don't know, there's so many different ways that, you know, this could be done. Um 14:43:03 ... I don't think it really matters, so it's not a strong opinion. I mean, the other thing that I was, you know, thinking about… so the diagram's great, thank you very much, Joe, for doing the diagram, thank you, Ted, for suggesting we do it. This is so much clearer than trying to, like, you know, wander through 14:43:06 ... tons of text. It's much easier to get a mental model on what's going on with this 14:43:23 ... Um, I do have a question on, like, you know, which parts of this, Joe, do you think Marcus or Steven would disagree with? Um, I know we've got a lot of comments to kind of take a look at there. Um, the other concern I have is, you know, folks from the TAG, you know, maybe they look at this and they're like, this is really complicated. Like, 14:43:24 can't you make it simpler? 14:44:07 ... And I think the response to that is, like, we are documenting reality. We would all prefer something simpler than this, but this is what, you know, the hundreds of DID methods that have been registered, you know, taking a survey from all of them, this is what we think works for. All of them. Um 14:44:10 ... So it's very much the HTML5 based. approach to spec development, which is reflect reality no matter how horrible and ugly it is, versus the XHTML2-based approach, which was try to come up with something that is, you know, fairly theoretically pure, but does not necessarily reflect what's happening out there on the. Uh, on the… on the web. 14:44:11 Um… Just some thoughts. That's it 14:44:18 Joe Andrieu: Let me ask Amanda, you suggested maybe putting the DID method, which is the last one we didn't quite get to, before the green one. Um, yeah... 14:44:24 ... So do you like then the hierarchy that separates the did document properties from the metadata document? 14:44:51 ... You know, I'm just double checking my bias because, you know, that happens, our own experiences and whatever. This does prioritize linked resources over did linked resources, but that's not my intention 14:45:05 ... Um, it also prioritizes the new path handling path service stuff above both of those, right? So I think we are making some priority choices. Um, and I was just looking for some feedback as to whether or not, am I just following my bias, or does that feel like, in fact 14:45:08 Manu Sporny: Don't know if I understood the question. My gut says yes, uh, for the question you asked, but I'm afraid I'm misinterpreting the question you're asking. Yes, ma'am... 14:45:11 Joe Andrieu: You know, going from the more concrete to the more abstract... 14:45:13 ... Which is what it feels like to me. Like, there's always did document stuff. Um, did resolution may or may not have interesting things in metadata 14:45:15 Manu Sporny: Mm-hmm, yes... 14:45:18 Joe Andrieu: Um... 14:45:19 ... So many processors for dereferencing will never look at the resolution metadata 14:45:22 Manu Sporny: Mm-hmm, yes... 14:45:28 Joe Andrieu: Um, so that's… that's how I came up with the hierarchy. I was just looking for feedback to… to check bi... 14:45:42 Manu Sporny: Yeah, I mean, I feel like, you know, if someone explicitly puts something in the DID document, or they explicitly choose a DID method, a specific DID method, they're expecting... 14:46:03 ... those things to take priority, right? Like, I don't know if someone, you know, take two different approaches. If one of them is, like, you're gonna end up using stuff in the, you know, result, you know, metadata 14:46:04 q+ 14:46:08 ... versus something that someone explicitly put in their DID document, I would expect the person that put that thing explicitly in their DID document would want that thing to take priority over 14:46:14 ... Some other, you know, um, things that might be kind of… fairly hidden um 14:46:18 ... If that makes sense 14:46:29 Joe Andrieu: Yeah, it does make sense. So a principle of visibility here as a rubric to sort of evaluate. What should we look at first?... 14:46:45 Manu Sporny: That's right, and individual choice, meaning, like, I picked this… me, the human, picked this DID method… may have picked this DID method because I really liked the way it worked, and I have said something very explicit about what I want to happen... 14:46:49 ... I don't want something else to, like, come in and, like, override that for some reason 14:46:55 ... as the general guiding principle. Like, I mean, there may be good reasons that the metadata overrides or did resolution result 14:47:18 ... metadata overrides, you know, what the DID method does, but that, to me, feels backwards. We're trying to create technologies to empower individuals and let the individual state explicitly, this is what I want to happen, and it feels like if something that they don't quite see. comes in and gets in there, they might not like that. I know I 14:47:18 wouldn't… You know, like that 14:47:22 Joe Andrieu: Yeah. Interesting. I I agree. So I like that change... 14:47:26 ... I invite folks to chime in if they don't 14:47:29 q? 14:47:29 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, um... 14:47:33 ... Sorry 14:47:39 Joe Andrieu: One note of that, Manu. Sorry, I heard you, Ted, but I wasn't quite done. The, uh... 14:47:52 ... There's an interesting sort of attack vector in that… in the current diagram that you just spoke to, Manu, and I want to both speak to it and ameliorate it a little bit, which is that we're trusting a resolver 14:48:03 swcurran has joined #did 14:48:05 ... To resolve that did method appropriately. So on some level, uh, if we chose a did method, then the resolver should be applying the metadata correctly for that did method. Like, we have to trust them to do that 14:48:08 present+ 14:48:08 ... Um, but if they were to start putting weird stuff in, then, you know 14:48:12 ... Yes, rather, the… the 14:48:19 ... Metadata and resolution could be an attack vector 14:48:26 ... But I'm ameliorating that because, well, so could the DID document. Like, the resolver themselves could manipulate the whole thing if they were a bad actor. Um 14:48:36 ... But it is an interesting challenge. I think the visibility feels like a tighter rubric. Did the users who choose this understand what the consequences were? 14:48:37 ack TallTed 14:48:39 ... And I'm done. Ted, if you want to chime in 14:48:45 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, yeah, I don't... 14:48:56 ... I don't think that we should be doing that much babysitting of people. If they chose the thing, let's assume that they understood what they were doing about it. We can warn them that they should be careful 14:49:04 ... But once they do it, let them see what happens. That said. I'm thinking that this 14:49:13 ... This last hop out, did method define a method specific handling strategy? That should be the first out 14:49:17 ... And it doesn't matter if there's a path handler if the did method says do this 14:49:18 q+ 14:49:21 ... For instance 14:49:28 Joe Andrieu: How's the queue? Do we have anyone on the que... 14:49:29 Otto Mora: I see, man. Man. I got Manu after that... 14:49:31 q+ 14:49:32 Will Abramson: Thank you, Matt... 14:49:35 q+ 14:49:36 ack manu 14:49:45 Manu Sporny: Yeah, I don't agree with that, Ted. I do understand, I think, the philosophy that goes into that, you know, which I can see, right?... 14:50:03 ... I think if we do that, though, we, uh, we, we slip down a bad, like, inconsistency path, meaning, like, I think we really want 14:50:17 ... this path handler stuff to be the way people use, you know, paths. And if we get, you know, multiple DID methods, potentially a really popular DID method doing something other than that, we fail to achieve that 14:50:27 ... kind of unified path handling strategy, uh, approach. That's… that's the only thing I'm concerned about. You know, if we adopt that approach, Ted, then all of a sudden, this… this unified approach 14:50:34