Meeting minutes
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, pause
<ottomorac> transcriber-bot, resume
Agenda Review, Introductions (5 min)
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...
… 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
… Then we also have a PR review on 342
… 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
… 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
<ottomorac> w3c/
Otto Mora: There is also something that I wanted to bring up, which is this, uh, TPAC
… Uh, meeting a session request that, uh, we submitted
… 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
… 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
… 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?
… 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
… Uh, also, generally, any other, uh, additions to the agenda, or topics that folks would like to bring up?
… Let's see
TAG Issue - hedgy DID Parameter text (5 min)
Otto Mora: Okay, so
<ottomorac> w3c/
Otto Mora: Uh, yes, so this one, it's, uh, issue 341. Um
… Which I'll just share because I think it'll be easier to just kind of navigate through it here. And
… So there was a observation from the folks in TAG
… 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
… 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
… 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
… Considering whether that should be a should and whether this green text here
… Uh, would be, uh, a good, um
… 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
… Marcus to it about it as well. But I'll pause right there. I see Will already. So go ahead, Will
<Wip> w3ctag/
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...
… 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
… make sure everyone has some attention on it. In case people have differing opinions. About how we should handle this
Otto Mora: Hmm...
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...
… Bit of normative text
Otto Mora: Right. Yeah, I agree. Manu?...
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...
… 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
… So the other way to do this is to move it into. Uh, did core
… 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
… 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
… 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
Otto Mora: Okay, I see Marcus. Go ahead...
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...
… There are some… some situations where
… where both… both make sense. For example, if you look at methods such as didSkid, or didCarry, or didSell, um, you're passing these
… You're passing this additional information that's needed for resolution, and
… 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
… 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
… I think it would be fine to just turn this into a shoot, as it suggested in the comment. Um, I'm
… didn't really fully understand what Manu said. I don't think this is
… DIT method specific. I think this is something that's a generic question or guidance about DIT parameters and options. In general, um
… So anyway, I don't feel strongly about it. I think turning it into should would work
Otto Mora: Yes, yes...
<Zakim> JoeAndrieu, you wanted to say I'm not sure this guidance is good
Otto Mora: Yeah, I'm curious about that testable aspect as well. That's interesting. Joe?
… You might be on it
<TallTed> "A DID method can use DID parameters for use cases ..."
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...
… 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
… is because the DID URL author is likely not the resolving party
… 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
… 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
Otto Mora: Banners...
… Okay, yep
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...
… which all specs need to have. We define the conformance classes. and the rules you have to follow
… 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
… And so, we have a conformance class in did-core, and we have a section that tells did-method authors what to do
… 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
… Uh, because the guidance is specific to, uh, how you write a DID method specification, um
Otto Mora: Mm-hmm...
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...
… That's it
Otto Mora: Okay. Uh, yep, thank you for clarifying. Uh, Marcus?...
Markus Sabadello: Uh, thanks for explaining about the conformance classes, but I don't think the text in question is in...
… in a section that has anything to do with DID methods, right? It's in a section about
… didParameters, so if we have text in the didParameters section
… How would that affect the methods conformance? I don't really understand that
Otto Mora: You seem too odd to remember in those parameters...
<Zakim> JoeAndrieu, you wanted to say DID methods don't write DID URLs
<manu> I don't care enough to keep discussing this topic -- we can move on, I won't block in either case.
Otto Mora: Either being moved to did resolution or or something to that effect recently. Sorry. Uh, but yeah. But
… You're on mute, maybe
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...
… 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?
… 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
… 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
Otto Mora: Yeah...
<swcurran> +1 to removing the text
Otto Mora: Um
<manu> +1 remove the text
Otto Mora: There's diverging opinions on this one
… Steven is… seemed to be citing
… With, uh, Joe here to remove, as well as Vanna to remove. Um
<manu> If we can't agree, remove the text.
Otto Mora: Okay, go ahead, Will
<danpape> +1 to remove
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
green?...
Otto Mora: Yes...
Will Abramson: or remove the text in the green, plus that text that Jeffrey is suggesting should be a should...
Otto Mora: Yeah...
Will Abramson: Like, are you removing all the text? And that is fine...
Otto Mora: Okay, um… Uh, Steven...
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...
… 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
… Um, but that last part should be removed
… That's it. And as I say, sorry, it's removed in the PR that I put in
… Yeah
Otto Mora: OK, so your PR alters the green box to remove this last bit...
… And then you're saying we should try to keep these two
… Okay
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...
<Zakim> JoeAndrieu, you wanted to propose edit
Otto Mora: Uh… Sure...
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...
… 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
Otto Mora: Mm-hmm...
<manu> +1 to Joe's suggestion.
Otto Mora: Mm-hmm
Joe Andrieu: is worth removing. So the bit before the green, and then that last sentence. What would be my proposal?...
Otto Mora: So what I'm… what I'm highlighting now… sorry...
Joe Andrieu: And and I'm sorry. And I meant turn what's in the green. To not be a note...
Otto Mora: To not be a note. Okay, so what I'm highlighting now is what you would keep, essentially...
Joe Andrieu: Yes...
Otto Mora: Remove this. Remove this last sentence and keep the highlighted things. Okay. Uh, plus one from...
<Wip> +1 sounds good
Otto Mora: So, okay, cool. Um… I will take this on, no problem. Um… So… Yeah
… Okay, I'm gonna sign myself
… Oh, but maybe that's because I'm not, uh
… Managing the anyways, I'll I'll I'll I'll
… Don't worry about that. I'll I'll do that later. But, yeah. Okay. I'. Okay, cool. Um
… Will, can you assign that to me? For some reason, I'm not at that point on the… I'm done
Will Abramson: Sure. Never...
Otto Mora: Sure. Okay, cool. Okay, so quickly moving on to 3, 4, 2. We'll do it for a maximum of 8 min...
… Because I want to let Joe have some time for the threat modeling discussion. So
… Let me… What specifically?
w3c/did-resolution#342
Otto Mora: the PR
… which is 3, 4, 2. Okay, so
… 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
… So, yeah. And
… Don't know if maybe Steven wants to
… Give us his last bit on that one, whether I guess you might be incorporating those recent comments from Joe, probably
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...
… So I'll take a look at that. But no, I haven't made any changes since our discussion yesterday
Otto Mora: Okay, no worries. I see Marcus. Probably you want to raise the. But the comments you. Go ahead...
Markus Sabadello: Yes, well, my objections to this change are well known, so don't want to waste time going over...
… 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
… 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
… 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
… passes the entire DDRL to the resolver, including the fragment. Um, so I'm surprised to see, uh
… re-approvals for this. I wonder if people actually read pull requests before they approve them
Otto Mora: Okay, you're mentioning… 611 here. or...
… Practice. Stephen, go ahead. Sorry
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...
… 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
… Um, that doesn't have a SCID in it, for example, that might pass URL validation, but not pass DID validation
… 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
… 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
… 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
Otto Mora: Okay...
… 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
Stephen Curran: No...
Otto Mora: No, I'm not. Okay, thank you for that...
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...
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...
Stephen Curran: So, validate...
Otto Mora: Mm-hmm...
Stephen Curran: prepare, and then validate. The third step is validate the input did...
Otto Mora: Got it, got it...
Stephen Curran: Um, okay...
… 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
… In… in specifying the input data, and then validating the two separately
<Zakim> JoeAndrieu, you wanted to suggest we use the Base DID URL pattern here to name and describe the DID URL without the fragment
Otto Mora: Thank you. All right. I see, Joe. Go ahead...
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...
… 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
… 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
… 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
… 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
… we have long agreed is not something we should do. Um, so I think we should have that in the spec
Otto Mora: Like this...
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...
… the generic DIT syntax, the generic A, B, and F, and for that reason, it
… 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
… That the way it's written right now, so this would be a
… a change, and, uh, regarding passing the fragment to the resolver, and in my opinion, also
… passing the path to the resolver is just crazy, I think. This contradicts a lot of
… 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
… Uh, and surveillance by Resolver Services, um
… On the previous call, there was an opinion that this is not a problem, because supposedly you have to trust the resolver anyway
… 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
… ping horizontal review, the privacy group or the attack would agree
… to that and it would be, I would raise formal objections for sure if we, if we have this in the spec
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?...
… Mm-hmm
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...
Otto Mora: Okay, well...
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...
Otto Mora: I guess totally noted, and uh...
… We can see what adjustments are made, but maybe we move on. I see Steven, sorry
Steve McCown: Yeah, just a real question, a quick question on Marcus's concern about passing all the other stuff to the resolver...
… I… if I'm not mistaken, I heard either Steven or Joe
… Say that we could trim that down and just pass like a base
… Base URL, the base part
… Are we pursuing that? That sounds like it would resolve Marcus's privacy concern
Otto Mora: Joe?...
Joe Andrieu: Uh, just… just to respond to Steve, um… The the base URL can have a path in it...
… 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
… Um, unless it's overridden by a base element in the HTML. Um
… So it does not address that the path information may contain sensitive data, but so may all the queries
… 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
… But the figured out the base did URL is really just about stripping off the fragment. Um, it doesn't address the path part
Otto Mora: Okay...
Steve McCown: Okay...
Otto Mora: Last word, Marcus, on this. Go ahead...
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...
… It would address that part, but it would not address the path
… problem, which I think is equally problematic
Otto Mora: Okay, so, yeah...
… I guess we can evaluate there, Stephen. Um, okay, thank you. Um
Threat Modelling Discussion
Otto Mora: Let me move on to… Next topic
… 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
Joe Andrieu: I just...
Otto Mora: The algorithm changes as well...
… Oh, like in the resolution algorithm changes, sorry. But… I don't know if there's direct
Joe Andrieu: Um, no, I'm not gonna speak to that. Um...
Otto Mora: Just from that...
… Okay
Joe Andrieu: The… so, this… this is a little bit of a hodgepodge. I put together a presentation, um...
… what I'm going to try to do is give the group, um, an update on where we're at and what's next
… If we can, it would be great to get the group involved in enumerating threats
… 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
… 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
… 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
… 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
… 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
… 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
… 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
… 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
… 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
… 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?
… Um… For the W3C, we have advocated that there are four different kinds of threats that we want working groups to think through
… 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
… 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
… 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,
like, is specifically trying to address that
… 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
… 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
… 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
… 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
… 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
… Ecosystem of really complex interweaving and independent technologies. And so there's, I don't think it's
… 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
… 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
… 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
… 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
… 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
… 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
… 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
… 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
… It has some some good introductory pros, in terms of the, introduction, the architecture, a description of what is resolution
… 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
… 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
iterations, um
… 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
… 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
… 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
… 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
… that feels like too much, but I wanted to include all the different parties that are stakeholders in this, so we have that analysis
… Um, then we get to this threat section, which this is… I apologize, because these
… These are not real threats. These are examples of the threat engine, um, that we've now abstracted into something called respec threats
… Um, which is a… just a little rendering engine that, um
… 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
… 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
… 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
… Um, which has a little bit more, um, actual threats in it
… Let me find a chat in… well, no, it's in the lounge that I want to get to, I guess. Um
<JoeAndrieu> https://
Otto Mora: And you're gonna share the presentation as well later, right?...
… Okay. Or just… yeah, right
Joe Andrieu: Um, I can, yeah, I… uh...
… 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
… 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
… But the threats that start to get interesting were just some of the things that
… Came out of some of the early conversations
… One thing I wanna clarify is
… 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
… 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
dependency?
… 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
… 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
… 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
… 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
… And when we're ideating, it's too much. So that's that's part of the challenge
… 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
… 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
… 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
… 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
consensus. Um
… 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
… 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
… 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
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
… 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
… For the DID resolution threat model. And then the next steps for the DID core
… Um, it's a little more vague to me, like, because one question is, are the diagrams that we have
… for bid resolution…the same diagram that we would have for did core
… And it might be. Um, and so there's some analysis and discussion to be had there, once we are a little bit more familiar with that. Because if it's… if it's the same diagram, it might, in fact, be the same threat model. There may be unique threats
… But there might not be
… So I'm not sure if the did resolution threat model will end up being like 90% of the did core threat model, or if there will be a a different refactoring of that as we move forward. But those are open questions. Um, I did see there's, uh, Wills on the queue
Will Abramson: Yeah, thanks. I mean, this is great, but I just want to observe, I don't know what we do about it, but...
… You've outlined a
… what feels like, to me at least, a fairly significant chunk of work, right? We got a
… first ideate and identify this subset of threats that we then have to, like, refine and get into a place that we're happy for them with did resolution. And then, I think you're imagining we're gonna ask Singh for a review over those threats and over the spec
… And then they're gonna come back to us with some feedback that we're gonna have to try and address, right? Like, maybe it's not words, but still some. That all will take time
… Um, I guess I'm just wondering if you think that we have time in our
… 4 months left to do this, and then there's the did-call-threat model as well, right? Like, I mean
… I wonder what the group thinks, like, is this achievable? Like, what is the, like, minimum viable thing that we can get that takes
… I know it's not just a box-ticking exercise, and maybe the fact is we just aren't going to finish in time for our chart, but that… Feels like a real
… fail state for us, but… I mean, I worry about that, basically, and it's not just the threat model at work, it still feels like we have a lot of
… now I think is that we've got to work through, so… just sharing some concerns, I guess
Joe Andrieu: Otto, where are you gonna go?...
… Hahaha!
Otto Mora: Sorry. I'm I'm just doing the same thing you do when you talk on me. I'm sorry. Okay. But my, the reason I put myself in the queue was for the the previous slide where you you talked about the threat taxonomies. So like...
… You were almost saying like putting classifying these in the potential threats that we ideate into the taxonomies is a later process, or, as we suggest these threats, we should already be thinking of the taxonomies which, by the way, like I'm completely
… new to the concept of taxonomies, but I was just trying to understand, yeah, whether we just freely ideate, and then we classify, and put in all the details to it, or… yeah, is it more of a free brainstorming, or should we already be thinking in the… Absolutely. model
… Uh, yeah, so go ahead, Joe
Joe Andrieu: Yes, so we should already be thinking. We probably aren't, but that's okay. The point of the taxonomies is twofold. One is to give you a framework of analysis, like STRIDE and LINDDN and OSSTMM3 all have...
… They're highly opinionated about the analysis. So that's cool. They can give you a way to think through these things. But what we need in terms of the threat model's own integrity is we need the taxonomical
… Definitions, right? So what is spoofing? I mean, spoofing the way Stride defines spoofing. Or, you know, I'm talking about penetration testing the way OSS TMM3 is talking about penetration testing
… I don't know that that's a legit category for a threat because it doesn't feel like a threat. But my point is that the vocabulary domain is one aspect of that. To Will's concern, yes, there is work to be done
… However, the second half of what you described is the security review that we have to go through anyway
… Um, seeing, looking at our specification and our threat model, and giving us feedback, and us responding to that feedback is part of wide review. Um, so that is not new work
… Um, in fact, the… the hypothesis being advocated by, um, Simone, and I… I think it's a good one, is that by getting the group to pre
… do the work on the threat model, it will make it easier for Singh to do a better job
… And so, yes, someone has to do the work. And part of the work is in the the domain expertise of the people in the working group and not in the security guys. Right. Developers tend to have a different sensibility about how they think through things, especially when it's your baby that you're creating
… And it's the security guys who have a, like, we're gonna attack it in all the ways we can think of, and they just have a different sensibility. So, creating a medium for that conversation is what we're talking about here
Otto Mora: Okay, so I think, was it Steve first? Yeah, go ahead, Steve...
Steve McCown: No, I just wanted to say thank you, Joe, for presenting all of this...
… This this is really important. It's one of the things I've observed over the years is
… In the old days, not so much now, we used to write code and nobody ever wanted to write the test cases for it
… Um, and we… we kind of had this… this perception that we'd thought it all through, and we'd done it correctly, and as
… Long as we we got results, we expected it was it was good and then
… come to find out that's not always the case. I think, um, we're having the same kind of awakening with… with security issues and supply chain security issues, um
… And so, Will is correct. This is a fair amount of work, um, to do on this spec and, uh, other projects, and
… I guess the question we need to debate is
… What what level should we be doing? I mean, all these things Joe presented are correct
… But just like we never used to like to write test cases
… Now we don't like to write security test cases or threat modeling. And so
… rather than just write it off as it's going to be a mountain of work, I think it'd probably be good to figure out how to streamline it a little bit to make it a little more automatic, because
… I think we're at the time in societal computing life that we can't not do this
… But at the same time, we don't have time to do it, so I think we need to kind of look for door number 3 a little bit. Uh, because it does need to be done
Otto Mora: Mm-hmm. Marcus...
Markus Sabadello: Uh, yeah, first of all, I think this looks great, really interesting. I admit I haven't looked at this yet, but I will. I have two quick questions. One, we already have some privacy and security considerations. Is the idea that...
… the threads would be linked or aligned to those? Like, would we try to get to a point where, for each one of the privacy and security considerations in the specification, there would be a corresponding thread that this document elaborates on? That's my first question, and the second question about the responses
… that you mentioned, we have at some point, or different times in the past, discussed certain security threats, and then come up with ways to address them. I'm thinking
… Thinking, for example, about the question of how can you trust the resolver, and how do you know that the resolver returns the corrected document? We've discussed that so many times, and then as a response, we came up with new properties
… in the resolution and the document metadata that could allow a client to somehow independently verify the results. So that's an example where we discussed
… a threat, and then a potential way to address it in the past. Is that the kind… is that what you… what you meant by responses in this model?
Joe Andrieu: Yes, that is exactly right. And to your earlier point, we're still teasing out the nuance of how do we update privacy and security considerations. That involves process changes depending on how deeply you want to go. The expectation right now is that it would be acceptable to have a security considerations section that enumerated...
… the the threats in a separate threat model. So like you have an index or table of contents that says, Hey, we have just the names of the threats. Go look at our threat model to understand those in detail. You could also have some paragraphs. You could. You could keep the whole current security consideration sections and have the threat model
… But I think the understanding, at least for Singh, is that a lot of the security consideration sections are hand wavy and not particularly useful. I think we've done a little bit better than that in our work. But the idea is to integrate those. And I don't have guidance yet from Ping about
<Wip> Part of the challenge is we only started really working on this or understanding that this is what SING wanted this year really. So with ~ 4 months of our charter left. Now we have 6 month extension, but only really 4 months left of that. We just have to be realistic about what we can achieve in this timeline
Joe Andrieu: um, whether or not they would align with that. Um, but, uh, we have expectations that they would, because of things that, um, uh, the chair of Ping has said separately. Um
… So I'm hoping that a table of contents that, you know, enumerates
… Um, hey, this is a privacy set, or this is a security threat, can be used primarily as a security considerations and privacy considerations section
… Um, but I think we're still… You know, vetting that with the rest of the institution
<ottomorac> transcriber-bot, pause