VCWG Spec Refinement

VCWG Charter Update

Joe Andrieu: Howdy folks.

Phil Archer: Good luck jump.

Joe Andrieu: Hey Phil. Thank you all for being on time. I do appreciate it. I see the two regulars we might be expecting. Ivan and Manu aren't going to be here. Um, is there anyone else we're explicitly expecting? Um, Denken, do you know if Air might be able to make it or do he only know him through his um issue that he posted?

Denken Chen: I don't know.

Joe Andrieu: Okay, we'll give folks another minute and then get started. All right. So, Denken, um, when you and I chatted yesterday, we talked about a few things you proposed that we bring up. Um, which item would you like to tackle first?

Denken Chen: And I think the holder binding should be an easier one. We can start it from that. Okay. Menu, please.

Manu Sporny: Just a real quick uh agenda plus. Um, there is some discussion going around the new verifiable credential working group charter and I just wanted to kind of point folks towards that.

Manu Sporny: Phil, I don't want to overstep uh and Joe and Denken uh overstep, you know, I mean it's public, right? So, I'm I'm hoping to just draw people's attention to it and then we don't need to talk about it at length. Looking for guidance from the chairs. Phil, you first and then Joe and Denken on uh how to talk about uh proposals.

Phil Archer: Uh um, so very quickly because we shouldn't be taking up this call which is about the confidence method. Um, Manu, the call you had yesterday with Carolyn Bernier, who you and I know but many people may not know, she's like one of the very important people in the digital product passport world and Casten um and Susanna um has had a lot of pigeons flying. I'm pretty sure we're landed on exactly what you've written. I haven't read the sorry on the thing on the PR. I haven't read the PR yet, but I think it is very likely that we will be adding it this in as a tentative deliverable, but I'm having 17,000 conversations around it because the politics of it are enormous.

Phil Archer: Um, and so I need to tread very carefully and I'm constantly having to change hats between my role here as uh Brent's co-chair and this group which has a different outlook to my day job one and so I'm balancing a lot of things here, but yes, it's there and um Ivan will guide us here, but I think it is very likely that with that addition and the other one, we may have to go back to everybody and say, you know, you voted for this thing, could you please have a look again because we changed it? Could you cast your vote again? I'm afraid that's um uh I think that's inevitable at this stage.

Ivan Herman: That's a requirement that we do that indeed.

Phil Archer: And does that mean then that the deadline then gets put back because currently the deadline is Friday?

Ivan Herman: For the current reviews. Yes. But then then when we have the PRs and we have accepted them, then we will have

Phil Archer: right?

Ivan Herman: about I don't remember I think it's a it's an email contact to all voters of 10 days or maybe two weeks I don't remember exactly but it's it's about that.

Ivan Herman: So it will delay the new charter's uh starting point.

Phil Archer: Okay.

Ivan Herman: That's

Phil Archer: Thank you. I don't want to hold up this call which is not about this topic, but thank you manu. Yes, it's happening. You will hear about it. We will talk about it. Yeah. Thanks man. Eyes

Joe Andrieu: Cool. Thank Thank you, Manu. I appreciate that you brought it up. I agree. Let's not talk about it now, but thanks for that link. Um, it's an interesting conversation to be had. Okay. Uh, Dan, back to our issues. Do you want to talk about number 25? The holder

Denken Chen: Yes.

Joe Andrieu: binding

Denken Chen: Yes. Uh, for the holder binding things, I know that uh, there are folks concerning about using the word binding, and that's why we move away from using the word binding, uh, but use confidence instead. And uh, my point has been always that the holder binding terms has been used elsewhere, particularly in the EU in the Europe UDI, UD wallet, their architecture framework, and I think it's a good thing for us to clarify clearly about our thoughts about how confidence can be increased through different mechanisms that we will define

Denken Chen: in our confidence spec, uh, but just include like there are some somewhere else using a turn holder binding, uh, but here's how we think to improve the confidence in the beginning of the paragraphs, uh, let's my focus on this, okay? So first, I think T is the first one preset. Go

Ted Thibodeau Jr: Yeah.

Denken Chen: ahead.

Ted Thibodeau Jr: Um, so holder binding was never an accurate term in any sense. We we never have had a way to enforce that only this entity or these entities are allowed to hold this spec or present it. It it's it's just never been a thing. So the folks who brought that terminology to other specification bodies never brought a useful thing. It was never something that we defined, never something that we made functional, never useful. Um, I'm afraid that confidence method is doing a similar disservice to people trying to use it. Now, confidence in what are you applying this method in order to increase your confidence? Um, I think what is trying to happen or trying to be made happen is authorized holder or authorized presenter, which is more accurate because anybody can hold this sequence of bytes.

Ted Thibodeau Jr: I can give it to somebody on a floppy or in a QR code or whatever else and they can hold it however long they want to and it doesn't matter whether they are authorized or not until the moment that they try and present it, make use of it. And even then, it may not matter that it's passed through a hundred hands on route to that presentation if the final holder is listed as an authorized presenter. And I think that is what is actually trying to be made use of is an authorized presenter. I think that's the thing that's trying to be held. I'm not certain because people keep gravitating to these old terms that have never properly been defined and still don't function even in the places where they've tried to put a definition on them. There there is nothing that makes me drop a VC that I'm not a listed holder of. Um, I think that's it for now.

Joe Andrieu: Okay, I'll go ahead and go. Um, I agree that uh, the term holder binding was never an accurate term.

Joe Andrieu: And so I think the the point of having a section on holder binding, which may not be a top level section, um, but to explain why we aren't using that term and why confidence method is a different way to think about it. Um, I I think you're close Ted with your thinking about what the semantics mean. However, I think it goes a little bit further with confidence method in that you don't have to be presenting. I could have a, for example, a verifiable credential for a marriage certificate that has the officient, two spouses, and two witnesses. And it it may be that this was submitted at some point to a school to establish parentage or something like that, however these are used in civic society. And then later someone else says, "Hey, this was the officient at this wedding. I want to go find I I want to verify that that person is the person I think they are and I can use this confidence method that may have been included for the officient so that in a separate ceremony that is not necessarily the presentation of that VC, we could increase our confidence that the person we're talking to in real time is that person who was in the VC that we got two years ago.

Joe Andrieu: So that's it. Uh, Manu, go ahead.

Manu Sporny: Yeah, plus one to uh those uh uh modifications, Joe. Uh, so again, plus one to what Ted said. Uh, holder binding was never a good term. We told people that fairly early on. People did not heed the warnings and now we're in a position where we should probably say something uh more a little more strong in the specification. We can do that in the terminology section uh of the specification as option one. Option two is to put it down in the security consideration section to very clearly let people know that holder binding is not a thing. Like it is not it is not something that you can you can um uh do uh due to uh proxying and and other things of that nature, right? Um, you can never bind something uh to a holder. Uh, okay. So, so that's, you know, item one. Um, item two is I agree with Joe's uh uh modulations to what you were saying, Ted.

Manu Sporny: Uh, I don't think it's about presentation. It is about raising confidence in a subject and it does not have to happen at the time of presentation. It can happen at at some uh other time. Um, so I do think that there's work to be done there. Um, uh, and just acknowledging, uh, that that's it.

