13:54:26 RRSAgent has joined #did 13:54:31 logging to https://www.w3.org/2026/07/15-did-irc 13:54:36 rrsagent, make logs public 13:54:41 Meeting: Decentralized Identifier Working Group 13:54:46 Chair: ottomorac 13:55:18 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jul/0009.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:38 previous meeting: https://www.w3.org/2026/07/08-did-minutes.html 13:55:51 next meeting: https://www.w3.org/2026/07/16-did-minutes.html 13:57:41 transcriber-bot, connect 13:57:54 transcriber-bot has joined #did 13:57:58 transcriber-bot, connect 13:58:00 scribe+ 13:58:08 transcriber-bot, pause 13:58:08 scribe- 14:00:58 JoeAndrieu5 has joined #did 14:02:12 Wip has joined #did 14:02:14 pdl-ASU has joined #did 14:02:16 present+ 14:02:20 present+ 14:02:49 present+ 14:04:33 transcriber-bot, resume 14:04:33 scribe+ 14:04:39 Topic: DID Threat Modelling 14:04:41 Otto Mora: Right, put it back on... 14:04:46 Joe Andrieu: So… All right, the first thing I'm just going to share with folks is the… uh... 14:04:58 ... The current draft of the threat model 14:05:09 ... which is your best reference for the diagram and for the introduction language. If you have any questions about you know what the elements are, those sorts of things, the components. But where we're actually working today is going to be in the Google Doc we've been using to corral 14:05:13 ... The enumerated threats that we have so far. That's in a different spot 14:05:18 ... That is that Google Doc. Um 14:05:29 ... And there were basically two things I want to do today. One is I want to go over the fleshed out threats 14:05:43 ... that Steve and I have documented in here, and get feedback on it. Just like, hey, here's how we're approaching this, here's the… these are, in my view, complete. Um, although maybe we don't have the component, so they're 99% complete 14:05:54 ... Um, and I want to make sure they're landing right, and that people are understanding what we're doing. Then I also… we have one question about, um 14:06:00 ... Where some of these go in the structure. Which I'll get into about, are they external threats or are they 14:06:10 ... Uh, dependency threats, or something else altogether. And then the other big item is that I think, in our conversation, Steve and I have come to the conclusion that 14:06:15 ... There is probably only one threat model right now for our group. Um 14:06:21 ... Uh, and that was basic, because we had talked about, hey, let's… let's use the 14:06:39 ... potentially smaller scoped DID resolution threat model to go through the exercise of threat modeling and understand what it would be. And then there might be a separate DID threat model, right, for DID core 14:06:55 ... Um, and I think there isn't. I think there's no daylight between these two. Um, so I guess let me just introduce that first, and then as we go through this, we can have that in our… in our minds. um… Although we did not have resolution defined concretely in DIDCOR. Dids don't work without resolution 14:07:00 ... So every threat to resolution is a threat to TIDCOR 14:07:16 ... Um, it may be nuanced because did resolution, you know, now has parameters being passed, or has particular bindings that we didn't have before, and those could have their own unique threads. Um 14:07:19 ... But we came up in our conversation the items that Steve was motivated to dive into 14:07:28 ... And they're… they're great threats. Um… Really are did threats and not about resolution 14:07:40 ... Like, to my sense, as a threat modeler, I want to look at the system, and I want to contain my analysis to that system 14:07:45 ... Um 14:07:52 ... With an awareness of where it's embodied, but things… I'll get into this shortly, I guess. Maybe I should have prepared a presentation. It would have been clear 14:08:10 ... But I think we should just have one threat document that has all the threats, whether it's did or did resolution. I think that boundary isn't helping us. I don't think we want to create a separate document. All that feels like more work than is necessary, and I'm not seeing a good reason for it. So… open to feedback right now on that, or we 14:08:11 can… we can dive into, uh, the Google Doc 14:08:14 ... Thumbs up from Stephen 14:08:17 Otto Mora: And I saw that Phil had his hand up for a second, but... 14:08:26 Phillip Long (GU, ASU): Yeah, I was… I wasn't sure immediately until Joe, um, explained a little bit further that the… the difference… the distance he was talking about was between... 14:08:37 swcurran has joined #did 14:08:39 ... uh, threats to DIDs in general, and threats to specifically DID resolution, and he's made that clear now, so I understand that, and I happen to agree that that's the proper way to view it 14:08:40 Joe Andrieu: Cool... 14:08:42 Phillip Long (GU, ASU): Thanks... 14:08:44 present+ 14:08:45 Joe Andrieu: Thanks, Will... 14:08:52 Otto Mora: Perfect. And as we go through this, I mean, I'm sharing my screen here, Joe, but if you prefer to share your screen and walk through it, I'm happy to help you do that as well. I just... 14:09:02 ... Wanted to, like, for folks that may not be on their computer. Well, um 14:09:07 ... It might just be 4 cents, yeah 14:09:09 Joe Andrieu: Sure. I appreciate that. And I'd be happy to share my screen. But since you already have it — oh, there you go. I was about to say, so do you have it up? You can go ahead. But I can grab it, too. It's easy... 14:09:12 Otto Mora: Oh, okay... 14:09:20 Joe Andrieu: Okay, so this document is a work in progress. Did you have Sanado? Do you want to add?... 14:09:24 Otto Mora: No, no, I'll keep an eye on the queue. That's what I can... 14:09:28 Joe Andrieu: Okay, I appreciate that. This is a work in progress... 14:09:37 DID Resolution Threat Model doc: https://docs.google.com/document/d/1Jpc7hKFjJCFEOJ7cIJXRQYeuLymPNgvwbR6T9WpQfiE/edit?tab=t.0#heading=h.wh5l3vvegjti 14:10:08 ... And we're going to go over the yellow highlighted things today. This is not all of the threats that have been enumerated by the group. We have quite a bit more. They are in here in the sections in which we think they belong, but they aren't quite well fleshed out 14:10:16 ... Like, we have interference by central authority. I'm not sure that that's a well-formed threat, but it needs a description. It needs a bit more details, as do all of these that aren't highlighted in yellow 14:10:28 ... This is the short list which really helps you get some sense of scope like, what kinds of things have we covered? What kinds of things have we not? Those should all be realizable by here. The main thing that happened is after. The, um 14:10:39 ... Uh, our last call, where we talked about the at-risk for the resolution architecture section, um, I don't know who put it in my ear, it may have been on the call, someone said, hey, that, you know, if that's a threat you're concerned about, it should be in the threat model. And so that triggered me generating several of these threats that we're 14:10:39 going to go over 14:10:45 ... And a couple that I haven't. They're all so they're all proxy related. And what I don't write have right now is is tampering with the URL. uh 14:10:50 ... Which isn't really about proxy, but it is about 14:10:54 ... Um 14:11:04 ... the, uh, confused deputy risk. So that's not in here, and I know it needs to be. Um, but let's dive into this first one, and I'm gonna make this bigger 14:11:16 ... So this thread is eavesdropping by did resolution service provider. And it could be surveillance or eavesdropping, I think I only want one of those 14:11:37 ... Unless people holler, I'm just going to get rid of and surveillance. I think eavesdropping feels more unique. So, did resolution service providers receive a significant amount of data that may reveal personal or proprietary information? I want to include both personal risk and corporate risk with that statement 14:11:44 ... Um, this is a, uh… In STRIDE, this would be called the Information Disclosure Risk 14:12:00 ... And we came up with four responses. One is we can let the user know. So this is convey threat likelihood. When onboarding users to any particular data resolution service provider, explicitly communicate the data use policy in terms that users can understand. So in many jurisdictions, this is lawfully required 14:12:14 ... But this is one response to the fact that the surveillance provider is getting your stuff, is that they can tell you what they're gonna do with it, and they could commit to it in terms of service or not, but there is this point in the relationship where they tell you exactly what they're gonna be doing 14:12:26 ... Um, the next step of this is the purpose binding, so they've told you what they're gonna do with it, and they actually do only what they say they're gonna do, right? So this is restrict the use of data provided to the DID resolution service providers to explicit purpose 14:12:31 ... As agreed to by the user. So this is a level up from R1 14:12:44 ... Um, R3 is to recommend local resolution. So, when explaining DID resolution, and we think this is mostly, like, our job, like the community job, um, educate users about the trade-offs of running a local resolver versus using a service provider 14:12:50 ... And that is, in fact, part of what this threat model is doing. So this is one of the responses we have to this risk 14:12:56 ... Um, and the third one, or the fourth one, R4, is use a locally controlled resolver, rather than using a service provider 14:13:03 ... And so I think that's actually going to be repeated. So I'm going to note that 14:13:19 ... R4 is probably what I should be using later, but, um, so there's no eavesdropping by a service provider if you're the service provider, so that's another way you can, you can deal with this. Um, this addresses these components, um 14:13:23 ... I don't have the diagram up. Maybe if I get the diagram handy 14:13:26 ... One second 14:13:43 ... I'm surprised our diagram is so… oh, I'm not… that's right, I'm in the wrong URL. Um… Let me get there. Hold on one second 14:13:52 Phillip Long (GU, ASU): It's the diagram at the top of the document, isn't it?... 14:13:57 ... No 14:14:00 Joe Andrieu: Correct. I just wanted to put it on screen easily without losing the place... 14:14:05 Phillip Long (GU, ASU): I understood. I just wanted… because I was mapping to the letter combos... 14:14:05 markus_sabadello has joined #did 14:14:06 Joe Andrieu: Okay. And do they look good? E seven f one c one... 14:14:08 Phillip Long (GU, ASU): Yep... 14:14:10 present+ 14:14:11 Joe Andrieu: Okay... 14:14:12 Phillip Long (GU, ASU): Yeah, they're understandable... 14:14:15 Joe Andrieu: Sometimes those shift... 14:14:21 ... Uh, and I keep going to the wrong 14:14:24 Phillip Long (GU, ASU): What I don't see are the F… oh, I don't see the Fs... 14:14:25 Joe Andrieu: thing. Okay, I'm… I'll just skip that... 14:14:36 Phillip Long (GU, ASU): in the upper document. Maybe that's… looking in the wrong place. And I don't see… well, maybe… It's the lower one... 14:14:41 ... No, I don't see the F, the F series 14:14:48 ... in either of the three graphics 14:14:51 Joe Andrieu: Should be... 14:14:56 ... Oh, that was the other link 14:15:03 Otto Mora: Yeah, it's mentioned in the architecture dictionary, but yeah, I don't see them. Yeah... 14:15:06 Phillip Long (GU, ASU): It's not in the graphics... 14:15:10 Otto Mora: Well, actually, in page... 14:15:18 Phillip Long (GU, ASU): Page 7. Hang on... 14:15:20 ... So 14:15:24 Otto Mora: 7, there is F0. and F1, F2... 14:15:31 ... H7, yeah. and the top graphic page 7. Yeah 14:15:36 Phillip Long (GU, ASU): I don't see it there... 14:15:45 Joe Andrieu: Oh, I am… I gave you the wrong URL, and I've been going to the wrong URL. Um... 14:15:47 ... No wonder 14:15:51 Phillip Long (GU, ASU): In the doc that I'm looking at, Date Resolution Threat Model. That was shared in the Zoom chat... 14:15:54 ... There is no F in 14:15:58 Otto Mora: But it… If... 14:16:03 Phillip Long (GU, ASU): that diagram, and it… and it would be helpful if you put diagram, uh, numbers. By the way, in the dark... 14:16:05 ... F1, diagram 1, diagram 2, diagram 3 14:16:05 Otto Mora: Okay... 14:16:08 Joe Andrieu: So... 14:16:12 ... At the very top of this file that I'm in 14:16:27 Otto Mora: By the way, just one… one thing, just, Joe, like, you're… you're mainly just sharing the Google Doc. I think you… you did that thing where you just share one tab or something like that? Okay. Okay, okay, okay, I just make sure. Right. Right... 14:16:29 Joe Andrieu: Yeah, no, no, no. I'm sharing the screen, but it only has a Google Doc open. This is the diagram I was talking about and looking for. So... 14:16:32 Phillip Long (GU, ASU): Where is F?... 14:16:36 Joe Andrieu: I've just pulled it up in a duplicate. F is... 14:16:38 Phillip Long (GU, ASU): Oh, the flows! Okay... 14:16:42 Joe Andrieu: the flows. F0 used at URL, F1 resolved. F3... 14:16:45 Phillip Long (GU, ASU): I see. I was looking for the boxes. Okay... 14:16:51 Joe Andrieu: Um, so... 14:16:51 Phillip Long (GU, ASU): My mistake... 14:16:54 Otto Mora: And in there, too, you can see it in the light blue box inside. It says F1 Resolve F2... 14:16:59 Joe Andrieu: Yeah, for the other profiles, it moves around... 14:17:06 ... Come on. Bye 14:17:09 Otto Mora: Yeah, you could do like a side by side. Yes, that's fine... 14:17:13 Joe Andrieu: Okay. Um... 14:17:16 Otto Mora: Yeah, okay... 14:17:21 Joe Andrieu: So that was E7… The entity is probably the service provider... 14:17:28 ... Alright, there we 14:17:32 ... the resolver service provider, F1, which is the resolve flow, C1, which is the DID user client device 14:17:36 ... I'm not sure the client device is implicated here 14:17:45 ... It's really C2. Resolver device. So, I'll adjust that 14:17:50 ... By the way, we're not going to do this on all these, but I just want to demonstrate this is what should be. Um 14:18:01 ... And the components tend to be the last thing you think about 14:18:20 ... And p two is right and d seven is right. Okay So those are now up to date. And this is an implementation thread. Potentially. So let me talk about that. So we have these four different kinds of threats 14:18:27 ... Target threats, implementation threats, external threats, dependency threats. I added this temporary category which if we're all in agreement on tomorrow's call 14:18:39 ... Um, then, you know we'll get rid of this and just integrate things. Um target threats are a threat to specific behavior feature API protocol or capability that the specification is designed to address. So, um 14:18:44 ... uh 14:18:58 ... Things like the resolution algorithm, if there are threats from the resolution algorithm. Then hopefully we've done something to deal with those threats. Like one of the threats we did deal with was HTTPS binding. It deals with tamper evidence 14:19:04 ... Uh, communication and trusted communication between, uh, the client and the resolver. So that would be a target threat 14:19:13 ... Um an implementation threat is an implementation I'm sorry is a threat that arises from how it may be implemented 14:19:19 ... But, even if the specification text is a hundred percent correct. For example, we don't talk about how you sign anything 14:19:29 ... Um… Uh… but if you are going to do some signing, then you need to have a key store somewhere. And so that's on you 14:19:45 ... Um, we don't… our specification doesn't read on it, we did not solve that problem, we did not really engage with that problem, but we want to identify it so that implementers understand what's happening. Um… And then there are two others, external threats 14:19:56 ... I didn't get the phrase copied in. External threat is a threat that is external and exogenous to the system. And this is just a heads up 14:20:08 ... Uh, because some people do… are concerned about this threat. Um, and we don't necessarily deal with it, and we don't know that implementers are gonna deal with it, or it's not expected that implementers are gonna deal with it. One of my, uh 14:20:14 ... favorite examples of this is the eavesdropping problem at the pharmacy when you're talking to a pharmacist 14:20:26 ... Um, it's a personal pet peeve of mine that, uh, a bunch of my personal medical data gets spoken out loud in front of strangers. Um, it's really not that big of a harm, but it's annoying, like, come on, guys 14:20:42 ... Uh, but that's an external threat. Someone's looking over your shoulder, our system doesn't have a way to deal with it. Like, throughout the architecture, we don't have good ways of dealing with that. But if you're concerned about it, we identified it. It is a threat, you might. And then the fourth one are what we call dependency threats 14:20:52 ... Which also I didn't copy the description of that. A dependency threat is that we're dependent on some other technology 14:21:02 ... And… and there are risks associated with that technology, and we might hint at them, or we might state some scary things, some names. And in our case, um 14:21:14 ... TLS is a dependency threat, or tampering on the channel that is addressed by TLS is a dependency threat, so that's very weird 14:21:20 ... Sorry, made me existentially question what I was just saying 14:21:27 ... There's a threat of eavesdropping on the channel of F1 when we do Resolve 14:21:35 ... We address that threat by transferring it to TLS. And so if you're concerned about TLS, you should go look at that 14:21:41 ... Um, and so threats that TLS creates are dependency threats. As an example 14:21:46 ... Um, so I… I actually… all these proxy things that I created 14:21:51 ... I'm not sure if their implementation… Um 14:21:55 ... Threats, or external threats 14:22:04 ... Um… So that's that's a weird question. We're we're gonna have to noodle through 14:22:09 ... But let me stop there. And this was initially submitted by Steve 14:22:23 ... Um, so this is a threat. It will be formatted and put in a prettier, uh, disposition in the repo, in fact, using, um, this JSON architecture and this rendering tool that we're using 14:22:25 q? 14:22:27 ... But I'm open for feedback. I see Phil, you've got a raised hand? 14:22:43 Phillip Long (GU, ASU): Yeah, I just wanted to know, are you suggesting that where there are threats that are not addressed by the… by the… the Reddit resolution spec, and you've mentioned several of them so far that aren't specifically because... 14:23:02 ... They're either completely external to it, or, as you just described, the TLS threat. Is there going to be a section that is dedicated to those things, just to bring it out, rather than… Inserting them wherever they happen to appear 14:23:06 Joe Andrieu: Yes, that is in fact what the external threats section is... 14:23:09 Phillip Long (GU, ASU): Okay, that's what that is. Okay, that's what I need to clarify. Thanks... 14:23:14 Joe Andrieu: And so, one of the reasons I currently have, um, these proxy… Things... 14:23:22 ... Um, and actually, I think… I think, Steve, we duplicated this one. I think this is the same one. Um 14:23:29 ... So that'll be interesting to dedupe. Um 14:23:40 ... Is that our spec does not define proxies. Normatively. We don't have a mechanism to secure that. Um… So, I don't think the spec deals with proxies 14:23:49 ... We could call it an implementation threat if our belief is that implementers might use proxies 14:23:53 ... That would be a good reason to move it up to implementation threats. Um 14:23:57 ... But you don't have to use proxies. So… Uh 14:24:03 ... I'm not sure which one it would go in 14:24:06 ... I think right now 14:24:07 Phillip Long (GU, ASU): Where else would they… they appear? Where else would you use a proxy?... 14:24:10 Joe Andrieu: Either… right now, I think implementation or external... 14:24:24 ... Like either we're saying it's external to our spec or it's an implementer's choice and therefore it's on the implementer whether or not they're proxying. Which feels a little bit more correct to me right now. Just curious how folks… Thank you. Go ahead, Steve 14:24:27 Steve McCown: Yeah, so there... 14:24:36 ... Part part of the part of the concern, especially with these internal external threats. Is we don't always know 14:24:49 ... as… as users or builders, um, developers of the system, where… where the threats actually originate. So if we go to a cloud service. for resolution 14:24:59 ... It's not always going to be clear to us that they virtualized that and farmed that out to another resolver. Um 14:25:16 ... and then we're just getting. We're just getting back the result, and we tend to trust that the result is is correct because we trust the 1st resolver. But if they virtualize that process and sent that out 14:25:36 ... we don't know anything about the other resolvers, so it's not just a matter of our choosing a good resolver that we trust, it's being concerned about their internal operation. And all along that path. Regardless of how many times that might be relayed. Um 14:25:53 ... There's opportunities for surveillance along the way. I've heard some resolver projects talk about collecting analytics for resolution requests and so forth 14:25:57 ... And and that being a good thing from 14:26:00 ... The way they talk about it, they talk about it being a good thing. I'm saying it's a bad thing 14:26:07 ... Um 14:26:12 ... that um 14:26:25 ... you know, like Google Analytics, that's the way the web's monetized, and so they're looking at it as from that light. But then from the user perspective, or the developer perspective, that's where these surveillance tampons. I can't speak. Tempering and repudiation threats start to emerge 14:26:34 Joe Andrieu: Awesome... 14:26:43 Steve McCown: And the reason they're in here, even though some of the threats might say they're external threats, is because they still need to be handled here. They still need to be addressed. I mean, we didn't go all the way down... 14:27:03 ... to say, you know, if your operating system's insecure, please patch it. I mean, that kind of goes without saying, but some of these borderline cases, even though the threat originates externally, there's something that we can do about it 14:27:17 ... Locally. Anyway, this is my thoughts 14:27:22 Joe Andrieu: Yeah Thank you Steve That helped me really see these proxy threats as implementation threats. Um, precisely because the end user may not know. Um, and so, when they choose a proxy. Um, I mean, when they choose a resolver... 14:27:37 ... These are matters of how did that resolver implement their resolution process like, are they doing proxying or not? So that to me, I think, moves it away from external into implementation. But an example potentially of a good external threat 14:27:42 ... Uh, which I'm not numbering or highlighting because it's not fleshed out, would be using this on a shared computer 14:27:48 ... Right, so if you're trying to use DIDS on a public library, um, or on someone else's phone 14:28:01 q+ 14:28:11 ... uh, you know, a different… whole different, uh, set of problems arise. Um, and in much of the world, we do have shared compute devices as normal, so it is an interesting and challenging threat, and I don't think we do much about it. Like, I don't think our spec 14:28:15 ... I don't think we as a community have spent a lot of time trying to solve that problem or contextualize how we might solve that problem together. So I think that's an example of an external threat. Okay Any other thoughts or I'll continue on? 14:28:23 Otto Mora: Marcus, Marcus was on the queue. Sorry... 14:28:27 ack markus_sabadello 14:28:31 Joe Andrieu: Okay, so the… I realized, uh, although these… Oh, sorry. Go ahead, Marcus... 14:28:35 Markus Sabadello: Yeah, I just want to say something about the proxying. I think I share all the concerns and all the comments about... 14:28:43 ... Proxying, or relaying, or surveilling, or tracking the resolution 14:28:53 ... behavior. I just want to explain that in the current specification there's a subsection about proxy resolution 14:28:57 ... and 14:29:08 ... it's important to understand that at least the way the specification is written right now, we sometimes have local resolvers and remote resolvers, or local bindings and remote bindings. And if I 14:29:29 ... invoke a local resolver, for example, an SDK or a command line interface that would, in the current specification, that would be considered a resolver over a local binding, and then that resolver calls a remote resolver over a remote binding 14:29:39 ... then essentially I have a local component, which calls a remote component, which then performs resolution. And in the current specification, that is also considered proxied resolution, even though 14:30:02 ... there's just one remote service, right? I call one remote service, and that remote service does not call another remote service, but it's still, at least the way the specification is written right now, that is also considered proxied resolution, because I call a local resolver, and that calls a remote resolver, so there. There are two, two 14:30:02 resolvers. Just wanted to mention that 14:30:12 Joe Andrieu: Yeah I appreciate that That is in fact why those sections are marked at risk. I don't think we as a community have come up with any consensus standards about how you deal with that... 14:30:31 ... There is text in there. Personally, I think it violates our security model, but that's not what we're going to dive in today. That's a longer conversation we're going to be having about those sections. What I want to do is capture the wisdom of those sections without making it look normatively like this is how you should do it 14:30:31 q+ 14:30:35 ... In fact, I want people to be encouraged to not violate our primary security dynamic by proxying 14:30:39 ... So let's let's talk about these proxy threats 14:30:53 ... Um, uh, I… we have a deeper argument there, Marcus, to have in a civil manner. Uh, I just don't want to do it right now. So, I appreciate that input 14:30:57 ... Okay, let's… I'm sorry, did you respond, Marcus? I didn't want to cut you off 14:31:00 Markus Sabadello: Yes, yes, I'm just trying to explain... 14:31:04 ... That, uh 14:31:04 ack markus_sabadello 14:31:08 ... I don't know, are we against remote resolvers altogether, right? Because 14:31:12 ... The the current specification does not 14:31:28 ... talk about remote resolver calling another remote resolver. I think some of the concerns and some of the arguments and some of the threats have to do with a client calling a remote resolver which then calls another 14:31:39 ... remote resolver but that's different from a local resolver calling one remote service. And. I'm not sure if 14:31:48 ... If we correctly distinguish between that in the 14:31:54 ... in the conversations 14:32:05 ... And so if you're saying you want to mark proxy resolution at risk or we maybe want to drop proxy resolution or we don't want to support proxy resolution, then I'm just saying the way how the specification is written right now 14:32:12 ... that would eliminate all of… all remote resolvers. It would only then allow pure local 14:32:20 ... resolution, and I don't think that's any… what anybody wants. I'm just explaining this. I'm actually agreeing with, I think, with you on what we want and what we don't want 14:32:36 Joe Andrieu: Well, I disagree with what you just said because we can get rid of proxied resolvers without the problem you introduced, but I really don't want to have this conversation right now, but I see Steve raised his hand... 14:32:39 Steve McCown: Yeah, so what we're doing, firstly, remote resolvers have been super useful... 14:32:49 ... And the work you've done for the universal resolver is super useful. What we're identifying here is not that remote resolution is bad 14:33:07 ... just that there are some risks associated with it that need to be mitigated. Um, so if we… if we figure out, um, good ways to mitigate those… those risks, then what this document does is say 14:33:25 ... is, um, tell future developers, hey, if you're building a system and you're using remote resolution, there are some risks that you'll want to encompass. So, um, that doesn't mean that remote resolution's bad, just that if we… we need to mitigate those risks. the notion of of 14:33:31 ... Relayed proxy, like, like, um 14:33:37 ... uh, resolution site that forms out to another resolution site by virtualization. That creates a different set of risks 14:33:57 ... And our job is to not say that any of those is inherently bad, just that we need to mitigate those risks, and we don't want to lose sight of them. as future developers create new solutions 14:34:01 Markus Sabadello: Yeah, yeah, I totally agree with that. And and we we should have a definition of what we mean by proxy resolution. So we mean the same thing. Oh, thanks... 14:34:04 Joe Andrieu: Cool... 14:34:15 ... Um… So, uh… Moving on to the next one. One of the things I said just a few minutes ago was, oh, it looks like these are duplicates 14:34:23 ... Because I was forgetting that number one is about the fundamental that the resolution service provider, regardless of whether they're proxying or not 14:34:41 ... They could watch your your data flow, and they could get information from that. These next 4 are all about proxies, and we do, in fact, define what that means in a lightweight manner. But that's what's different. This is directly talking to a resolution provider 14:34:52 ... And surveillance by proxy means that you've got a proxying resolver who passes an incoming resolution request to another resolver before passing the result back 14:35:10 ... enables the initial resolver to observe all traffic to all proxy resolvers So they'll they'll get to see all the did methods that you are resolving even if they don't have the ability to resolve it directly. And the responses we have for this are there's direct resolution. Uh, local resolution… Um, which we've already talked about 14:35:31 ... Well maybe we haven't talked about direct resolution So in this in the context of proxying, if my if the server I'm talking to for example doesn't know BTCR two it doesn't want to talk to Bitcoin, but it knows that hey there's another BTCR two resolver that will proxy to 14:35:41 ... And then we'll go get the result and bring it back. In that case, my opinion based on our security model is that the original caller should directly call that BTCR2 resolver It should be their trust choice 14:35:56 ... So, and that's what direct resolution means. So there is some… there is some resolver out there that's capable of doing it, so let's just call them directly. Um, that's this response R4. Local resolution we've already talked about, um, and I made a note that this is likely a repeat. Um 14:36:03 ... Um, you can put in your terms of service that there is no proxying 14:36:06 ... That's one potential answer 14:36:14 ... Uh, terms of service, no tampering. That is not part of this one 14:36:19 ... So let me mark this. A different color 14:36:39 ... The threat here is just surveillance, right? So it's not tampering. We have another threat to address that. Another response is duty of care. Duty of care and duty of loyalty were inspired in part by what's going on in Utah because there is an opportunity to change the law 14:36:56 ... And you might change that through a lawsuit that establishes case precedent, or it might be by statute, which is the path Utah is navigating through, which is pretty amazing. So duty of care is about how they treat sensitive data 14:37:12 ... So, hey, you know all these dids I'm resolving. That creates a burden on you to take care of that information appropriately. We do this in other domains, but it's one of those things that follows society. It doesn't drive society. So eventually we will have some sense of what's the appropriate duty of care 14:37:20 ... Right now, none of that really is is out there. Like 14:37:32 ... Service providers use our data willy-nilly in all sorts of ways. And so duty of care is currently under-defined, under-socialized, and under-enforced. Duty of loyalty is similar but different in that this is when you have an agent acting on your behalf 14:37:39 ... You could argue that the service provider is in a certain way. And then it pertains to how they use that sensitive data 14:37:56 ... So this is what they do to take care of the data, i.e. not letting it be redistributed to other folks. This is what they do with it themselves. And an example of duty of care is a fiduciary, like a doctor. They have a duty of care with your medical data 14:38:07 ... They're not allowed to use that in their own interest and put that ahead of your interest. That is in some context called duty of loyalty. Um 14:38:08 q? 14:38:14 ... And I point out that this response likely entails both contractual elements and other legislative or court based engagement 14:38:29 ... Because that… if… if you want these responses to exist, you're not gonna solve it in a technical problem. You gotta get out into society and pass some laws, or convince some judges, or something like that. And then, uh… the last response is trust 14:38:38 ... Our security model depends on trusting the resolver to honestly return the result from each did resolution process. And so if we trust them 14:38:42 ... Why don't we trust them? 14:38:57 ... If they choose to proxy, why don't we trust that? That is an option. Obviously, based on my comments here, it's not my preferred option, but there's a little bit in this decentralized world of what I call Martha stewarding all the way down 14:39:06 ... Right? Making your own resolver, making your own DID method, making your own wallet, um, so that you can trust it. Um, and I respect all that. Um, I love my clients who'd like to do that. Um 14:39:14 ... But most people can't do it, frankly. Uh, they're gonna use Coinbase, right? And they're gonna say, hey, I know not my keys, not my coins, whatever, I'm gonna trust them 14:39:20 ... Um, so that is a valid response 14:39:31 ... So this is the first pass through of the set of proxies. And when we move on to the next one, which is tampering by proxy. Um, and that is where 14:39:35 ... Uh, the terms of service, no tampering goes 14:39:39 ... So I'll just inject that down there 14:39:43 ... Obviously, we did some refactoring incompletely 14:40:05 ... I'll clean that up later. But tampering by proxy is now that you're going through a proxy. Your results could be tampered with on the way back. So in this theoretical example where we're connecting to a resolver that doesn't want to deal with Bitcoin 14:40:15 ... It could get the result back from a legitimate BTCR2 resolver and modify, either the metadata or the DID document itself 14:40:31 ... And so there are a bunch of responses that are the same. All these proxying things have the option to go directly, do it locally, or use terms of service to address it. I was wrong with the tempering in the one before because that threat was about surveillance 14:40:50 ... This threat is about tampering. And so you could have in the terms of service, they could legally agree and bind themselves and hold themselves accountable in the court of law that they are not going to tamper that evidence. That is a response. It's a transfer of responsibility to the legal system 14:40:56 ... We're not coming up with a cryptographic or technical solution, but we're letting the rule of law deal with it 14:41:07 q? 14:41:11 ... Um, and then another response that's innovative here, right? So we sell duty of care and loyalty. These are repeat. Um, and you could, again, just trust them. So these are common to all of these proxy months. You'll see that we just have a few new things, and the other ones we're going to look at in this section 14:41:17 ... Um, another one is signed resolution results. And I think in the… in this section, uh 14:41:25 ... Uh, that I'm not a big fan of, Marcus. We talked about this, I think you talked about this as verified resolution? 14:41:35 ... Um, so I tried to copy that notion, that that is one way you could address this risk 14:41:40 ... Is that if the calling party knows the public identifiers of the proxies, proxied resolvers, they could independently check and say, oh, okay 14:42:00 ... My resolver, which is doing proxying, is giving me results that I know are actually from those other providers. Now, maybe for operational reasons, I didn't want to go to direct resolution. I wanted to have this service bureau that has, you know, better uptime, better reliability, better whatever. I do want to go with the proxying guys 14:42:11 ... But they're in an architecture where the resolvers they are calling are signing the resolution on the way back. Um… So that's signed resolution results 14:42:16 q+ 14:42:23 ... We just haven't standardized what that would mean is really my main complaint with that other section. But this is tampering by proxy. And with that, let me pause and see if there's anyone who wants to chime in 14:42:29 ack markus_sabadello 14:42:30 Otto Mora: Marcus?... 14:42:39 Markus Sabadello: Yes, signed resolution results. We have talked about this, and there is a bit of content in the specification... 14:42:50 ... There's also, I think, one other response, I'm not sure if you have that, which would be to include 14:43:08 ... the document metadata and the resolution metadata from the upstream resolver. Right? So that proxying resolver could or should include all the metadata from the the other resolver that it's calling and return that to the client, and that could make it possible for the client to independently verify that the 14:43:13 ... results are correct. This doesn't work for all bid methods, and it doesn't work for all the 14:43:18 ... situations or all the threats, but it could be a partial response to 14:43:28 ... to this thread. In the current specification, we, at some point, we added 14:43:37 ... properties to the… to both the deed resolution metadata and the deed document metadata. We… we added this property called proof, uh, right? So we said that in the deed document metadata 14:43:46 ... There could be proofs about the from the deep methods or proof that the result is correct and the resolution metadata that would be proofs about 14:43:52 ... the resolver, the resolution process, for example, designed. signed results that you 14:43:58 q+ 14:44:01 ... that you mentioned. So there is a bit of that in the specification, but maybe not detailed enough based on your analysis 14:44:07 Joe Andrieu: Cool. Thanks, Marcus. Um... 14:44:07 ack Wip 14:44:11 ... Okay. Go ahead, Will 14:44:12 Otto Mora: Will also... 14:44:15 Will Abramson: Yeah, I just wanted to comment on this a little bit, um, because... 14:44:26 ... I think, in my view, maybe it's almost like there's too much detail on this proof in the specification. I mean, I think it is a good threat response to have, but really 14:44:43 ... I think we're just… we're just pointing at it and saying, look, this is one way you could do it. We have no examples, and we are not going to tell you how to do it, right? Like, we're just saying… I mean, in some ways, the proof property that we're defining in the metadata 14:44:57 ... I kind of have questions whether it should be defined in this spec or not. I mean, it kind of feels like we're having a placeholder, right? We're trying to hold that name, that property name, in those objects, and saying to people, if you're going to use something that's like this, you should put it in here 14:45:08 ... I think. But we don't have — we haven't described in our spec because we don't have any examples of how to actually use those properties in practice 14:45:08 q? 14:45:17 Joe Andrieu: Cool. Thanks, Will. Okay, I just want to draw folks attention to the link Steve dropped in the chat about duty of loyalty... 14:45:26 ... Um, and what Utah's doing is a nice paper about their approach and how they're framing it 14:45:44 ... Okay, and with that, we'll move on to DOS. So proxying resolvers who pass incoming results can arbitrarily choose to deny proxy service to some or all secondary resolvers 14:45:48 ... Um, and it could be for good business reasons, i.e. the secondary resolver charges too much 14:45:52 ... Um or it could be malicious reasons They're just trying to disrupt, um those clients that have become dependent on that proxied results 14:46:02 ... So we see a lot of the other proxy responses repeated. But you could also have assurance in the terms of service 14:46:16 ... And the nature of this assurance could take many forms, but one form of it would be a guarantee to resolve all requests for specific data methods, regardless of back-end service providers. Um, uh 14:46:38 ... That seems like maybe a really risky way to present it and maybe a service provider wouldn't quite put it that way. So I'm open to improvements. But the idea is, look, I'm not going to let you down. I'm imagining I'm the service provider who's providing this universal resolver. Um, not 14:46:53 ... I wish I'd use a different term. I don't mean it has to be, uh, the universal resolver Marcus has worked on, but a resolver that's proxying to these other parties, and they'll say, hey, look, come hire high water. We've got, we've got so many, um, uh, did key compatible resolvers. We can, we can resolve did key for you no matter what 14:47:04 ... Um, you know, that's kind of silly with Dead Key, but I think you see what I mean. You can… you can put it in the Terms of Service that they will not deny you service. And that's a way to transfer this risk to the legal system 14:47:12 q? 14:47:13 ... And that's the only new threat that DOS denial of service by proxy gives us. Any thoughts before we go on? 14:47:19 Otto Mora: No one in the queue... 14:47:27 Joe Andrieu: Okay, the next one is repudiation by proxying resolver. Um... 14:47:37 ... Which is, uh, the proxying resolver may deny that they were responsible for any particular result, asserting that the errant result was the output of a secondary resolver 14:47:52 ... So you get back a did document that was fraudulent, and somehow you were able to determine that through other factual means. The proxying guys can say, oh, I wasn't the one who resolved that. I wasn't responsible for that result 14:47:55 ... That was, uh, that BTCR2 resolver. They messed it up. I just passed on the normal thing 14:48:01 ... So having the proxy in the loop creates this sort of question of repudiation of who's on the hook 14:48:05 ... For doing the different things, and uh 14:48:09 ... The responses there are mostly the same. Um 14:48:33 ... In fact, I don't think there's a new one in here because we have signed resolution results, which we talked about before. If they have a signed document, then that's a correct repudiation. No, that wasn't me. Look, I have signed evidence that says that this other person provided. And of course, you could have terms of service that address it 14:48:33 with no proxying. Ah 14:48:45 ... That it is there. We had an agreement that you were not proxying, so you don't get to say that you went to a proxier. Like, a court of law would hold that accountable if they agreed to not proxy 14:48:49 ... So these are the possible responses to this 14:48:59 ... Uh, fourth proxy. Threat. Any thoughts about that? 14:49:04 ... And I'm noticing in here, and I must have… I must have stopped copying it 14:49:08 ... Uh, because I was sad we weren't filling it in. We don't have the components in here 14:49:13 ... But it's going to be the same components, fortunately, for all these proxy ones 14:49:23 ... Okay, let's get into Steve's contributions 14:49:26 ... Uh, which I think were really great. So the first one here is correlation by overuse 14:49:31 ... Um, also called a super cookie. Some of you may have heard this. This has been a term of art, um 14:49:49 ... Uh, from the beginning, uh, I think, I think it was Daniel Hardman who used it most with me. Um, so I'll give him a tip of the hat to this, which is the idea that if you use a single DID for interacting with multiple parties 14:50:06 ... Like your own you got one did I mean it doesn't have to be just one but if you're using a single did for multiple parties, then those parties are able to use that did to correlate your activity They could talk to each other and say hey, the guy with did x y z came over here It's like oh I know the guy with did x y z. He did this other thing And 14:50:06 now they can start correlating user activity 14:50:25 ... And it's especially true when user activity is correlated like what's done with web analytics right now, where you pass on your log to a third party in the cloud, and they are doing this sort of correlation metrics to give back some interesting summation 14:50:41 q+ 14:50:43 ... IE analytics over that data. And so now that third party is potentially seeing all the DIDs from all these people that they are providing. And that person is in a catbird seat with regard to seeing how the DID shows up on dozens or hundreds or even thousands of websites. Um 14:50:48 ... And the only response we have right now for this is convey the threat likelihood. Um, which 14:50:54 ... Uh, maybe as a repeat, I'm gonna put a question 14:51:00 ... Because the description may change but 14:51:08 ... So when people created did explicitly communicate the data use policies that's similar and repeating 14:51:33 ... Enable users to create multiple DIDs and recommend using peer DIDs for each connection the user establishes. So that is unique to this particular, this idea of peer DIDs, or what I prefer the term, contextually unique DIDs for each connection. Um 14:51:42 ... But that's really all we can do. Like, users can use the same data everywhere. I don't know that we have any other ways except trying to get users to not do that. Um, so if there are other responses, we'd love to hear them 14:51:42 ack ottomorac 14:51:45 ... And we need to identify the components here 14:51:49 ... Hey, Mike 14:51:52 Otto Mora: Yeah, I wanted… I put myself in the queue for this one, because, um, I… I personally… at least we did identity. We did, um... 14:52:02 ... kind of experienced this as… it was something that the DID method itself kind of optimized for, like, your wallet kind of 14:52:08 ... on purpose established, uh, different DID identifiers for each connection that you make to, you know, relying parties and so on 14:52:12 smccown has joined #did 14:52:26 ... Um, so I think this is, this is a great response to the enable, you know, different dids as you interact with different, uh, parties. But what I was wondering is, is, is that a different, I mean, like one, one response seems to be, yeah, like convey that this is a threat 14:52:37 ... But isn't is another response like an R. 2 for that. What Steve is suggesting there to create multiple dids like, you know, kind of your your peer dids that he's mentioning there. Right? 14:52:42 Joe Andrieu: Oh, yep. Yeah, of course. Yeah, this should be its own response. That's a good call out... 14:52:45 Otto Mora: Yes... 14:52:56 ... Yeah, contextual. Correct 14:53:01 Joe Andrieu: So, we'll deal with that... 14:53:02 Steve McCown: Kind of the implicate. Oh, sorry. Go ahead... 14:53:05 Joe Andrieu: Oh, no. I was just gonna say I'll save that for later. Like, we'll come up with a good description... 14:53:08 Steve McCown: Yeah, part of the... 14:53:12 Joe Andrieu: Just in the interest of time... 14:53:25 Steve McCown: Yeah, the implication of what's going on with this, the reason this is a concern is, just like everybody wants your cell phone number or your email address today. Um, when DIDs are more prolific, that's what they would be correlating on... 14:53:32 Joe Andrieu: Yep, agreed. Okay. Looking at the next one... 14:53:37 q? 14:53:47 ... Correlation by data exchange. So even if you use contextualized unique DIDs with different parties. It can lead to correlation if in the context of those DIDs, the user exchanges additional correlatable information 14:54:06 ... So, uh, for example, sharing an address in order to receive a product, like, have Amazon ship you something, um, allows anyone who got that address to correlate the… the user. And so, if I go to a bunch of different sites, and I'm… I have to 14:54:28 ... Give them other information because maybe they require me to like, oh, they've got to do KYC. So I have to upload my driver's license, but I'm using a unique DID to log into that site. They now, of course, have data that they can correlate. So it doesn't get rid of all the risks in this world of a sea of information where lots of things are 14:54:28