14:52:12 RRSAgent has joined #did 14:52:16 logging to https://www.w3.org/2026/06/18-did-irc 14:52:20 rrsagent, make logs public 14:52:31 Meeting: Decentralized Identifier Working Group 14:52:38 Chair: ottomorac 14:52:42 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0020.html 14:52:42 clear agenda 14:52:42 agenda+ Agenda Review, Introductions (5 min) 14:52:42 agenda+ TAG Issue - hedgy DID Parameter text (5 min) 14:52:42 agenda+ DID Resolution PR review \[1\] (10 min) 14:52:42 agenda+ Threat Modelling Discussion (30 min) 14:52:45 agenda+ Next Time (5 min) 14:53:01 previous meeting: https://www.w3.org/2026/06/17-did-minutes.html 14:53:12 next meeting: https://www.w3.org/2026/06/24-did-minutes.html 14:55:32 markus_sabadello has joined #did 14:58:10 transcriber-bot, connect 14:58:24 transcriber-bot has joined #did 14:58:34 transcriber-bot, connect 14:58:35 scribe+ 14:58:51 transcriber-bot, pause 14:58:51 scribe- 15:00:23 Wip has joined #did 15:00:26 present+ 15:00:28 TallTed has joined #did 15:03:51 present+ 15:04:21 smccown has joined #did 15:04:48 transcriber-bot, resume 15:04:48 scribe+ 15:04:50 present+ 15:04:56 zakim, next item 15:04:56 agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot] 15:05:04 present+ 15:05:10 danpape has joined #did 15:05:11 Otto Mora: Um, yeah, so for… for today, uh, we have, uh, one of the leftover issues from the… the tag review, where there was some text that, uh... 15:05:22 ... could be kind of bottom down, and and I think it's a good catch from the the folks that did the horizontal review that we have that 15:05:25 ... Then we also have a PR review on 342 15:05:42 ... and so hoping to close that one down pretty soon, and then we have a reserve the rest of the call for a discussion on thread modeling 15:05:51 ... uh, to pick that up again, which kindly Joe has, uh, again, uh, volunteered his time to kind of guide us through that conversation. Um 15:05:52 https://github.com/w3c/tpac2026-meetings/issues/64 15:05:58 ... There is also something that I wanted to bring up, which is this, uh, TPAC 15:06:03 ... Uh, meeting a session request that, uh, we submitted 15:06:20 ... earlier this week, and in it, we request, uh, effectively 4 slots, which amounts to a day. Uh, we're pretty flexible right now in terms of 15:06:32 ... dividing it between, uh, you know, half days, or just doing it all together. Uh, and then we specified that it should avoid the Verifiable Credentials Working Group 15:06:44 ... And I think I saw also some comments there from — what's his name? Ian from the payments group, I believe, where he also mentioned it in two of the other issues. But yeah, first off, any reactions to that one? 15:06:51 ... From anybody? Uh, I'm guessing, yes, this is an ongoing process of agenda building for… Or that'll be it for the TPAC. um 15:06:58 ... Uh, also, generally, any other, uh, additions to the agenda, or topics that folks would like to bring up? 15:07:04 ... Let's see 15:07:07 zakim, next item 15:07:07 agendum 2 -- TAG Issue - hedgy DID Parameter text (5 min) -- taken up [from agendabot] 15:07:07 ... Okay, so 15:07:14 https://github.com/w3c/did-resolution/issues/341 15:07:21 ... Uh, yes, so this one, it's, uh, issue 341. Um 15:07:29 q+ 15:07:30 ... Which I'll just share because I think it'll be easier to just kind of navigate through it here. And 15:07:38 ... So there was a observation from the folks in TAG 15:07:53 ... and that will did catch, which was this text in in the beginning, I believe, of the of the spec, where it says that the parameters might be reused if there is a clear case use case and then that might languages 15:08:03 ... kind of considered to be hedgy, or I guess should be tied down, and that they were recommending that it should be… it would be better to have it as it should 15:08:20 present+ 15:08:20 q+ 15:08:20 ... And the text, the green text box below it should also perhaps be considered to be normative. So the section in question is this one here, did whatever might be used if there's a clear use case where the whatever needs to be part of a did URL 15:08:23 ... Considering whether that should be a should and whether this green text here 15:08:28 ... Uh, would be, uh, a good, um 15:08:42 ... candidates for making it now normative. Uh, so that's… that's sort of the consideration there. Uh, and I know that then there was also some reactions from, um 15:08:42 ack Wip 15:08:47 ... Marcus to it about it as well. But I'll pause right there. I see Will already. So go ahead, Will 15:09:01 https://github.com/w3ctag/design-reviews/issues/1157#issuecomment-4602993561 15:09:03 Will Abramson: Yeah, I think that was a good summary. Yeah, so this just came about as I was trying to reply to the TAG design, the TAG review... 15:09:17 ... I have now replied to them and just let them know our status and all this stuff. And this is the one remaining issue in DID resolution that we need to address. I think Stephen maybe already has, or this came up as part of one of Stephen's PRs, so maybe it is going to be addressed through that. I just wanted to… to 15:09:23 ... make sure everyone has some attention on it. In case people have differing opinions. About how we should handle this 15:09:26 Otto Mora: Hmm... 15:09:33 q+ 15:09:35 Will Abramson: I think the easy solution is literally just to do what they're telling us to do, right? Make that a should, and turn that note from a note into a... 15:09:36 ... Bit of normative text 15:09:37 ack manu 15:09:42 Otto Mora: Right. Yeah, I agree. Manu?... 15:09:58 Manu Sporny: Um, I wouldn't object to it turning into normative, but I mean, you know, the whole reason we have normative statements is to make it so that it's testable. If this is a normative statement, it's really a normative statement on a did method. Um... 15:10:06 q+ to say I'm not sure this guidance is good 15:10:15 ... which we don't have, I don't think, a conformance class for in the spec. Like, it just creates this waterfall of effects where it's like, do we really want to… do that, right? Um 15:10:22 ... So the other way to do this is to move it into. Uh, did core 15:10:41 ... And because that spec does have a conformance class for did methods and it does have a requirements for did methods section. So that's my suggestion is remove this text 15:10:55 ... Uh, and rewrite it so that it fits in DID core instead of, like, reintroducing or figuring out a way to introduce the conformance class of a DID method into this spec, and then spread the requirements for DID methods between two different specifications, which people 15:11:04 q? 15:11:08 ... Did method implementers would have to, or did method authors would have to then read both specs. I mean, they're going to do it anyway. Hopefully that makes sense. Like, let's just put this all in one place instead of spreading it between two specs. That's it 15:11:09 ack markus_sabadello 15:11:09 JennieM has joined #did 15:11:11 Otto Mora: Okay, I see Marcus. Go ahead... 15:11:19 present+ 15:11:32 Markus Sabadello: I remember when we put this green box in the specification, this question has come up a few times in the past, like when should something be expressed as a parameter and when should something be expressed as an option? Question... 15:11:40 ... There are some… some situations where 15:11:50 ... where both… both make sense. For example, if you look at methods such as didSkid, or didCarry, or didSell, um, you're passing these 15:11:55 ... You're passing this additional information that's needed for resolution, and 15:12:10 ... sometimes it makes sense to pass that as a parameter as part of the DTRL, and sometimes it makes sense to pass those things as options, and we've had this discussion a few times in the past, and that's 15:12:20 q? 15:12:23 ... why I think we wrote this… this box to… to provide some… some guidance when something should be part of the DTRL, and when… when something should be… Should be an option 15:12:38 ... I think it would be fine to just turn this into a shoot, as it suggested in the comment. Um, I'm 15:12:42 ... didn't really fully understand what Manu said. I don't think this is 15:12:44 q+ 15:12:50 ... DIT method specific. I think this is something that's a generic question or guidance about DIT parameters and options. In general, um 15:12:55 ... So anyway, I don't feel strongly about it. I think turning it into should would work 15:12:58 Otto Mora: Yes, yes... 15:13:02 ack JoeAndrieu 15:13:02 JoeAndrieu, you wanted to say I'm not sure this guidance is good 15:13:07 ... Yeah, I'm curious about that testable aspect as well. That's interesting. Joe? 15:13:09 swcurran has joined #did 15:13:13 ... You might be on it 15:13:16 present+ 15:13:18 "A DID method can use DID parameters for use cases ..." 15:13:32 Joe Andrieu: I was muted. Thanks. I think the guidance here is a bit of a category error or layering error. But I do like the first sentence or two in the green box. I think we should elevate that from a note and treat it as normative... 15:13:48 ... Like that because we need to do we do need to describe the difference between the options that are passed to resolution and the did URL query parameters. But the reason I think it's a it's a category error or a layering error 15:13:53 ... is because the DID URL author is likely not the resolving party 15:14:10 ... So the resolving party is the one who's going to add options like we do with HTTP headers, but the URL, the DID URL, came from somewhere else. So the party who is crafting the DID URL doesn't have an opportunity to tell the resolver, hey, put these 15:14:25 q? 15:14:26 ... these parameters in the options, they can only put it in query parameters. So I think we don't have the surface for people to be responsive to this guidance. So I think we should just be silent on when, which. Situation is more appropriate 15:14:29 ack manu 15:14:34 Otto Mora: Banners... 15:14:40 ... Okay, yep 15:14:50 Manu Sporny: Yeah, let me share my screen to, um, show what I'm talking about, uh, to, uh, Marcus. So, this is the DIDCOR spec. In our conformance section... 15:15:00 ... which all specs need to have. We define the conformance classes. and the rules you have to follow 15:15:17 ... One of those section or one of those conformance classes is a conforming DID method. So Marcus, I didn't mean to imply this is specific to a DID method. It is specific to all DID methods. If we change it to a should, that is guidance for all DID method authors 15:15:28 ... And so, we have a conformance class in did-core, and we have a section that tells did-method authors what to do 15:15:46 ... who are writing DID method specifications, what they must do in their specification, and what they may do, and what they should do. And the text that is… that we're looking at seems to be text that should go into this long list of things that we say people should and shouldn't do 15:15:54 q+ 15:15:56 q+ to say DID methods don't write DID URLs 15:15:56 ... Uh, because the guidance is specific to, uh, how you write a DID method specification, um 15:16:08 Otto Mora: Mm-hmm... 15:16:11 Manu Sporny: uh, which a resolver needs to pay attention to. So that's what I'm saying, is that, like, we already have sections in the dude core spec that talk about stuff like that. Let's move this statement into there, rather than splitting it out, um, and putting it elsewhere... 15:16:15 ... That's it 15:16:18 Otto Mora: Okay. Uh, yep, thank you for clarifying. Uh, Marcus?... 15:16:19 ack markus_sabadello 15:16:31 Markus Sabadello: Uh, thanks for explaining about the conformance classes, but I don't think the text in question is in... 15:16:35 ... in a section that has anything to do with DID methods, right? It's in a section about 15:16:42 ... didParameters, so if we have text in the didParameters section 15:16:47 ... How would that affect the methods conformance? I don't really understand that 15:16:49 q? 15:16:56 Otto Mora: You seem too odd to remember in those parameters... 15:17:01 ack JoeAndrieu 15:17:01 JoeAndrieu, you wanted to say DID methods don't write DID URLs 15:17:05 I don't care enough to keep discussing this topic -- we can move on, I won't block in either case. 15:17:10 ... Either being moved to did resolution or or something to that effect recently. Sorry. Uh, but yeah. But 15:17:13 ... You're on mute, maybe 15:17:28 Joe Andrieu: Sorry, plus one to what Marcus just said. I think there's some conflation about who controls which elements of this. Did methods don't decide what query parameters are in a did URL... 15:17:51 ... the DID URL author does. And so, I think this… the guidance here is just off, because we… it cannot be applied by anyone in the system, unless they control the entire stack. So, if it's my DID method, and I'm creating the URL, and I'm calling the resolver, then I could decide, is it part of my DID method spec? Is it part of the DID URL? 15:18:03 ... Or do I put it in the options like an HTTP header? But those roles are all by three different parties. And so we don't have a way to give guidance to someone who could pick and choose which one of those are happening. What we can do is say, hey 15:18:16 ... If you need to override an option, then when you call resolve, you can provide options, and that is, you know, the mechanism that I think we are planning on. But this guidance suggests functionality that I think our specs just don't have 15:18:18 q? 15:18:27 Otto Mora: Yeah... 15:18:30 +1 to removing the text 15:18:31 ... Um 15:18:36 +1 remove the text 15:18:36 ... There's diverging opinions on this one 15:18:41 ... Steven is… seemed to be citing 15:18:46 q+ 15:18:48 ... With, uh, Joe here to remove, as well as Vanna to remove. Um 15:18:49 If we can't agree, remove the text. 15:18:50 ack Wip 15:18:53 ... Okay, go ahead, Will 15:19:04 +1 to remove 15:19:06 q+ 15:19:18 q+ to propose edit 15:19:19 Will Abramson: Sure, yeah. Um, yeah, I mean, removing text is fine. Really, I think I'm just… I would look to the group to say, okay, this is the action we want to take, and then someone just take it on, so we can reply to the tag and say, we've addressed your comment. When you say remove the text, are you meaning remove the text in the 15:19:19 green?... 15:19:21 Otto Mora: Yes... 15:19:24 Will Abramson: or remove the text in the green, plus that text that Jeffrey is suggesting should be a should... 15:19:24 Otto Mora: Yeah... 15:19:24 q? 15:19:26 Will Abramson: Like, are you removing all the text? And that is fine... 15:19:29 ack swcurran 15:19:31 Otto Mora: Okay, um… Uh, Steven... 15:19:49 Stephen Curran: Um, my PR does remove the last line of that, which says anything about a difference between parameters and options, and any sort of guidance to say you should use options for this or parameters for that. It just removes that. I think that's what we're talking about here... 15:20:04 ... And that's the text that I'm saying should be removed. As others have said, I think, as Joe said, that first part of the paragraph is very important and absolutely needs to be there. Um, so that's useful to have 15:20:09 ... Um, but that last part should be removed 15:20:13 ... That's it. And as I say, sorry, it's removed in the PR that I put in 15:20:15 ... Yeah 15:20:18 Otto Mora: OK, so your PR alters the green box to remove this last bit... 15:20:21 ... And then you're saying we should try to keep these two 15:20:43 ... Okay 15:20:43 q? 15:20:46 Stephen Curran: Yeah, and I believe there is a comment in one of mine that says something should be changed from a note, and it might be this one. I just haven't had a chance to look back at that one. I was going to look at it today, but it might be that one that is being asked in my PR to. Take it out of being a note... 15:20:47 ack JoeAndrieu 15:20:47 JoeAndrieu, you wanted to propose edit 15:20:51 Otto Mora: Uh… Sure... 15:21:03 Joe Andrieu: Um, yeah, I just want to put in my two cents as to what I think we should be removing here. I think the paragraph before the green is part of the guidance that I think is, uh, we should remove... 15:21:17 ... And then I would keep the first three sentences all the way through an additional one from what you highlighted. So that this is comparable to HCTP, I think is, you know, it's not normative, but it is useful. And then it's just that last bit, the important distinction is the guidance that I think 15:21:20 Otto Mora: Mm-hmm... 15:21:20 +1 to Joe's suggestion. 15:21:20 ... Mm-hmm 15:21:24 Joe Andrieu: is worth removing. So the bit before the green, and then that last sentence. What would be my proposal?... 15:21:27 Otto Mora: So what I'm… what I'm highlighting now… sorry... 15:21:30 Joe Andrieu: And and I'm sorry. And I meant turn what's in the green. To not be a note... 15:21:34 Otto Mora: To not be a note. Okay, so what I'm highlighting now is what you would keep, essentially... 15:21:37 Joe Andrieu: Yes... 15:21:43 Otto Mora: Remove this. Remove this last sentence and keep the highlighted things. Okay. Uh, plus one from... 15:21:46 +1 sounds good 15:21:54 ... So, okay, cool. Um… I will take this on, no problem. Um… So… Yeah 15:21:57 ... Okay, I'm gonna sign myself 15:22:02 ... Oh, but maybe that's because I'm not, uh 15:22:07 ... Managing the anyways, I'll I'll I'll I'll 15:22:14 ... Don't worry about that. I'll I'll do that later. But, yeah. Okay. I'. Okay, cool. Um 15:22:22 ... Will, can you assign that to me? For some reason, I'm not at that point on the… I'm done 15:22:25 Will Abramson: Sure. Never... 15:22:36 Otto Mora: Sure. Okay, cool. Okay, so quickly moving on to 3, 4, 2. We'll do it for a maximum of 8 min... 15:22:41 ... Because I want to let Joe have some time for the threat modeling discussion. So 15:22:47 ... Let me… What specifically? 15:22:53 Topic: https://github.com/w3c/did-resolution/pull/342 15:22:57 ... the PR 15:23:01 ... which is 3, 4, 2. Okay, so 15:23:15 ... I think there has been some recent updates on it, and we did discuss it yesterday, and I know that, uh, Joe also provided some additional inputs. uh 15:23:19 ... So, yeah. And 15:23:22 ... Don't know if maybe Steven wants to 15:23:29 ... Give us his last bit on that one, whether I guess you might be incorporating those recent comments from Joe, probably 15:23:32 q+ 15:23:49 Stephen Curran: Yeah, I haven't been able to update the comment Joe made, which is to the abstract. I think it would just go in as is. I can't remember. I've got to find that note again where it is. Oh, yeah, normative should not be in a note. That's the one. Um, so I'm pretty sure that is the same discussion... 15:23:55 ... So I'll take a look at that. But no, I haven't made any changes since our discussion yesterday 15:24:02 ack markus_sabadello 15:24:03 Otto Mora: Okay, no worries. I see Marcus. Probably you want to raise the. But the comments you. Go ahead... 15:24:13 Markus Sabadello: Yes, well, my objections to this change are well known, so don't want to waste time going over... 15:24:29 ... all of that again. I posted my summaries and my arguments on the mailing list. I think this is a really bad idea. I think it's a charter violation. But even if you want to make that change to the input 15:24:46 ... being a deed URL, then the pull request, I think, has a number of problems that I put in comments. For example, it makes no sense to first validate an input deed URL, then extract the deed 15:25:01 ... And then validate the deed again, because it's kind of implied that that must be valid if the deed URL itself is valid. And, uh… The way it's written, as I… when I reviewed it a few hours ago, it, uh 15:25:11 ... passes the entire DDRL to the resolver, including the fragment. Um, so I'm surprised to see, uh 15:25:17 ... re-approvals for this. I wonder if people actually read pull requests before they approve them 15:25:23 Otto Mora: Okay, you're mentioning… 611 here. or... 15:25:26 q+ 15:25:33 ack swcurran 15:25:34 ... Practice. Stephen, go ahead. Sorry 15:25:56 Stephen Curran: Sure, I'll answer the one on the did URL validation, then did validation. What I was envisioning was… the… Did you? URL validation? Might not know the details of the specific did so that... 15:26:00 q+ 15:26:11 ... It would validate that, oh yeah, this looks like it did, but doesn't go into the did specific validation, the did method specific validation. So for example, if I have a did WebVH 15:26:11 q+ to suggest we use the Base DID URL pattern here to name and describe the DID URL without the fragment 15:26:21 ... Um, that doesn't have a SCID in it, for example, that might pass URL validation, but not pass DID validation 15:26:31 ... Um, so that's the reason. Um, I do expect that an implementer would say, oh, I've got to do all these things, and might do them in a single pass and things like that 15:26:43 ... But as far as laying out the algorithm and making sure people understand all of the pieces, that's why it's separated out that way. Um 15:26:44 q? 15:27:03 ack markus_sabadello 15:27:04 ... I would have to look again. I don't think it's the end of the world, quite frankly, if a fragment gets passed. It does say ignore it. So I don't think that's the end of the world, but we can absolutely look at that. And if you have specific wording to suggest. That would be helpful 15:27:07 Otto Mora: Okay... 15:27:16 ... Thank you, Steven. And I'm sharing the… is this the right… just double-checking… I'm sharing the right section here, right? The Prepare for Resolution 15:27:18 Stephen Curran: No... 15:27:21 Otto Mora: No, I'm not. Okay, thank you for that... 15:27:29 Stephen Curran: Sorry, um, it's up in the… it's not in the provisional, um, it's in the actual DID resolution algorithm, 4.4... 15:27:34 Otto Mora: Oh, 4, 4, 4. Okay, thank you. Thank you. Sorry I was trying to follow. Okay, so it's this part of validating... 15:27:34 Stephen Curran: So, validate... 15:27:37 Otto Mora: Mm-hmm... 15:27:40 Stephen Curran: prepare, and then validate. The third step is validate the input did... 15:27:41 Otto Mora: Got it, got it... 15:27:44 Stephen Curran: Um, okay... 15:28:04 ... Part of the reason, by the way, um, is that I realized input did was used a fair amount, and so I decided as, um, as that step 2 to actually create the input did so that the rest of them would have fewer changes and wouldn't be affected. So that's part of the rationale by 15:28:06 q? 15:28:10 ... In… in specifying the input data, and then validating the two separately 15:28:11 ack JoeAndrieu 15:28:11 JoeAndrieu, you wanted to suggest we use the Base DID URL pattern here to name and describe the DID URL without the fragment 15:28:15 Otto Mora: Thank you. All right. I see, Joe. Go ahead... 15:28:18 q+ 15:28:32 Joe Andrieu: Yeah So we had talked about naming this thing that is passed to the resolver. And one of the names that was proposed in one of my PRs was a base did URL, which is a did URL without the fragment. I think... 15:28:48 ... You should take a stab at something like that Steven. I think there was some some debates or question about whether that term was appropriate. The my the takeaway I remember was actually from Pierre Antoine saying that the base did URL is actually a a 15:29:05 ... Um, it's a role that a URL plays. You figure out the base depending on signals that you have in an HTML document. Um, it could be a base tag, it could be the location of the HTML file, and so it is something that is determined rather than something that is a syntax 15:29:06 q? 15:29:15 ... Um, which was part of that debate. Like, we looked at 3986 and we're trying to say, hey, is there syntax that exists that already can describe this thing? Um 15:29:26 ... And so that's just my suggestion, Steven, is that name name this transformation from the one thing to the other. I think passing the fragment is something 15:29:30 ... we have long agreed is not something we should do. Um, so I think we should have that in the spec 15:29:34 Otto Mora: Like this... 15:29:39 ack markus_sabadello 15:29:51 Markus Sabadello: Uh, regarding the invalid DID error, uh, Steven, that's not about DID method-specific validation, that's a validation. Of the input data against the... 15:29:57 ... the generic DIT syntax, the generic A, B, and F, and for that reason, it 15:30:17 ... makes no sense to have that as a separate step. If before, in an earlier step, you already validate the input DTURL against the DTURL ABNF, which includes the DTURL ABNF rule, so that that's not. method-specific, at least, uh 15:30:20 ... That the way it's written right now, so this would be a 15:30:30 ... a change, and, uh, regarding passing the fragment to the resolver, and in my opinion, also 15:30:38 ... passing the path to the resolver is just crazy, I think. This contradicts a lot of 15:30:56 ... things and opinions that we've heard in the past in the group. There's a section in the privacy considerations that I think was triggered by points that Stephen raised originally about tracking 15:31:00 ... Uh, and surveillance by Resolver Services, um 15:31:01 q? 15:31:08 ... On the previous call, there was an opinion that this is not a problem, because supposedly you have to trust the resolver anyway 15:31:27 ... But I think this goes against all kinds of privacy principles to pass information such as a path or a fragment. to a resolver, and that's what this PR says right now. I don't think the 15:31:35 ... ping horizontal review, the privacy group or the attack would agree 15:31:39 q? 15:31:40 ... to that and it would be, I would raise formal objections for sure if we, if we have this in the spec 15:31:52 Otto Mora: Okay, this being separate from the change of the input, this is more just on the handling of the… of the passing of the path and so on, right?... 15:32:00 ... Mm-hmm 15:32:17 Markus Sabadello: Well, it's a consequence of the change of the input, right? If we say we pass a DDRL to a resolver, and looking at this PR, then we're saying we're passing a path and a fragment, and not just... 15:32:22 Otto Mora: Okay, well... 15:32:24 queue+ 15:32:24 Markus Sabadello: parameters to a… to a resolver. That's what, uh… that's what you're… you're doing here. That's what this PR is doing, and, uh, three people are approving. Like, I… I have no idea why. Why that is happening... 15:32:27 Otto Mora: I guess totally noted, and uh... 15:32:32 ... We can see what adjustments are made, but maybe we move on. I see Steven, sorry 15:32:36 ack smccown 15:32:44 Steve McCown: Yeah, just a real question, a quick question on Marcus's concern about passing all the other stuff to the resolver... 15:32:50 ... I… if I'm not mistaken, I heard either Steven or Joe 15:32:53 ... Say that we could trim that down and just pass like a base 15:32:59 ... Base URL, the base part 15:33:03 q+ 15:33:05 q+ 15:33:06 ... Are we pursuing that? That sounds like it would resolve Marcus's privacy concern 15:33:10 Otto Mora: Joe?... 15:33:10 ack JoeAndrieu 15:33:15 Joe Andrieu: Uh, just… just to respond to Steve, um… The the base URL can have a path in it... 15:33:30 ... Uh, conceptually. Like, that happens today. And when you… when you look at the base for an HTML page, it is the folder that that HTML file is in 15:33:34 ... Um, unless it's overridden by a base element in the HTML. Um 15:33:47 ... So it does not address that the path information may contain sensitive data, but so may all the queries 15:33:59 ... all the query parameters could have PII in it, or whatever. Like, so I didn't… I don't think we have a distinction between the query parameters and the path, and the… and the way that Marcus is highlighting as, uh… as a problem 15:34:06 ... But the figured out the base did URL is really just about stripping off the fragment. Um, it doesn't address the path part 15:34:09 Otto Mora: Okay... 15:34:11 Steve McCown: Okay... 15:34:14 Otto Mora: Last word, Marcus, on this. Go ahead... 15:34:14 ack markus_sabadello 15:34:33 Markus Sabadello: Just plus one to what Joel just said, this idea of a base DTURL would address the concern about the fragment, but it's not in this PR, right? does send the fragment to the resolver, if we had that... 15:34:38 ... It would address that part, but it would not address the path 15:34:40 q? 15:34:45 ... problem, which I think is equally problematic 15:34:48 Otto Mora: Okay, so, yeah... 15:34:54 ... I guess we can evaluate there, Stephen. Um, okay, thank you. Um 15:34:58 Topic: Threat Modelling Discussion 15:34:59 ... Let me move on to… Next topic 15:35:18 ... Uh, and I will yield the floor to, uh, Joe to… I guess we can refresh, I guess, on where we were, uh, on the threat modeling discussion, and then, I don't know if there's maybe changes in light of the 15:35:21 Joe Andrieu: I just... 15:35:24 Otto Mora: The algorithm changes as well... 15:35:32 ... Oh, like in the resolution algorithm changes, sorry. But… I don't know if there's direct 15:35:33 Joe Andrieu: Um, no, I'm not gonna speak to that. Um... 15:35:36 Otto Mora: Just from that... 15:35:39 ... Okay 15:35:42 Joe Andrieu: The… so, this… this is a little bit of a hodgepodge. I put together a presentation, um... 15:35:52 ... what I'm going to try to do is give the group, um, an update on where we're at and what's next 15:35:57 ... If we can, it would be great to get the group involved in enumerating threats 15:36:16 ... Um, my experience with Simone, um, trying to do this is we need more time than we have available to really sort of get into that sort of ideation. Um, that's why it's a bit of a hodgepodge, so maybe we can get to that, maybe we can be constructive at enumerating new threats, but 15:36:28 ... at the… at the minimum, I will be opening up a Google Doc and sharing that where people can go and add threats, because that has been one of the ways we've been successful. Um, so let me just walk you through where we're at in this process. Um… Um 15:36:42 ... So, uh, I'm gonna talk about threat modeling real quick, and then the next steps, both for resolution and did core, which, uh, I think is one of the interesting wrinkles we should… we should start being aware of. And then if we have time, we'll get into threat enumeration 15:36:55 ... So we do have a commitment by the working group to get a threat model by the end of Cr. For did core and we are pushing to get did resolution threat model ready so that we can go into Cr 15:37:11 ... And the eventual goal is that all security considerations across the W3C incorporate threat modeling. We're trying to figure that out. It's a mess. We are the guinea pigs. And so with compassion and support, we're trying to 15:37:24 ... figure all this out. Um, and so for the DID resolution spec itself, that's where, um, I started to say, hey, that feels like a subset, and maybe it's simpler, and so let's start working through that. Um 15:37:42 ... And so the steps that we've engaged in are we've created actually a couple of diagrams. I will share those shortly. And we've done a stakeholder analysis of the parties involved in DID resolution. And we have started identifying some threats 15:37:51 ... And then we want to describe good responses to those threats. And the idea here is for the group to distill what shaped the specification 15:38:08 ... like, what were the threats and and responses to those threats that helped us decide. For example, you know this debate we're in about. Did URL. Marcus is bringing up this privacy threat. That's a legitimate threat. And so what is a good response? Well, Marcus's response was to put those 15:38:31 ... to not send the path, and instead put it in an option, right? So that is a good response. And so, hopefully, this threat modeling will let us have a more nuanced conversation about, well, what are the threats, and what are the concrete responses? 15:38:36 ... Um… For the W3C, we have advocated that there are four different kinds of threats that we want working groups to think through 15:38:47 ... The 1st is target threats. So these are threats we knew about in the spec, and the spec was responded to those threats specifically. The second one is implementation threats, which are they're out of scope for the spec. But we know they're real. So in 15:39:07 ... like the verifiable credentials work, or, uh, even with DIDs, we've got key management. And how you deal with key management, it's just, it's not in the spec. But we can identify implementation spec, uh, threats, such that when someone's going to implement, they're aware that, hey, I have to deal with these threats, um, they are non-trivial 15:39:37 ... Um, and so we can highlight that, um, to help implementers. External threats are threats that are out of scope and generally just accepted. Um, for example, um, over-the-shoulder, um, surveillance of people typing PINs into their mobile phone as they're authenticating into a system. Perhaps at an airport or something like that. Unless the spec, 15:39:37 like, is specifically trying to address that 15:39:48 ... Um, that's the kind of thing where you might want to say, yeah, that… that's a risk. We don't… we don't have a spec that solves it, we don't solve it, we're not sure how implementers solve it, but we just want to flag it, because it did come up, and it… and people had legitimate concerns, and we want to anchor 15:40:06 ... for the audience that's reading this, hey, these are real threats, and you may take it into consideration when you deal with your deployment. Um, and then the fourth category is dependency threats, which is where we have an external specification of some kind that we can say, hey, if you're concerned 15:40:22 ... about the security of this link, go read the TLS spec, because we're not redesigning TLS, and that's a whole other security model and security analysis. But we can point to it and say, hey, there are aspects of our protocol or our specification that depend on these external 15:40:31 ... specs, and we can point to those. And so those are the four different kinds of threats that, for us in the W3C, we want to bubble up in our threat models 15:40:47 ... Um, that last one leads us to sort of this notion, this is kind of highfalutin, maybe I could come up with a less fancy word of constellation, but the web is this 15:40:55 ... Ecosystem of really complex interweaving and independent technologies. And so there's, I don't think it's 15:41:14 ... ever going to be reasonable for a single threat model to try to encompass all of that, except in an encyclopedic sort of manner. Like, yes, a collection of all the threat models would be useful, and that's sort of what this constellation is about. Like, if we can start getting good threat models piecewise 15:41:28 ... For different parts of the web as as we upgrade our sensibility about specifications, then we can help establish, hey, there is this shared understanding of how these pieces fit together in a common lingua franca about 15:41:44 ... These are threats, and these are good responses to those threats, and different specs will reuse some of those responses, like signing things is a threat to tampering that is used all over the place, right? So this idea of a constellation is part of how we can break down the work 15:41:59 ... So we can get traction on small bits and move the larger story forward without feeling like we're overwhelmed by having to come up with all the threats for all the things and all the places, because that's just too much work. Um… In our case, um 15:42:22 ... for example, with the Verifiable Credentials Working Group, which is right, not this working group, but they've got… we've got a bunch of task forces over there, and each of those are looking at a threat model for how they are each extending the VCDM directly, and the goal is to have those be coordinated such that the language is common 15:42:40 ... what we call a given process or what we call a given device is common. And even some of the flows, hopefully, we can find common numbers. But that's an exercise in how do we refactor and coordinate all these together. But what we're not trying to do is have the working group come up with one single threat model that has to deal with 15:42:56 ... render method and confidence method and barcodes and data integrity. Um, we want to spread that to the edge so that you can have smaller, um, more readily consumable threat models. Um, and that was why, for us, I started with, uh, did resolution. So, um 15:43:09 ... The next steps for us on the did resolution threat model. And let me share two things. So one is the the spec as it is now is 15:43:22 ... It has some some good introductory pros, in terms of the, introduction, the architecture, a description of what is resolution 15:43:38 ... We have one diagram currently in the document. I want to add two more. You'll see them in the Google Doc because I profiled did key on a single device and did BTCR2 15:43:56 ... Just to show that there are different deployment architectures, and those different deployment architectures, um, will affect your threat model. If everything's on the same device and you don't even have to talk to the network, which is possible with DidKey, um, then that changes things. Um, so we have a diagram. This has gone through a few 15:43:56 iterations, um 15:44:09 ... But hopefully this is stable enough for us to start enumerating some threats. We have a description of the process flow that is anchored to the elements of that diagram 15:44:25 ... And then we have a dictionary of all the elements in that diagram so we can formally refer to them with a label and a name. And you can go here and look it up. If you're confused, what do I mean by resolver process? Well, here's the definitional term. Um 15:44:43 ... And then we do have a stakeholder analysis between the DDRL user People who are maintaining the different bits of code or administering the code. And just really trying to highlight why are they in this game And for most of these players, like the code maintainer 15:44:54 ... They just want their code to work, right? It's a pretty simple stakeholder analysis, but I want it to be… Thorough, uh, it's, you know, I 15:45:01 ... that feels like too much, but I wanted to include all the different parties that are stakeholders in this, so we have that analysis 15:45:08 ... Um, then we get to this threat section, which this is… I apologize, because these 15:45:16 ... These are not real threats. These are examples of the threat engine, um, that we've now abstracted into something called respec threats 15:45:21 ... Um, which is a… just a little rendering engine that, um 15:45:40 ... uh, makes it easy to take, uh, JSONified versions of these threats and render it. So, um, this is an automated, generated table of contents, and these tables are also automatically generated, and part of what that Respec threat is doing is it's making sure 15:45:54 ... That the JavaScript engine correctly pulls in respec to get into the table of contents and to get these links and those sort of nice features that we've come to expect with respec 15:46:03 ... So this is just to show you, like, this is how it will get rendered. Um, and then I'll drop the URL in and share this Google Doc 15:46:09 ... Um, which has a little bit more, um, actual threats in it 15:46:17 https://docs.google.com/document/d/1Jpc7hKFjJCFEOJ7cIJXRQYeuLymPNgvwbR6T9WpQfiE/edit?tab=t.0 15:46:19 ... Let me find a chat in… well, no, it's in the lounge that I want to get to, I guess. Um 15:46:25 Otto Mora: And you're gonna share the presentation as well later, right?... 15:46:28 ... Okay. Or just… yeah, right 15:46:31 Joe Andrieu: Um, I can, yeah, I… uh... 15:46:47 ... Um, so this… this document is essentially the, um, same as what's in the repo, but it's easier for us to edit and ideate in. Um 15:47:00 ... I will mention, you know, I'll point out here's the did key single device profile And then there's the BTCR one. So those diagrams and descriptions are also in this. And I intend to get that over to the repo soon 15:47:06 ... But the threats that start to get interesting were just some of the things that 15:47:09 ... Came out of some of the early conversations 15:47:14 ... One thing I wanna clarify is 15:47:30 ... Ultimately, each of these threats are going to need to have these, you know, eight or so, or nine, whatever the count is at H, different, properties. We need an ID. We need a description. We need it for each response 15:47:49 ... We also need an ID, a name, and a description, and we want to categorize it by type in terms of are we eliminating the threat, are we reducing it, are we transferring it, or accepting it? These are standard sort of threat model notions defined in the threat modeling guide. What category, which is the target, implementation, external, or 15:47:49 dependency? 15:48:04 ... the taxonomy that, uh, let us identify this threat. There are multiple different taxonomies, and you can make up a taxonomy, or you can… you can use a taxonomy that no one's ever heard of, that's fine. The point is that, for example, in Stride and in Linden 15:48:19 ... They both use repudiation with very different meanings. And so, uh, it's important to say, hey, this is, this is a repudiation problem in stride. And so that's sort of what this, these, these two parameters are doing. And then really, uh, one of the 15:48:35 ... the biggest challenges with our current state in some of these threat models is getting to the actual elements in the Dfd. That are impacted by that threat. So we don't want just threats that are sort of abstract and hanging out there. We want to say, for example, in the stride framework 15:48:52 ... If you're talking about something that is being spoofed, well, what is it that's being spoofed? There's going to be a data object in the DFD, and we can say our concerns are with that particular object being spoofed, and we can describe how we can respond to that. So this is a lot of stuff 15:48:56 ... And when we're ideating, it's too much. So that's that's part of the challenge 15:49:12 ... So, really, what would be useful now is, um, in terms of ideation, is just to start identifying by name some threats, and if you… if you can think of responses or components, we can start to fill that in 15:49:23 ... Um, but even… even these threats, I'm gonna walk through some of these with the group, I'm not sure they're good yet. Um, and so part of the process 15:49:40 ... of threat refinement is one to do some dedupe, because we're going to get threats from different people, or even the same person on a different day, that really, at the end, they're the same threat, so we want to deduplicate that. We want to tie it to components in the DFD, because that anchors it to the specific embodiment under consideration 15:50:01 ... And then we do need to come up with, you know, a good response, at least one good response for all the threats. There may be multiple responses. And so that's a refinement process, and I want to separate ideation from refinement, but we're going to have to go through both steps, and this is where the work is in terms of the group getting to 15:50:01 consensus. Um 15:50:16 ... Once we have a set, then we'll bubble up to the group and say, hey, basically, we have a good set here. What are we missing? And then that as its own, as long as the group says, yeah, I think this represents a good set of threats 15:50:36 ... that illustrate what we cared about when we created the spec. Not that it's exhaustive, but that it captures what we want to tag and sing, and others to consider. Then we can publish it, and what sing will do in particular. I won't speak to tag 15:50:52 ... But what Singh will do is they will look at those threats and that data flow diagram. They'll say, Oh, we understand the threats you talked about, and we do or do not understand the responses that you talked about. And oh, hey! What about this other threat? Because we are thinking about it because we're security guys. And then that will come 15:50:52 back as a form of feedback for the working group to say, Oh, yeah, that's a legitimate threat. And we don't have a response 15:50:57 q+ 15:51:08 ... We just accept it, which is a viable response. But the point is, it gives a lingua, it gives a medium for seeing to be concrete about, hey, we see some threats that weren't discussed here. Let's add it. So I think that's the process that we're hoping to get to 15:51:13 q? 15:51:15 ... For the DID resolution threat model. And then the next steps for the DID core 15:51:23 ... Um, it's a little more vague to me, like, because one question is, are the diagrams that we have 15:51:30 ... for bid resolution…the same diagram that we would have for did core 15:51:44