Ted Thibodeau Jr: So just to clarify um, not necessarily in confidence in the identity of the presenter, but it it's a method of increasing confidence in something. It could be any of the attributes spelled out in the VC. Um, in Joe's example, it it would be confidence in the identity of the officient and the method used to increase confidence of the identity of the officient. But it's still not about the subject nor any holder nor right that there it's not generically increased confidence. It is explicitly increased confidence in something, and I think in that sense, it could be applied to anything within the VC. I, as an issuer, have increased confidence in my stating that this is the subject of my DC.

Ted Thibodeau Jr: I it gets really hanky really quickly, but that's I think where we're going. Uh, where people are going in in every discussion of it. I think they're all going in the same direction, but nobody seems to be actually saying that's the direction they're going in. Unless I'm missing it. That's a

Joe Andrieu: Anken, I think you're

Denken Chen: Okay, thank you. Um, to be clear, like as a as a product that uh

Joe Andrieu: next.

Denken Chen: manual said that we can clear some uh clear things in the terminology sections. Um, I I just would like to have a section or some ways in our spec to distinguish or respond to what other specification has been used in the terms, like we are actually answering the same questions but in a more accurate and uh reasonable ways. So, for example, um, in the UDA, their architecture reference work, they use the turn use uh the holder binding in the beginning, most of the time, and then switch to user binding, which I think is even all even more awful world because you you cannot really bind to any holder and not user because there's no device can be really bind to any specific user at all.

Denken Chen: Um, but there's also another word, device binding using in their spec. So, there are three things, there are holder binding, there are user binding, there are device binding, which I think uh device binding could be the only reasonable way. For example, in our first goal of this spec, we are going to include the O and the facial image. So for the O, it's similar to device binding, it's binding to a cryptography material. And for facial image, it's related to user, but it's not binding to user, right? You can like using face recognition to improve the confidence, like the holder, the presenter is the holder or the subject, etc. So, we can make it really, really clear of these terms in our spec, um, that will really help for anywhere in the world implementing digital identity. Um, in our case, uh, during our internal discussion, we talk about this a lot. Uh, how do we ensure the presenter is the subject or can we really do that? Is is it really technically doable? We can describe it really clearly in our spec, and that's my initial motivation for this spec.

Denken Chen: Thank you.

Manu Sporny: Uh, yeah, uh, there's a lot of chatter happening in the text that's not going to show up in the minutes. Um, so just vocalizing something that Dave said, uh, which is uh, we're talking about raising confidence

Joe Andrieu: f***.

Manu Sporny: in any subject in the VC. Uh, and Phil is saying, well, yeah, it's really it might be any claim. Um, I think there's that's a good direction to go in. Uh, I think maybe uh, well, I'll let Joe clarify what he meant, but um, I think that's the direction we want to go in uh here is that you're raising confidence in one of the things identified, uh, and, you know, potential claims, um, associated claims in the uh, in the in the VC. Um, that's

Joe Andrieu: Okay, thanks Benny. Um, I I don't think it's at the claim level, and I think um, Dave's comment actually spoke to it pretty directly. Um, we're talking about confidence in the subject. Confidence in the predicate or confidence in the object is something actually that would be very hard for us to express.

Joe Andrieu: Um, maybe RDF star could let us start to do that kind of thing. But the way the architecture works, we have an ID and we have a confidence method. And what we're saying is something about that subject. And so the the the pattern that we're talking about is is the subject of this VC the same entity in some other context. And it may be that there's a there's a signature on something that's posted to a public record. It could be an interactive session with someone um after the fact. But what you're trying to do is say, oh, the subject in this VC, that's this other person in this other context. And I think it's not about the rest of the claims or the rest of the components of the claims, just about tying the subject, um, correlating them from one context to another. The first context being the VC, the other context being wherever else that confidence method happens to be exercised.

Phil Archer: This discussion for me highlights the um problem I have is that the in my head, there is a blurring between what we're talking about here and the completely separate um work being done on verified issuers.

Phil Archer: So, and and it goes back to something that happens quite a lot in this community, which is that for reasons I fully understand, of course, a lot of this community is motivated by um the personal credentials of, you know, of an individual. the world I work in, we're about we're talking about credentials for businesses and for inanimate objects where the this is something that my organization is going through. We are improving dramatically in some cases the way that we know our customers. Um, in some parts of the world, if you want a GS1 identifier, you turn up and your credit card works and there's a GS1 identifier. End of. In other parts of the world, you want a GS1 identifier and they check the local business register and they check this and they check that, and if you pass all that test, then you can have a GS1 identifier. And that's that's an issue that we're handling. But that speaks to the issue of if I give you if I GS1 give you a credential, it is a process I'm going through.

Phil Archer: It's not asking for a biometric this or a photograph of that or a blood sample. It's my own process that I followed that gives me confidence that I'm issuing it to somebody I know. Now, maybe that belongs in the verified issuer spec rather than here, but for me, the discussion that's going on right now blurs that line between those two things.

Ted Thibodeau Jr: So, I'm pretty sure I'm next on the queue. Um, you what you said Joe,

Joe Andrieu: Go ahead, Ted.

Ted Thibodeau Jr: it has never matched my understanding that this confidence method thing is about the subject or subjects of VC, who has confidence in what again, it it it just doesn't lie. Now, if you put the subject in a statement where you say the subject has confidence method XYZ, then I as an issuer have used XYZ confidence method to confirm that the subject that I'm speaking of is this subject. And then I say whatever else about that subject. There might be blank nodes involved that collect some number of predicates associated with a subject and that blank node has a confidence method associated with it and that's where I got all those attributes.

Ted Thibodeau Jr: But here there is an explicit association of the confidence method with the predicates, and that's what I've been arguing for. is that confidence method could be applied to any predicate or number of predicates in the VC. And that confidence method is how I, as the issuer, assured myself that I was speaking about this entity and that these were the attribute values that are associated. It it it can't be about the recipient. It can't be about the initial holder because that is it's purely about holding some series of electrons, and that can be multiply copied and passed around and nobody knows. The useful thing in my mind is being able to say somehow that only holder X, whom you check that they have these attributes to ensure your confidence that it is holder X, is authorized to present it because that's what's useful about a VC is presenting it. I I don't I I I'm trying to see how the other things would have value and I'm not seeing it except at present at presentation time.

Ted Thibodeau Jr: And it could be it could be that the only authorized presenter is the one that has this blood analysis, but if we watch some Mission Impossible films or old TV shows, we'll see how easy that is to spoof. But then we have confidence method and the method is that we mash that presenter completely to paste and then we analyze it and then we're sure, but

Joe Andrieu: All

Ted Thibodeau Jr: of course, then they're not so useful going forward. I yeah, I'll leave it at that for now. I'm going to be a lot of minus ones if everybody's still on the same page they were a few minutes ago.

Brent Zundel: So,

Joe Andrieu: right.

Brent Zundel: First, I'd like to start with a brief apology for my part in the propagation of holder binding as a term. Um, and note that the existence of device binding as a term in the other spec was something that I pushed as a replacement for holder binding, which didn't quite entirely get fixed, but it was a step in the right direction. Um, I think so I cued to agree with what Joe was saying.

Brent Zundel: Um, while I think it could be useful to allow confidence methods to help the verifier to obtain confidence in any of the attributes of a credential, I fear that expanding the scope to that extent will make producing this specification difficult if not impossible. And so limiting the scope to confidence in some relationship between the presenter and the subject would probably be a good idea. However, if the group wants to go in that other direction, I'm not going to, you know, stand in the way of that. It's just this is a concern I've brought up in the past. I still have the concern and wanted to voice it again. Now, all of this said completely, chair hat off.

Joe Andrieu: Thanks, Brent.

Manu Sporny: I think you automuted.

Joe Andrieu: Uh, Jason LD moderate the predicates.

Ted Thibodeau Jr: Oh,

Joe Andrieu: Um,

Ted Thibodeau Jr: I think everybody lost most of what you were saying.

Joe Andrieu: Oh, okay. Thanks. Can you hear me now?

Manu Sporny: Yes.

Phillip Long: Yeah,

Ted Thibodeau Jr: Yes.

Phillip Long: but just start over.

Joe Andrieu: Okay. Um, I think we do not have a technical way that is reasonable.

Manu Sporny: lost his audio

Joe Andrieu: Great. Um, uh,

Manu Sporny: again.

Joe Andrieu: predicates

Ted Thibodeau Jr: We do not have a technical We do not have a technical way that is reasonable. Cut

Joe Andrieu: Ted,

Ted Thibodeau Jr: off.

Joe Andrieu: please don't interrupt me.

Manu Sporny: No, no,

Joe Andrieu: I let you speak for quite a bit.

Manu Sporny: we lost your audio, Joe.

Joe Andrieu: Oh. Oh, I'm sorry.

Manu Sporny: We We keep losing your audio.

Joe Andrieu: I'm sorry. Thank you. Sorry, Ted. I thought it was a different comment.

Ted Thibodeau Jr: No, the cut off is where we lost you. I'm sorry.

Joe Andrieu: Oh, it's all good. Um, now I don't know where I was. Um, uh, that technically with JSONLD, we can't moderate the predicate. like we don't have a way to make that statement. We have a way to make statements about subjects. Um, and the predicate is confidence method.

Joe Andrieu: So twisting the confidence method so that it could apply to another predicate or an object, um, is the kind of exercise that RDF star is about. Like it is it is a a weird and hard thing to try and do. Um, but I do want to acknowledge Ted, I think I think we have been on different senses of what this is. you've never understood like why we're trying to do this thing. And I agree that how you're thinking about it is not how we should do it because that that would not make sense. But I also think you're you're um, you're thinking more about assurance that an issuer might do before issuing a credential, which is different than what a verifier is going to do to increase their confidence. So to to be very explicit to your question, it is the verifier who is increasing their confidence that the subject of some context is the subject of the VC. That's what we're increasing confidence about. And I I think it's a very closed form statement. And the point is the issuer is providing a hint for the verifier that hey, this is a way you can increase your confidence.

Joe Andrieu: We believe that this is a way that that the holder, the subject that we intended could verify to you or increase your confidence that they're actually them. That's it.

Manu Sporny: Yes. Plus one to that.

Joe Andrieu: Manny

Manu Sporny: I think I think we're uh I think there's just a miscommunication because the thing that you said made made sense to you, Ted, is my understanding of what we're actually doing. And I'm seeing a lot in the chat of like other people agreeing like we're doing the same thing. We're not doing the insane thing, right? So there's a miscommunication here. I'm just trying to figure out how we can solve that. What you said, uh Ted, confidence that dog A is the dog in front of me. Yes, I think that's what we're trying to do and and that's it. Like uh and plus one to what Brent said, none of us want to see the spiral into blood tests and DNA analysis and that kind of thing. Like let's just let's just do like, you know, cryptographic key, you know, mechanism and then if that's all we get done, then that's fine.

Manu Sporny: We can add other things in the future, right? Um, that's

Joe Andrieu: Cool. Thank you. Um, Ted, did that help at all? I just want to check in. I mean, we should probably move on, but Okay.

Ted Thibodeau Jr: No, I'll keep reading and I'll keep conversing and hopefully we'll get closer to it. But the if this thing has a specific purpose and is only for the specific purpose, then the generic label confidence method is not useful in my opinion. And I'll leave it at that for now.

Joe Andrieu: Okay, thanks

Manu Sporny: Yeah, let's get some examples and PRs raised.

Joe Andrieu: Manny

Manu Sporny: I think we'll we'll be I I'm confident enough that many of the rest of us are on the same page and if we get some examples and text that we can look at, I feel like we can make the refinements at that point. That's

Ted Thibodeau Jr: Uh, this is a minor tangent. Um, we have this chat block on the side from which we can copy and paste, and it might be useful to manually copy and paste that content to the PR or to the issue wherever in context.

Ted Thibodeau Jr: Um, I don't obviously want to do that with anything that somebody doesn't want to be pasted in that way, but I want to make sure that the things that have been said in both voice and typing get captured as much as we can. That's it.

Joe Andrieu: Yeah, it's an interesting question. Um,

Phillip Long: We've lost your audio, Joe.

Joe Andrieu: the issue. Um, but I think there's a better way. I just don't know that we've figured it out given this sort of loophole in our

Ted Thibodeau Jr: Forgive me for interrupting you, Joe.

Joe Andrieu: system.

Ted Thibodeau Jr: We lost most of what you said. You said that was an interesting question and then we lost you, and then you came back just a few words

Joe Andrieu: ago.

Joe Andrieu: Okay. Thank you, Ted. Um,

Joe Andrieu: we haven't really figured out um how to deal with this loophole in our documentation system. Um, uh, if you posted to the chat and you want it in the issue, please go make a comment in the issue separately.

Joe Andrieu: I think I would like to find a better way to capture this because there are a lot of good comments in there. Um, but I also don't want to grab them without permission. Uh, because part of what we implied or I think we stated rather explicitly is that that stuff's off the record. So if you need to say something off the record, it goes there. So we've sort of set up a catch 22 around that. But I want to defer the larger uh question rather than try and deal with it now. So please gra, if you have comments in here that you want to contribute, I'll drop the URL in again. Um, please just add them to the issue. I tried to capture my thoughts as we were going and I tried to moderate that a bit by consensus, but um, they that really is my thoughts, not trying to capture what the group said. Okay. Um, I think that's enough holder binding. What's next? Then

Denken Chen: Uh, thread

Joe Andrieu: okay.

Denken Chen: modeling.

Joe Andrieu: Ah. Oh, wait. I see Dimitri and Phil. So, uh, let's talk about this, Dan. This is I was trying to avoid it because I wanted to get spec text. Um, there's we've had conversations about um assurance levels um and the possibility that maybe that's evidence and we adjusted the charter um so that this deliverable isn't just about confidence method. We specifically opened it up so that it could address what might be a redefinition of evidence or to to my current thinking, and I'll let Dan chime in. I think we were on the same page about it that rather than redefine evidence, which is a uh VC level property, not a subject level property. Um, maybe what we should do is just create an assurance method, which is um a different way for the well, it is a way for the issuer to describe what assurance level they achieved and the kinds of things that would go in there are NIST IAL3 or EID medium, um that they achieved some regulatory standard and we'll have a vocabulary for the ones that that we know about and recognize and it could be extensible to do other assurance uh methods.

Joe Andrieu: And the idea there is that's sort of the other half Ted that I think you were talking about a little bit, that, you know, having the issuer explain what their assurances were um is part of this conversation, but a little bit different than what you would tell the verifier because if if an issuer tells me they did I3, um, that doesn't give the the verifier any way to do anything except just, oh, thank you, I appreciate that you did that. That doesn't give them like a, a key or biometric or some other way to do a secondary act that would increase confidence. Um, so I see Phil's on the

Phil Archer: Just very briefly,

Joe Andrieu: queue.

Phil Archer: I mean, this conversation has been extremely helpful for me and I appreciate your patience with me. Um, yes, I understand that what we are talking about is I turn up with a VC, I give it to you, and you want to make sure that I am the person that the issuer gave it to. That is now clear in my mind. I apologize.

Phil Archer: has taken me all this time to understand that's what this is about because I think some of you are more than aware of that. I'm going to suggest a slight rewording of the abstract that conveys that in words I get. But I do understand that what I was talking about is evidence that I am an issuer giving it to the person I think I'm giving it to. And that's not what you're talking about here. I understand that now. Thank you for your patience and explanations.

Joe Andrieu: You are welcome and I appreciate the confusion.

Phil Archer: All

Joe Andrieu: This is I'm bottlenecked on a a rev of the introduction, which was specifically to take hey why did we change the charter and update that abstract. So, uh, uh, it's on me to get some spec text that you can look at and hopefully when you read that, Phil, you'll be able to say, "Oh, I wish they had said this before." You're

Phil Archer: right. Thank you.

Joe Andrieu: welcome. Okay. Um, so threat modeling.

Joe Andrieu: Um, so who is we have a good crew on the call. Okay. So I want to start by introducing the let me get the right resource. Um, I have been working with Simone, the security lead for the W3C. He's staff and um, and uh, through the security interest group to develop this threat modeling guide that I'm sharing on screen and I'll drop the URL in. And the the goal that Simone and I have been trying to figure out how we deal with is how do we improve the security consideration sections across the W3C by using threat modeling. Like I think that was um to to my sense, Simone might put it differently, but it seemed like Simone came in with a vision that this is a way we can really up our game around security considerations. And so how do we do that for specifications and how would we start to do it so that all of our uh W3C publications or our our recommendations in in any case have um, a threat model that we can start doing this sort of work with.

Joe Andrieu: Um, so I can I want to introduce that real quick what we're doing. And then the goal is for every spec that's produced by the W3C to have a threat model at the heart of its security considerations. And we are just at the beginning of that. Um, and clearly none of the working groups are doing this yet. Uh, we're the first ones really to start pushing through it. We have a couple of other groups that have been doing some threat modeling. Um, the DC API has some good support for a threat model. So that's that's also been going hand in hand with this work. Um, and I see Yvon, so I'll let you chime in.

Ivan Herman: Yes. Sorry. Uh, so it's a question to what you just said that every W3C recommendation use this threat modeling, which is okay, but is it something that you want to apply sort of retrospectively? I mean, in very specific terms, do we have to redo the the security section of the VC model and uh, and the other spec that we have already published and worked with along these lines or or this is for future specs?

Joe Andrieu: So I think um uh I think it's not reasonable to go back to old specs that aren't being iterated. However, I think for like v1.1 um of the did spec, right, which is not a completely new spec. Um, but since the work group is active um, we're going to get we're going to put together uh, a threat model for it. And I think we should also do the same for VCs. Um, I haven't looked at the timing of the the VC workflow to understand where that might create bottlenecks. Um, mostly because I'm trying to get on the other side of the DID related bottlenecks that are threat modeling. Um, and I think it's it's understood by staff and certainly by Simone that there's going to be slippage here that um, you know, this goal of everyone doing it actually first requires us to have a process that's understandable and easy enough for volunteers to be willing to do it. So we still have some work to do before this is you know, standard operating procedure, but I think the goal is as we move forward, let's capture our concerns about security in the form of a threat

Ivan Herman: Okay.

Joe Andrieu: model. All right. Thank you.

Denken Chen: Yeah, last time when we talk about different possible confidence methods could be developed, we realized like um all of the possible possibility of being fraud uh is actually a risk risk assessment measurement. Um, on the other side, it's actually threat modeling. So that's why we decided to start a threat modeling in our confidence spec. Uh, it's really two ways, just the same thing, but two ways of looking at it. As we increase our confidence, the risk is decreasing. So uh, I think the confidence spec can be a great starting point for our working group to use that threat modeling methodology in our security considerations. And that's it.

Joe Andrieu: Cool. Danken, I really appreciate that because that and I'll I'll introduce what we're doing with did resolution, but we're sort of going through a similar pattern. Um, I'm doing the threat modeling for DID resolution. Um, and then I'll turn and look at the other other aspects of DIDS.

Joe Andrieu: Um, and those are probably separate threat models for so I think doing it for confidence method um and probably separate sections um and maybe even separate diagrams and I'll introduce how that might work um for the different methods themselves, like the biometric has different threats than uh the cryptographic um so it might be worth breaking those out um, so I want to anchor in the process the the the simple way that you think about it is um, that you you you paint a picture with a diagram. You capture threats um using that picture uh to ground your vocabulary and then you describe the responses um to those threats. And those responses might be um responses that the specification has um implemented or they may be responses that someone else might implement to address this this threat. Um, so it starts with a diagram and in this case we we put to I put together um this minimalist threat model for the web and I made an overly simple diagram and when I first did it, I said, hey, um, it's not that interesting if it's just a client and the brow and the server um, because I was struggling to think where are we mitigating the threats in that and so I introduced TLS um, which addresses one specific threat um, which is the HTTP it secures F4 this HTTP request in a particular way.

Joe Andrieu: And so this was designed to just be a minimalist way to to work through it. Um, but what's happening for did resolution? Um, I'll pull up my diagramming tool. Um, this is the current DID resolution diagram, but I then went and also said, hey, what if that's um a DID key resolver and everything's on one device. Um, this is one of the things that Marcus was exploring in the architecture section of DID resolution. And so this is my attempt to have, you know, the same vocabulary terms like these E1s and D1s and D6s, these are the same in both these diagrams, but this is a different configuration and then I also went and did it for BTCR2 um and so each of these diagrams represents a different profile of this system and you could talk about the threats differently for example, when you're dealing with did key, the the threat to your resolver being an error is really likely to be that you have a library that your resolver code maintainer um has compromised, right? You don't have a the read the resolve doesn't go over over the wire.

Joe Andrieu: So we're not going to a different device context, but we may have we may be using a library that could be compromised. And so, that sort of difference lets us talk about these different points of potential threats. And I think this is what we probably want to do here is that we will ultimately have a diagram that is the three-party model that is the heart of VCs and and eventually, you know, we'll have a threat model for VC data model itself. Um, but then confidence method can have, you know, its own uh set, its own profiling of that diagram, its own breakdown of threats. Render method is going to have different threats, right? Um, quite interestingly different threats, happening there. So, I think that's that's sort of this idea of a constellation of different threat models that focus on different aspects of the system and yet relate to each other. And one of the things that we did, this is perhaps a nod to your question Ivan, is that one of the things that we encourage um uh threat modelers in the W3C to do is identify dependency threats.

Joe Andrieu: And this is sort of a lightweight one um, because I I really what we don't want to do is put the burden on, in this case, right, this is a web threat model. The web depends on a whole bunch of stuff, BGP, DHCP, DNS, HTTP, right? So HTTPS is probably the most direct here, but um, all of them have a role to play in securing the system and so if you want to understand how DNS may affect um uh the web, then you should go read DNS, like this this spec isn't going to tell you all the the threats that you might find in DNS, but you can go over there. So this is a way that we can as we move forward, start pointing to different resources rather than imagine a monolithic threat model that's uh singularly going to pull everything in together. Um, Denken, did that cover sort of what you were curious to talk about with threat models?

Denken Chen: Uh, yes, uh, I think we will ultimately have similar diagram to describe um, different risk when people are using the confidence in our spec.

Denken Chen: For example, uh, you can use any DID all to increase your competence, but also be aware that the, for example, the pass key or the the DID key could be transferred into other devices or into others end, and those can be described in a threat modeling flow diagram, um, in my understanding. Yeah.

Joe Andrieu: That's right. It's absolutely right. Okay. Any other thoughts or comments on threat modeling? So, I I will take this. Um, Denken, I think you and I are agreed that let's start putting together a threat model for confidence method with the intention of bubbling that up and and collaborating like with the render method folks. I see Dimitri's on the call. Um, but I think we can put the stake in the ground and start putting some diagrams and start socializing that. Okay. And then the other item was this uh issue from Amir, which I will bring up and I'll drop the URL in. Um, do we, well, I guess one of the questions is, do we know this gentleman?

Joe Andrieu: Um, I don't think I do. Um,

Phil Archer: I think you joined as an IE very recently. Is that right?

Joe Andrieu: man.

Manu Sporny: uh, possibly Phil, I I think, yeah, I forget which which group he was eyeing on, um, I have met Amir, I have talked with him, um, he's out of uh, the Kashmir region, um, and so, yeah, I I I don't know what his IE status is in this group, though.

Ivan Herman: I think I think it has

Manu Sporny: um, awesome, thank

Brent Zundel: He is an invited expert to the verifiable credentials working group.

Ivan Herman: been

Manu Sporny: you

Joe Andrieu: Um, yes, the GitHub says he's a member, which maybe includes invited expert. So I think with regard to substantive contributions, we're cleared. Um, so this is an interest, I mean, it's a it's a long post and um, basically, I think he's proposing a new type of confidence method. Um, but I think we should get him on a call and just ask him to introduce it. I mean, there are I do have some challenges with this particular, it's a lot of JSON, and I don't necessarily know what that JSON means.

Joe Andrieu: Uh, security and privacy considerations is, you know, a bunch of JSON. So, uh, maybe if we can get a good introduction, then we can understand how we might move this towards something that could become a spec. But also, you know, we should be considering whether or not this is aligned with what we want to do. Um, but it seems, other than the fact that it feels a little monolithic, um, it seems like an honest effort to combine a bunch of different factors. I don't know if anyone else has other thoughts. Go ahead, Manny.

Manu Sporny: Yeah, a couple of thoughts. Um, Amir is um uh quite talented. Uh, he uses uh a lot I feel like he uses a lot of LLMs to generate a lot of stuff. So there's an enormous amount being produced and it takes a lot to wade through it. Um, and some of it is, you know, pretty like big ideas that require enormous effort and lots of R&D, and we don't have the time to do a lot of that stuff in this specific work, but we should absolutely hear him out.

Manu Sporny: He's got good ideas. He's very focused on kind of like postquantum uh, you know, schemes and postquantum security, zero knowledge proofs, um, some pretty cutting edge kind of, you know, ZKP stuff, uh, uh, he does have a, you know, background in computer science and mathematics, uh, so tends to, you know, uh, be be pretty focused on on those things. So, um, the the only concern I'd have is like this, this is enormous amounts of work, uh, and I think we were trying to get in, get out of the confidence method spec pretty quickly. Um, these are good examples of things that could be added to the confidence method after, you know, a couple of years of of developing, getting implementers, showing that there's market demand, you know, that sort of thing. So, uh, just noting that I I absolutely agree. We should bring him on a call, have him talk through it. Um, but I I think there's a there's a gap between kind of I think what he wants to do and how things typically work in in incubation and standards and things of that nature.

Manu Sporny: That's

Joe Andrieu: Thanks, man. Thank you. You want to speak to your comment there over

Ivan Herman: Yeah. So,

Joe Andrieu: chat?

Ivan Herman: um, this, I see that Benjamin put something like that into the the chat that I wanted to say that we never we should never forget that we are working in a JSON LD space. So when we add terms like that, when in large quantities like in this one, we are extending the vocabulary that we have and and you know very well that the vocabulary in the JSON LD has some methodology to be followed and has to be explained and defined, and this is all not done here. Um, and in general, we have to be careful about how we do that. Uh, so yeah, uh, uh, it, it's, it's a lot of things actually, it it goes in a more general sense, not only for confidence method, any extension that we do on what we already have would require a serious vocabulary work. So we have to be careful about what we do without before we we throw in yet another JSON terms.

Ivan Herman: Um, yeah, that's

Joe Andrieu: Cool. Thanks, Ivan.

Ivan Herman: it.

Joe Andrieu: Thank you mention breaking this framework into different parts.

Denken Chen: Yeah, as I go through this issue, I see it present a framework that uh describe different aspect of uh either risk or different framework that can be comparable. Uh for our confidence one, the most relevant part is that, for example, for the NIST AI does and ISO 29115, those uh assurance level stuff we have been addressing, and but there is also other stuff like zero knowledge proof, unlinkability stuff, and in our VC spec, we present different related spec to address those concerns. So it really didn't have such high level overview, um, and classifications into looking those kind of concerns. So, I was wondering, like, is it um should it be just an overview, and then we break things down into different parts of our VC spec or I mean, how to deal with this kind of framework? Yeah.

Joe Andrieu: Yeah, it's complicated. I'm just trying to make sense of what this J, how this JSON's going to be interpreted.

Joe Andrieu: Um, so I think that, you know, I think the right homework here is let's get Amir in and see if he can present a coherent narrative. Um, maybe there is one, and maybe there is a way to leverage pieces of this, or maybe this is a future confidence method of its own. Right? Confidence method is a point of extensibility. So, uh, we may not get to this in this uh round, but maybe it's a future round. I'm not sure yet because it's still just hard to understand really, you know, I don't know what this anti-tracking means. Uh, I just see some some values here. Um, so how do we, do we know this guy's email? Oh, I shouldn't leave. I don't have an how how might I get an email for this

Manu Sporny: Sorry.

Joe Andrieu: W3C?

Manu Sporny: Sorry, Joe. I've got an email for him.

Joe Andrieu: How you do?

Manu Sporny: I'll uh send it

Joe Andrieu: Okay,

Manu Sporny: on.

Joe Andrieu: cool. So, if you send that to me, I'll I'll reach out to him.

Joe Andrieu: CC Denken and see if we can uh get him to come and talk to

Manu Sporny: Okay.

Joe Andrieu: us.

Manu Sporny: He's posted on the CCG mailing list. Uh, you could probably pull it from there as well.

Ivan Herman: I I've put the uh W3C account on the

Joe Andrieu: Okay.

Ivan Herman: chat. It gives the various data that he published for us.

Manu Sporny: Only team can read that link.

Ivan Herman: Oh, I'm sorry.

Manu Sporny: Avon

Ivan Herman: Is that correct?

Joe Andrieu: Uh, but Phil Phil did drop a an email in there. Thanks, Phil. I'm just going to get that out of this context. So, I I think that's it. Denken, um, uh, we're pretty much out of time. Was there anything else you wanted to go over?

Denken Chen: Yeah, it's great conversation today. I think that's it.

Joe Andrieu: Okay, excellent. Anyone else last thoughts? Otherwise, I think we're wrapped for the day. All right, thank you everyone. Um, are we on in two weeks? Is that our next rhythm? I guess that's or do we have the the VCWG in the

Phil Archer: Uh hang on. Yeah,

Joe Andrieu: way?

Phil Archer: I've already got a BCWG in the way in two weeks time. Um, and because it's a so yeah, it's it's um random methods next week, and then full working group, and then you'll be back on on the 18th.

Holder Binding Terminology

Denken Chen: Yes. Uh, for the holder binding things, I know that uh, there are folks concerning about using the word binding, and that's why we move away from using the word binding, uh, but use confidence instead. And uh, my point has been always that the holder binding terms has been used elsewhere, particularly in the EU in the Europe UDI, UD wallet, their architecture framework, and I think it's a good thing for us to clarify clearly about our thoughts about how confidence can be increased through different mechanisms that we will define

Denken Chen: in our confidence spec, uh, but just include like there are some somewhere else using a turn holder binding, uh, but here's how we think to improve the confidence in the beginning of the paragraphs, uh, let's my focus on this, okay? So first, I think T is the first one preset. Go

Ted Thibodeau Jr: Um, so holder binding was never an accurate term in any sense. We we never have had a way to enforce that only this entity or these entities are allowed to hold this spec or present it. It it's it's just never been a thing. So the folks who brought that terminology to other specification bodies never brought a useful thing. It was never something that we defined, never something that we made functional, never useful. Um, I'm afraid that confidence method is doing a similar disservice to people trying to use it. Now, confidence in what are you applying this method in order to increase your confidence? Um, I think what is trying to happen or trying to be made happen is authorized holder or authorized presenter, which is more accurate because anybody can hold this sequence of bytes.

Joe Andrieu: Okay, I'll go ahead and go. Um, I agree that uh, the term holder binding was never an accurate term.

Manu Sporny: Yeah, plus one to uh those uh uh modifications, Joe. Uh, so again, plus one to what Ted said. Uh, holder binding was never a good term. We told people that fairly early on. People did not heed the warnings and now we're in a position where we should probably say something uh more a little more strong in the specification. We can do that in the terminology section uh of the specification as option one. Option two is to put it down in the security consideration section to very clearly let people know that holder binding is not a thing. Like it is not it is not something that you can you can um uh do uh due to uh proxying and and other things of that nature, right? Um, you can never bind something uh to a holder. Uh, okay. So, so that's, you know, item one. Um, item two is I agree with Joe's uh uh modulations to what you were saying, Ted.

Denken Chen: Um, but there's also another word, device binding using in their spec. So, there are three things, there are holder binding, there are user binding, there are device binding, which I think uh device binding could be the only reasonable way. For example, in our first goal of this spec, we are going to include the O and the facial image. So for the O, it's similar to device binding, it's binding to a cryptography material. And for facial image, it's related to user, but it's not binding to user, right? You can like using face recognition to improve the confidence, like the holder, the presenter is the holder or the subject, etc. So, we can make it really, really clear of these terms in our spec, um, that will really help for anywhere in the world implementing digital identity. Um, in our case, uh, during our internal discussion, we talk about this a lot. Uh, how do we ensure the presenter is the subject or can we really do that? Is is it really technically doable? We can describe it really clearly in our spec, and that's my initial motivation for this spec.

Confidence Method Scope

Joe Andrieu: And so I think the the point of having a section on holder binding, which may not be a top level section, um, but to explain why we aren't using that term and why confidence method is a different way to think about it. Um, I I think you're close Ted with your thinking about what the semantics mean. However, I think it goes a little bit further with confidence method in that you don't have to be presenting. I could have a, for example, a verifiable credential for a marriage certificate that has the officient, two spouses, and two witnesses. And it it may be that this was submitted at some point to a school to establish parentage or something like that, however these are used in civic society. And then later someone else says, "Hey, this was the officient at this wedding. I want to go find I I want to verify that that person is the person I think they are and I can use this confidence method that may have been included for the officient so that in a separate ceremony that is not necessarily the presentation of that VC, we could increase our confidence that the person we're talking to in real time is that person who was in the VC that we got two years ago.

Manu Sporny: Uh, I don't think it's about presentation. It is about raising confidence in a subject and it does not have to happen at the time of presentation. It can happen at at some uh other time. Um, so I do think that there's work to be done there. Um, uh, and just acknowledging, uh, that that's it.

Ted Thibodeau Jr: So just to clarify um, not necessarily in confidence in the identity of the presenter, but it it's a method of increasing confidence in something. It could be any of the attributes spelled out in the VC. Um, in Joe's example, it it would be confidence in the identity of the officient and the method used to increase confidence of the identity of the officient. But it's still not about the subject nor any holder nor right that there it's not generically increased confidence. It is explicitly increased confidence in something, and I think in that sense, it could be applied to anything within the VC. I, as an issuer, have increased confidence in my stating that this is the subject of my DC.

Joe Andrieu: Um, we're talking about confidence in the subject. Confidence in the predicate or confidence in the object is something actually that would be very hard for us to express.

Joe Andrieu: Um, maybe RDF star could let us start to do that kind of thing. But the way the architecture works, we have an ID and we have a confidence method. And what we're saying is something about that subject. And so the the the pattern that we're talking about is is the subject of this VC the same entity in some other context. And it may be that there's a there's a signature on something that's posted to a public record. It could be an interactive session with someone um after the fact. But what you're trying to do is say, oh, the subject in this VC, that's this other person in this other context. And I think it's not about the rest of the claims or the rest of the components of the claims, just about tying the subject, um, correlating them from one context to another. The first context being the VC, the other context being wherever else that confidence method happens to be exercised.

Phil Archer: This discussion for me highlights the um problem I have is that the in my head, there is a blurring between what we're talking about here and the completely separate um work being done on verified issuers.

Brent Zundel: Um, while I think it could be useful to allow confidence methods to help the verifier to obtain confidence in any of the attributes of a credential, I fear that expanding the scope to that extent will make producing this specification difficult if not impossible. And so limiting the scope to confidence in some relationship between the presenter and the subject would probably be a good idea. However, if the group wants to go in that other direction, I'm not going to, you know, stand in the way of that. It's just this is a concern I've brought up in the past. I still have the concern and wanted to voice it again. Now, all of this said completely, chair hat off.

Joe Andrieu: So twisting the confidence method so that it could apply to another predicate or an object, um, is the kind of exercise that RDF star is about. Like it is it is a a weird and hard thing to try and do. Um, but I do want to acknowledge Ted, I think I think we have been on different senses of what this is. you've never understood like why we're trying to do this thing. And I agree that how you're thinking about it is not how we should do it because that that would not make sense. But I also think you're you're um, you're thinking more about assurance that an issuer might do before issuing a credential, which is different than what a verifier is going to do to increase their confidence. So to to be very explicit to your question, it is the verifier who is increasing their confidence that the subject of some context is the subject of the VC. That's what we're increasing confidence about. And I I think it's a very closed form statement. And the point is the issuer is providing a hint for the verifier that hey, this is a way you can increase your confidence.

Manu Sporny: I think I think we're uh I think there's just a miscommunication because the thing that you said made made sense to you, Ted, is my understanding of what we're actually doing. And I'm seeing a lot in the chat of like other people agreeing like we're doing the same thing. We're not doing the insane thing, right? So there's a miscommunication here. I'm just trying to figure out how we can solve that. What you said, uh Ted, confidence that dog A is the dog in front of me. Yes, I think that's what we're trying to do and and that's it. Like uh and plus one to what Brent said, none of us want to see the spiral into blood tests and DNA analysis and that kind of thing. Like let's just let's just do like, you know, cryptographic key, you know, mechanism and then if that's all we get done, then that's fine.

Ted Thibodeau Jr: No, I'll keep reading and I'll keep conversing and hopefully we'll get closer to it. But the if this thing has a specific purpose and is only for the specific purpose, then the generic label confidence method is not useful in my opinion. And I'll leave it at that for now.

Threat Modeling Introduction

Joe Andrieu: Ah. Oh, wait. I see Dimitri and Phil. So, uh, let's talk about this, Dan. This is I was trying to avoid it because I wanted to get spec text. Um, there's we've had conversations about um assurance levels um and the possibility that maybe that's evidence and we adjusted the charter um so that this deliverable isn't just about confidence method. We specifically opened it up so that it could address what might be a redefinition of evidence or to to my current thinking, and I'll let Dan chime in. I think we were on the same page about it that rather than redefine evidence, which is a uh VC level property, not a subject level property. Um, maybe what we should do is just create an assurance method, which is um a different way for the well, it is a way for the issuer to describe what assurance level they achieved and the kinds of things that would go in there are NIST IAL3 or EID medium, um that they achieved some regulatory standard and we'll have a vocabulary for the ones that that we know about and recognize and it could be extensible to do other assurance uh methods.

Joe Andrieu: And the idea there is that's sort of the other half Ted that I think you were talking about a little bit, that, you know, having the issuer explain what their assurances were um is part of this conversation, but a little bit different than what you would tell the verifier because if if an issuer tells me they did I3, um, that doesn't give the the verifier any way to do anything except just, oh, thank you, I appreciate that you did that. That doesn't give them like a, a key or biometric or some other way to do a secondary act that would increase confidence. Um, so I see Phil's on the

Joe Andrieu: Um, so I want to start by introducing the let me get the right resource. Um, I have been working with Simone, the security lead for the W3C. He's staff and um, and uh, through the security interest group to develop this threat modeling guide that I'm sharing on screen and I'll drop the URL in. And the the goal that Simone and I have been trying to figure out how we deal with is how do we improve the security consideration sections across the W3C by using threat modeling. Like I think that was um to to my sense, Simone might put it differently, but it seemed like Simone came in with a vision that this is a way we can really up our game around security considerations. And so how do we do that for specifications and how would we start to do it so that all of our uh W3C publications or our our recommendations in in any case have um, a threat model that we can start doing this sort of work with.

Joe Andrieu: Um, so I can I want to introduce that real quick what we're doing. And then the goal is for every spec that's produced by the W3C to have a threat model at the heart of its security considerations. And we are just at the beginning of that. Um, and clearly none of the working groups are doing this yet. Uh, we're the first ones really to start pushing through it. We have a couple of other groups that have been doing some threat modeling. Um, the DC API has some good support for a threat model. So that's that's also been going hand in hand with this work. Um, and I see Yvon, so I'll let you chime in.

Joe Andrieu: So I think um uh I think it's not reasonable to go back to old specs that aren't being iterated. However, I think for like v1.1 um of the did spec, right, which is not a completely new spec. Um, but since the work group is active um, we're going to get we're going to put together uh, a threat model for it. And I think we should also do the same for VCs. Um, I haven't looked at the timing of the the VC workflow to understand where that might create bottlenecks. Um, mostly because I'm trying to get on the other side of the DID related bottlenecks that are threat modeling. Um, and I think it's it's understood by staff and certainly by Simone that there's going to be slippage here that um, you know, this goal of everyone doing it actually first requires us to have a process that's understandable and easy enough for volunteers to be willing to do it. So we still have some work to do before this is you know, standard operating procedure, but I think the goal is as we move forward, let's capture our concerns about security in the form of a threat

Denken Chen: Yeah, last time when we talk about different possible confidence methods could be developed, we realized like um all of the possible possibility of being fraud uh is actually a risk risk assessment measurement. Um, on the other side, it's actually threat modeling. So that's why we decided to start a threat modeling in our confidence spec. Uh, it's really two ways, just the same thing, but two ways of looking at it. As we increase our confidence, the risk is decreasing. So uh, I think the confidence spec can be a great starting point for our working group to use that threat modeling methodology in our security considerations. And that's it.

Joe Andrieu: Cool. Danken, I really appreciate that because that and I'll I'll introduce what we're doing with did resolution, but we're sort of going through a similar pattern. Um, I'm doing the threat modeling for DID resolution. Um, and then I'll turn and look at the other other aspects of DIDS.

Joe Andrieu: Um, and those are probably separate threat models for so I think doing it for confidence method um and probably separate sections um and maybe even separate diagrams and I'll introduce how that might work um for the different methods themselves, like the biometric has different threats than uh the cryptographic um so it might be worth breaking those out um, so I want to anchor in the process the the the simple way that you think about it is um, that you you you paint a picture with a diagram. You capture threats um using that picture uh to ground your vocabulary and then you describe the responses um to those threats. And those responses might be um responses that the specification has um implemented or they may be responses that someone else might implement to address this this threat. Um, so it starts with a diagram and in this case we we put to I put together um this minimalist threat model for the web and I made an overly simple diagram and when I first did it, I said, hey, um, it's not that interesting if it's just a client and the brow and the server um, because I was struggling to think where are we mitigating the threats in that and so I introduced TLS um, which addresses one specific threat um, which is the HTTP it secures F4 this HTTP request in a particular way.

Joe Andrieu: And so this was designed to just be a minimalist way to to work through it. Um, but what's happening for did resolution? Um, I'll pull up my diagramming tool. Um, this is the current DID resolution diagram, but I then went and also said, hey, what if that's um a DID key resolver and everything's on one device. Um, this is one of the things that Marcus was exploring in the architecture section of DID resolution. And so this is my attempt to have, you know, the same vocabulary terms like these E1s and D1s and D6s, these are the same in both these diagrams, but this is a different configuration and then I also went and did it for BTCR2 um and so each of these diagrams represents a different profile of this system and you could talk about the threats differently for example, when you're dealing with did key, the the threat to your resolver being an error is really likely to be that you have a library that your resolver code maintainer um has compromised, right? You don't have a the read the resolve doesn't go over over the wire.

Joe Andrieu: So we're not going to a different device context, but we may have we may be using a library that could be compromised. And so, that sort of difference lets us talk about these different points of potential threats. And I think this is what we probably want to do here is that we will ultimately have a diagram that is the three-party model that is the heart of VCs and and eventually, you know, we'll have a threat model for VC data model itself. Um, but then confidence method can have, you know, its own uh set, its own profiling of that diagram, its own breakdown of threats. Render method is going to have different threats, right? Um, quite interestingly different threats, happening there. So, I think that's that's sort of this idea of a constellation of different threat models that focus on different aspects of the system and yet relate to each other. And one of the things that we did, this is perhaps a nod to your question Ivonne, is that one of the things that we encourage um uh threat modelers in the W3C to do is identify dependency threats.

Joe Andrieu: And this is sort of a lightweight one um, because I I really what we don't want to do is put the burden on, in this case, right, this is a web threat model. The web depends on a whole bunch of stuff, BGP, DHCP, DNS, HTTP, right? So HTTPS is probably the most direct here, but um, all of them have a role to play in securing the system and so if you want to understand how DNS may affect um uh the web, then you should go read DNS, like this this spec isn't going to tell you all the the threats that you might find in DNS, but you can go over there. So this is a way that we can as we move forward, start pointing to different resources rather than imagine a monolithic threat model that's uh singularly going to pull everything in together. Um, Denken, did that cover sort of what you were curious to talk about with threat models?

Denken Chen: Uh, yes, uh, I think we will ultimately have similar diagram to describe um, different risk when people are using the confidence in our spec.

Denken Chen: For example, uh, you can use any DID all to increase your competence, but also be aware that the, for example, the pass key or the the DID key could be transferred into other devices or into others end, and those can be described in a threat modeling flow diagram, um, in my understanding. Yeah.

Amir's Proposed Method

Joe Andrieu: Um, I don't think I do. Um,

Phil Archer: I think you joined as an IE very recently. Is that right?

Manu Sporny: uh, possibly Phil, I I think, yeah, I forget which which group he was eyeing on, um, I have met Amir, I have talked with him, um, he's out of uh, the Kashmir region, um, and so, yeah, I I I don't know what his IE status is in this group, though.

Brent Zundel: He is an invited expert to the verifiable credentials working group.

Joe Andrieu: Um, yes, the GitHub says he's a member, which maybe includes invited expert. So I think with regard to substantive contributions, we're cleared. Um, so this is an interest, I mean, it's a it's a long post and um, basically, I think he's proposing a new type of confidence method. Um, but I think we should get him on a call and just ask him to introduce it. I mean, there are I do have some challenges with this particular, it's a lot of JSON, and I don't necessarily know what that JSON means.

Joe Andrieu: Uh, security and privacy considerations is, you know, a bunch of JSON. So, uh, maybe if we can get a good introduction, then we can understand how we might move this towards something that could become a spec. But also, you know, we should be considering whether or not this is aligned with what we want to do. Um, but it seems, other than the fact that it feels a little monolithic, um, it seems like an honest effort to combine a bunch of different factors. I don't know if anyone else has other thoughts. Go ahead, Manny.

Manu Sporny: Yeah, a couple of thoughts. Um, Amir is um uh quite talented. Uh, he uses uh a lot I feel like he uses a lot of LLMs to generate a lot of stuff. So there's an enormous amount being produced and it takes a lot to wade through it. Um, and some of it is, you know, pretty like big ideas that require enormous effort and lots of R&D, and we don't have the time to do a lot of that stuff in this specific work, but we should absolutely hear him out.

Manu Sporny: He's got good ideas. He's very focused on kind of like postquantum uh, you know, schemes and postquantum security, zero knowledge proofs, um, some pretty cutting edge kind of, you know, ZKP stuff, uh, uh, he does have a, you know, background in computer science and mathematics, uh, so tends to, you know, uh, be be pretty focused on on those things. So, um, the the only concern I'd have is like this, this is enormous amounts of work, uh, and I think we were trying to get in, get out of the confidence method spec pretty quickly. Um, these are good examples of things that could be added to the confidence method after, you know, a couple of years of of developing, getting implementers, showing that there's market demand, you know, that sort of thing. So, uh, just noting that I I absolutely agree. We should bring him on a call, have him talk through it. Um, but I I think there's a there's a gap between kind of I think what he wants to do and how things typically work in in incubation and standards and things of that nature.

Ivan Herman: um, this, I see that Benjamin put something like that into the the chat that I wanted to say that we never we should never forget that we are working in a JSON LD space. So when we add terms like that, when in large quantities like in this one, we are extending the vocabulary that we have and and you know very well that the vocabulary in the JSON LD has some methodology to be followed and has to be explained and defined, and this is all not done here. Um, and in general, we have to be careful about how we do that. Uh, so yeah, uh, uh, it, it's, it's a lot of things actually, it it goes in a more general sense, not only for confidence method, any extension that we do on what we already have would require a serious vocabulary work. So we have to be careful about what we do without before we we throw in yet another JSON terms.

Denken Chen: Yeah, as I go through this issue, I see it present a framework that uh describe different aspect of uh either risk or different framework that can be comparable. Uh for our confidence one, the most relevant part is that, for example, for the NIST AI does and ISO 29115, those uh assurance level stuff we have been addressing, and but there is also other stuff like zero knowledge proof, unlinkability stuff, and in our VC spec, we present different related spec to address those concerns. So it really didn't have such high level overview, um, and classifications into looking those kind of concerns. So, I was wondering, like, is it um should it be just an overview, and then we break things down into different parts of our VC spec or I mean, how to deal with this kind of framework? Yeah.

Joe Andrieu: Yeah, it's complicated. I'm just trying to make sense of what this J, how this JSON's going to be interpreted.

Joe Andrieu: Um, so I think that, you know, I think the right homework here is let's get Amir in and see if he can present a coherent narrative. Um, maybe there is one, and maybe there is a way to leverage pieces of this, or maybe this is a future confidence method of its own. Right? Confidence method is a point of extensibility. So, uh, we may not get to this in this uh round, but maybe it's a future round. I'm not sure yet because it's still just hard to understand really, you know, I don't know what this anti-tracking means. Uh, I just see some some values here. Um, so how do we, do we know this guy's email? Oh, I shouldn't leave. I don't have an how how might I get an email for this

Manu Sporny: I'll uh send it

Joe Andrieu: Okay,

Manu Sporny: on.