Meeting minutes
VC Barcodes and Data Integrity Meeting
Wesley_Smith: Good morning, I'll give it a couple more minutes for people to trickle in and then we'll get started.
Wesley_Smith: All Good morning everyone. Welcome to the May 19th meeting of the VC barcodes and data integrity task force. A reminder to everyone that this meeting is being recorded and transcribed. if you are not comfortable with that, please let me know. The agenda today is similar to normal. we'll quickly talk about any process items, introductions or announcements folks have and then we'll split about half the remaining time between VC barcodes and data integrity respectively.
Wesley_Smith: Today instead of focusing on the normal PR review and issue processing, I hope to talk a little bit about threat modeling and get started with some group threat modeling brainstorming for the VC barcodes work. excuse me. And then in the second half of the call Greg Bernstein, do you want to speak briefly on what you want to talk about?
Greg_Bernstein: I was going to go over u selective disclosure for postquantum a little bit of BBS status and anything else people want to discuss.
Proposing Document As First Public Working Draft
Wesley_Smith: All right, that sounds good. with that in mind, does anybody have any process items they would like to discuss? Anybody like to introduce themselves to the group or does anybody have any announcements they'd like to make? Avon, go ahead.
Ivan_Herman: That's for the quantum thing and not for the barcode. we may want to discuss whether we want to propose the document as a first public working draft just to put a stake in the ground that we do that.
Ivan_Herman: But that's for Greg.
Greg_Bernstein: Okay. Yes,…
Wesley_Smith: Great. No,…
Greg_Bernstein: I definitely want to understand that process and yes, I would like to put a stake in the ground because especially with the essence when we get to our portion we'll discuss it.
Wesley_Smith: no, it's fine to discuss now, Craig.
Greg_Bernstein: We have some selective disclosure stuff By putting a stake in the ground, we can get folks to implement and try things out and get feedback. this was a thing that I was particularly wanted to get to because sometimes people won't implement until you have something that's at least merged and…
Greg_Bernstein: somewhat stable. And so that sounds like a really good thing to me because Ivonne
Ivan_Herman: Yeah, I think it's a little bit more than that,…
Ivan_Herman: I mean what you say is obviously true but by doing a first public working draft process-wise that means that the document becomes an official W3C publication as a draft and there are two things which happens. one that might be of importance in this case that all the IPR related processes start at that point and that might be good to have it behind us but more importantly is that it sends a message to the outside world that the working deals with this.
Greg_Bernstein: Yeah. yeah. Okay. Okay.
Greg_Bernstein: No, that's Yeah.
Ivan_Herman: So far in the charter it's possible we will do that…
Ivan_Herman: but we haven't committed yet and what we say by publishing is a draft yes we are committed to do that and…
Ivan_Herman: with all the hooplas around quantum computing I think that's an important message. Okay.
Greg_Bernstein: Yeah, I also think the draft is quite stable and…
Greg_Bernstein: technically sound too personally because a lot of it is reusing the frameworks that we've established with our other crypto suites and NISTs. intended these to be somewhat drop in replacements if not as efficient as what we already have. So the APIs that were calling into look a lot like what we were calling into our classical crypto suite. So yeah, I don't think we need to delay any longer.
Greg_Bernstein: So, we'll do whatever we need to do to get that together because it seemed like it took a lot more importance of late. And so, I've got test vectors for everything and only there's just, two PRs that are need to go through and…
Greg_Bernstein: then we can see what else I might be missing in there. We may be missing. Sounds good.
Wesley_Smith: Sounds good.
VC Barcodes Threat Modeling Brainstorming
Wesley_Smith: Thanks folks. that is exciting progress as well. All right. Anybody else have any other process announcement or introduction related items? Okay, hearing nothing, let us go ahead and let us go ahead and start the VC barcodes threat modeling brainstorming that I'm hoping to get into. So, here I'm going to drop a link to a Google doc in the chat.
Wesley_Smith: go ahead and let me know if that is inaccessible to anyone for any reason. What currently it's an empty template for threat modeling for VC barcodes. Specifically, I would like folks to go to section four which is threat brainstorming and I'd like us to get some ideas down on paper today as a group. now this is obviously first stage fairly informal that sort of thing. We just want to get ideas and content down in a rough form that we can go back and polish later. so this threat brainstorm section is broken down into sort of categories.
Wesley_Smith: target threats, what it does the system does address, implementation threats, things that implementers need to do, external threats, out of scope, dependency threats, things that you inherit. so I would like to hear what you guys think the best way to go about filling this out right now is if we want to just all put in words and type words and then talk about them afterwards. If we want to go item by item, Kevin, go ahead. That sounds good to me.
<Wesley_Smith> VC Barcodes Threat Model Brainstorming - Google Docs
Kevin_Dean: Yeah, I think it would be better if we just had a list at the end that we could add to we could work as a group to categorize them as target implementation external or dependency. Yeah. Yeah.
Wesley_Smith: And that gives us a nice list to work through as a group and discuss item by item as well. All right, let's go ahead and do that then. I expect I'm typing the word duplicability as a threat, but I expect we'll also have duplicates and the process you described will be a good way to get rid of them.
Wesley_Smith: I'm seeing the pace of addition slowed down a little bit, which is We already have, 10 good items to talk about. anybody still going or should we go through what we have now and categorize and then maybe go back to brainstorming. Great.
Dave Longley: I think we should categorize what we have right now because some of them might even break out into more than one threat if we talk about them.
Quishing Presentation Of A Barcode
Wesley_Smith: and some might break out into less than one threat if there are very related ones. great. Let's go ahead and do that. First one we have quishing presentation of a barcode were expected but one that is intended to hijack the interaction. Kevin, do you want to speak to this?
Kevin_Dean: Yeah. fairly common well-known problem that when it's most often in situations where somebody is presented with a barcode maybe to a movie trailer or to some product website, but the barcode itself has been replaced. the barcode is redirects the user to a different website. we could face the same issue with a VC presentation in a barcode. It could have content that is intended to hijack the interaction in some fashion. it could have a different set of signatures, make different claims than are intended.
Kevin_Dean: But basically the system that is receiving the barcode is getting one that is not valid for that interaction.
Kevin_Dean: And it may be because the u users the presenter's device has somehow been compromised to present something different.
Wesley_Smith: Yeah, that's a great point.
Wesley_Smith: So to my mind that sounds like you could argue a couple of categories for this. Either it could be a dependency threat in that and the external technology is the medium by which somebody reads these barcode bytes that may or may not be malicious and there's a vulnerability there or it could be an external threat just sort of generally out of scope. If you're sharing data with a third party you can craft that data to be malicious if you want. What would you say?
Kevin_Dean: Yeah, I think I
Kevin_Dean: Those are good examples and that spam call coming in there.
Wesley_Smith: No worries.
Kevin_Dean: Yeah well timed I think but yeah I think that those are good categorizations.
Kevin_Dean: There obviously we'd have to go through in detail to think of different ways that these can get into the interaction and ways to detect them and mitigate them.
Wesley_Smith: So I'm going to put that in dependency threats and…
Wesley_Smith: I'm going to say that there are a couple of at which there are a couple of layers that can be attacked in that way. So external technologies tapped in this way, barcode scanners, JSON LD processors, HTTP clients.
Wesley_Smith: Anything else that's used in the stack for consuming a VCB that could be subject to a maliciously crafted barcode payload?
Wesley_Smith: Go ahead, Dave Longley.
Dave Longley: did and…
Dave Longley: I have a second point too that first does JSON LD processors cover core LD processors…
Dave Longley: because that's in the stack.
Wesley_Smith: It does now.
Dave Longley: Okay and the other point I want to make is down here what is currently listed under number five we have mismatch of information on physical documents with VCB that seems like it's sort of a category that encapsulates this that mismatch of information could be intentional or it could be for example an implementation threat because it's a mistake so your implementation could put the wrong …
Dave Longley: barcode onto a physical document by accident as opposed to doing it on purpose.
Wesley_Smith: I understood all the individual words you said,…
Wesley_Smith: but I lost the point you were making.
Dave Longley: I'm just seeing, one of the reasons we're going down the list right now of things we've been brainstorming where is there overlap and is it the case that there's a general category of mismatched document to barcode where one of the sub items for that that makes this a dependency threat would be the quishing example…
Dave Longley: where there's an intent you intentionally mismatch the Bark barcode whereas the mismatch of information with the bar on the document with the barcode could also be listed as a threat in other places. Should we consider quishing to be it's an entirely separate category or entirely different threat or is it just a subthread of mismatched information between barcode and document?
Wesley_Smith: Yeah, heard and…
Wesley_Smith: understood. I think the way that this threat brainstorm, which I don't think we're married to, but the way that it's currently laid out, this section is it doesn't seem like quishing should be its own category as listed here.
Wesley_Smith: It doesn't see none of these other categories are about the mechanism of attack so much as they are about they kind of are h I would love other people's feedback here because I could see leaving the structure as we have it and I could also see adding a new category. I lean towards leaving the structure as we have it and…
Wesley_Smith: dealing with the fact that lots of these attacks look more or less the same by, having the wrong barcode in some sense. Philip, go ahead.
Phillip Long: Yeah. What I'm taking from Dave's comment,…
Phillip Long: and Dave, you can clarify if I'm misunderstanding, but I think the difference that we're talking about here is where there are intentional threats who are doing something with the intent of defrauding or otherwise corrupting the system and attemp and threats that are threats but simply…
Phillip Long: because an error was made in the issuings in the processing in some fashion not malicious intended at all and I'm not sure how to represent that but I think that's the underlying idea
Wesley_Smith: Yeah, that's a great point and…
Wesley_Smith: In that framing I think we don't need to do anything to the current structure because these inadvertent mistakes type things sounds exactly like implementation threats implementers must handle what that category is designed for. So if you put the wrong barcode on a document you X follows. thoughts
Phillip Long: As a quick response, I do think there is a difference in so far as the way in which one corrects reacts to it because in the case of an inadvertent one, it's one of finding the error and fixing it and you're done. if it's one that's intentional it's unlikely to be internal or rather it's more likely to be external than internal I think and the mechanism by which you go about fixing it is it seems to me is different but I may be mistaking
Wesley_Smith: No, I think you're right. yeah. No, I think we're on the same page. I posit that we do not need to change the structure of this document to have it play nicely with the points that Philip and Dave Longley are making. Does anybody disagree with that? Is that I disagree with that or a thumbs up.
Dave Longley: No, it's Yeah. let's not battle the document.
Wesley_Smith: Sounds good.
Dave Longley: Let's just make progress.
Wesley_Smith: That sounds good. All right.
Wesley_Smith: So currently under quishing external technologies are attacked this way or could be barcode scanners, JSLD and CLD processors and HTTP clients. can anybody think of any other sort of attack vectors processors that might be attacked by a micious maliciously crafted VCB in some way. Maybe cryptographic hardwaresoftware.
Wesley_Smith: Although it would have to be some pretty squishy and questionably architected cryptographic hardware to be attacked by malicious. All right.
Dave Longley: I just want to comment I'm struggling a little bit as thinking about those technologies being attacked. it does not seem to me like you're attacking those technologies in this case at all. I mean you could easily have a barcode that is totally legitimate that you intentionally put in the wrong place. are those technologies being attacked or is it really you're attacking some validation layer of software that's checking for something? you're attacking a user interface that might confuse a user when it should have flagged something to the user or…
Wesley_Smith: So my sorry sorry my understanding is that the other subset of the kind of intentionally wrong barcode attacks that we're talking about are not being covered in this current bullet point that's covered under the uncatategorized number five mismatch of information on physical documents with VCB What… Dave Longley:
Dave Longley: made it clear. Good.
<Phillip Long> Is there a generic linked data threat grouping?
Wesley_Smith: how I'm thinking about this quishing point that we're currently describing is little Bobby drop tables kind of thing right is there a way to craft a barcode such that it will cause a barcode scanner throw an error is there a way to craft
Dave Longley: I think that's certainly the attack you would probably reach for first,…
Dave Longley: but that does not preclude doing something clever. I mean, I guess we have to have a different threat then for it's still an intentional attack, but you're putting the wrong barcode somewhere.
Wesley_Smith: Yes. Yeah.
Dave Longley: You could Okay.
Information Leakage Via Video
Wesley_Smith: Absolutely agree that that is not covered by what we're talking about and does need to be in the threat All next up we have information leakage via video. I wrote this one. I did not put much explanation there. basically presentation of these credentials leaks information in ways that presentation of digital credentials usually does not. For example, a highresolution security camera might capture in its entirety your verifiable credential barcode if you pull out your driver's license at a gas station, right?
Wesley_Smith: So that is not a target threat. It is not an implementation threat. It is presumably an external threat. unless we want to argue that that is a limitation inherited by a barcode, but I don't really think that that's true.
Dave Longley: Yeah. And can we change via video to be some external medium example video? I mean, it doesn't have to be video. Someone could take a picture. What do any number of It's an optical barcode in this case. So anything that can capture
Phillip Long: That may also then allow you to fold in the biometric falsification images. I'm not sure if that is exactly the same thing.
Dave Longley: It might be. Yeah, I think that's different because in this case we're worried about someone recording or…
Phillip Long: Inadvertent.
Dave Longley: seeing the barcode and the biometric. I mean, we don't have to dive into that one, but maybe we'll do that one next.
Dave Longley: That one seems I think it's also an external threat, but a different
Phillip Long: Right. But different.
Phillip Long: Yeah, that was the one I put in. So that's why I was raising it.
Wesley_Smith: All right.
Wesley_Smith: We'll go to that one next. anybody have anything to add about this what we're calling physical medium information leakage notion.
Phillip Long: I was just thinking of AI image generation that's being used to capture and then somebody else's this image and represent it in a different credential for example.
Wesley_Smith: You're talking about the biometric falsification.
Phillip Long: That's right. That's right.
Wesley_Smith: We'll get to that one. We'll do that one immediately after this one.
Phillip Long: Very Very good. Sorry, I thought you would move.
Biometric Falsification Threat
Wesley_Smith: It's all good. Anybody have anything else they want to add to the physical medium of information leakage? the security camera at the gas station steals your VCB. Whatever. All right, Philip, let's go ahead and talk about your biometric falsification notion. I know you just gave a brief summary, but can you do it again? Philip, you're muted if you're talking.
Phillip Long: I was indeed incredibly insightful, but I'll repeat it. the biometric falsification is just a recognition of the extent to which AI tools can represent facial images that are apparently extremely analogous to direct capture of and sand, something that signs the image when it's captured, could be used to represent falsely data for some other purpose as a barcode u conveyed credential.
Wesley_Smith: Dave Longley.
Wesley_Smith: Go ahead.
Dave Longley: And I would widen it beyond AI.
Dave Longley: There are twins and…
Phillip Long: I Fair enough.
Dave Longley: people that look like each other. there are variety of other things that people might do.
Dave Longley: They might do something clever that did not require AI. plus one to that threat and…
Dave Longley: talking about those possible vectors for the threat.
Wesley_Smith: Ivon, go ahead.
Ivan_Herman: Much as this is interesting,…
Ivan_Herman: is it really related to the barcode spec? I mean for me this is more a threat to the confidence method which wants to use biometric things.
Ivan_Herman: It's not relevant to the barcode.
Dave Longley: So true.
Dave Longley: Part of this threat modeling is identifying external threats which are things that are out of scope. but of course that's not meant to be everything you can think of in the universe that has out of scope. it is the case that there certainly is sometimes some biometric thing that is put into a barcode. And for that reason it seems important to talk about it here in this spec.
Dave Longley: But say there might be components of it that are out of scope.
Wesley_Smith: Yeah, I would argue that this is a pretty clear example of a dependency threat,…
Wesley_Smith: something inherited from a external technology. There's nothing preventing you putting a biometric of some clonable form into a VC barcode. And if you do, then you have to deal with this thread. to me it seems just like talking about how cryptographically relevant quantum computers break ECDSA digital signatures because we put those on VC barcodes as well. So agreed that to my knowledge the VC barcode spec does not make explicit use or mention of biometrics at the moment. But there is also nothing to stop you from putting a biometric into a VC barcode if you so desire.
Wesley_Smith: And…
Wesley_Smith: that seems like not just a thing you could do, a thing that you would often want to do since these things often want to be connected or bound to people that hold the physical pieces of plastic in some way. So, I think it's a good candidate to at least mention here even though it's not, the most directly related threat.
Phillip Long: And just as a practical matter, it's incredibly common that you would have a barcode and an image on the same credential just the way it has been inherited from things like driver's licenses or whatever. But I agree with Ivon.
Dave Longley: And there are specifically Yeah.
Phillip Long: I agree with Ivon that it's an inherited dependency from an external combination of things, but one that is Fair enough.
Dave Longley: One component of it being specific to the barcode spec is you can take a biometric and shrink it down to put it in a barcode. That is the reason why you made the modification. And that doing you might increase the threat that it could be falsified in a variety of ways you have to…
Dave Longley: then close those gaps.
Wesley_Smith: What is the actual threat there?
Wesley_Smith: So, you can duplicate a biometric
Dave Longley: I think it is getting a valid true response when you have a actual biometric mismatch.
Ivan_Herman: Ready?
Dave Longley: it's a false positive for a biometric check.
Dave Longley: So the biometric does not match per the person, but you end up accepting it as if it did.
Wesley_Smith: So that is certainly a threat.
Wesley_Smith: I'm not sure that it's the only threat and I'm not sure that it's exactly what we're describing. I mean, we keep bumping into the same exact problem over and over again, but there is a set of threats that in some way are related to the holder binding in quotes.
Wesley_Smith: the attempt to staple an identity credential to the person holding the identity credential through the use of physical characteristics and These physical characteristics could be simpler, more primitive things like eye color, hair color or they could be more sophisticated it does sound painful. more sophisticated these sort of biometrics and…
Ivan_Herman: Thank you.
Wesley_Smith: attempting to subvert that kind of holder identification stuff is certainly a class of threats. It seems to me like using duplicable or clonable or fakeable biometrics is sort of its own threat, but it's not clear what you can do with it besides, fool the biometric check part of an interaction or presentation. All right, let's do the false positive notion for now and we can revisit in the future if we need so we can keep making progress.
Dave Longley: One other way to describe such a threat is a masquerading presenter.
<Dave Longley> "masquerading presenter" ?
Dave Longley: Does I don't know that that's helpful or harmful to try and be an umbrella for these
Wesley_Smith: That sounds still too restrictive,…
Wesley_Smith: but we can get there when we get there. All next we have information not covered on physical documents by VCB. Who added this one?
Information Not Covered On Physical Documents
<Phillip Long> It might be useful to mention Ivan's concern that the biometric threat may be more relevant to the binding of an biometric to a holder.
Wesley_Smith: Might have been me was it you?
Dave Longley: That it was I'm not sure that one might have been me.
Dave Longley: I was trying to refer there's a couple things here. So you can have a physical document that has information on it. where some of that information is not covered by the barcode and that can be a threat in the sense that people could misunderstand that information. They might think that something is covered by the barcode but and so I was going to consider it an implementation threat in a number of different ways.
Dave Longley: You need to make sure that the systems that you're using correctly surface to the users of those systems so that there is not confusion.
Wesley_Smith: strongly agree all around.
Wesley_Smith: I think that's a pretty straightforward one and also I think it very nicely fits in the implementation threats category. your digital signature isn't over everything. After all, everything is a piece of plastic. What exactly is it over? All right. anybody have anything else they want to add to that particular item? Okay.
Mismatch Of Information On Physical Documents
Wesley_Smith: If not next we have mismatch of information on physical documents with VCB.
Dave Longley: I did want to do a time check though. Amen.
Wesley_Smith: Back to thank so we are making really good progress on this and we're also discussing things that the group in general have added and we don't want to get into a position where folks aren't able another time to talk about what they've said. Greg Bernstein, do you have any issue with us finishing this out on this call going into your time and…
Wesley_Smith: then next week you can take, as much of the call as you need to progress the DI stuff or is there stuff you absolutely need to get done today for a DI?
Greg_Bernstein: no I…
Greg_Bernstein: if you can give me 10 minutes or
Wesley_Smith: Yeah, that sounds Okay, so We'll go for another 5 to 10 minutes to try to get through most of these labelings and then we'll go over data integrity. All right. with the time sensitivity in mind, mismatch of information on physical documents with VCB. who put this one? Yeah.
Dave Longley: I put that This is the one we were trying to sort of map to quishing, but it was a little different. And this seems like at least for now we can put it under implementation threats, but let's we can put it there,…
Dave Longley: but there that doesn't seem to me like it's the right place if for people who intentionally swap out BCBs with other VCBs. Yeah.
Wesley_Smith: And I'll also note that implementers must handle it's kind of restrictive language here.
Wesley_Smith: There are attacks that implementers such as people who build issuing and verification systems must handle. And then there are attacks that are totally unrelated that the clerk at the gas station needs to handle, And I don't think we would call them an implementer. So I'll put that in both external and implementation threats. I think we're all aware that as written now needs a lot more explanation and clarity because there are a lot of different ways in which you can do this kind of mismatch attack. All right.
Duplicability Of Optical Barcode Bytes
Wesley_Smith: Next up we have duplicability of optical barcode bytes. this one I'm going to say is a dependency threat inherited from a required external technology. These things are optical barcodes. You can put them in a photocopier and make photocopies of them. That's something that you can't do with digital credentials in the way that they are expressed most of the time. I think that's pretty straightforward. if I haven't labeled your thing with your contributor name, please do that. duplicability in cases where signed data is not uniquely identifying for a holder for identity barcodes. I put This one is a pretty specific one and it is strongly related to some of the other larger conceptual points that we're touching on.
Wesley_Smith: Basically here if you are going to do something such as sign over the fields in a driver's license credential, those fields might be things like height, eye color, whatever, address related to the threat that we just talked about of information not covered by digital signature. It is possible that the information that is signed by a digital signature reduces the set of people that meet this description to a set larger than one. So if somebody who looks a lot like me takes my barcode, they could present it and then pass this biometric check. again, this is strongly related to some of the other threats that we've already talked about. We need to figure out the best way to reduce them down to a minimal comprehensive set.
Wesley_Smith: But for now I would argue that that is an implementation threat that if Elaine go ahead Right.
Elaine_Wooton: Yeah, I think you can add in there that often times at least with US driver's license there is no biometric.
Elaine_Wooton: So you can copy the entire document entirely, scan it entirely, just swap out the photo and then everything's going to be good. So I just put a caveat that often there's no biometric in the barcode yet.
Wesley_Smith: No, that's a really good point. and so then often the set of identifying characteristics that you're left with are okay, this person is 5 foot 10 and has brown hair and blue eyes and that's it kind of thing.
<Phillip Long> +1 @Dave ^^^^
Elaine_Wooton: Yeah, exactly.
Spoofing Of Keys Where Available
Wesley_Smith: And obviously that's a fairly large set of people that you're describing. especially those we are down to the last uncatategorized item. Spoofing of…
Wesley_Smith: where keys are available. Who put this one in?
Elaine_Wooton: Yeah, that's me.
Wesley_Smith: Okay. Absolutely.
Elaine_Wooton: So, if they bad guys figure out how to put the public keys somewhere other than where they're supposed to be, they can sign it.
<Phillip Long> Can you implement selective disclosure in a barcode?
Wesley_Smith: So that sounds me lot to me like a dependency threat because we're using technologies to distribute these public keys. but not defining them directly in the VC barcode spec. We're using things like decentralized identifiers. And totally right. If you compromise the way in which those public keys are distributed, you can pass off a fraudulent document as real. but I think that's a kind of textbook example of a dependency threat. the way that we've currently architected the VC bar code spec. All nice. We got through categorizing that whole list in only a little bit over time. is there anybody would like to add to this kind of threat model brainstorm session before we pivot over to data integrity for the rest of the call? Man, go ahead.
Manu_Sporny: Yeah, just to kind of speak to next step. So this is great this is working out really well to gather kind of threats from the group. the next step is to move it into a threat model document. I am trying to figure out what the best way to do that is. I think I need to talk with Joe, Andrew, and Eric Shu about this, but I think we want to programmatically split these up into a bunch of different YAML files that talk about the threat, that talk about the stakeholders, that talk about, the data flow dictionary. because I think we're going to want to reuse this stuff.
<Greg_Bernstein> With something like BBS that is space efficient for SD
Manu_Sporny: Just like we reuse bibliography entries we have a bibliography database and we use that bibliography database to link to the latest version of documents so that we don't have to keep updating it. I'm seeing the threat modeling stuff kind of go down that path. I think Joe has said something similar to that. The problem is we have zero tooling for that. I know Joe's working on some of that. So, it may be that somebody else that has more time than me takes a cut at taking what we've brainstormed and putting it in a machine readable format so that we can generate these specifications. von somewhat like you do for YAML to vocab. I'm thinking something in that vein.
<Dave Longley> Phillip -- you can put a derived VC into a QR code, so yes.
Manu_Sporny: That's my kind of thoughts on next steps here is we're now going to be potentially blocked by some of the tooling and…
Wesley_Smith: Avon, go ahead.
Manu_Sporny: maybe we can do a very rapid iteration on that tooling so we can get a threat model document together so that we can kick off the horizontal review process. that's it.
<Phillip Long> Then does SD increase the potential threat opportunities as that which is exposed gives less for the recipient to verify?
Ivan_Herman: I just want to understand something about this whole threat modeling thing. somewhere here we should have something which says yes this is a threat but this aspect of things is covered by the VC spec by these and…
Wesley_Smith: Morning. Go ahead.
Ivan_Herman: these reasons and we handle that and I haven't heard anything about that so far.
<Dave Longley> there are probably a few threats that could be listed there (and would go under external or dependency threats i would think)
Manu_Sporny: I think so if in the threat modeling guide of there's a place on whether or not we mitigate it or we don't. so that's a required part of the documentation that's generated. There is also an expectation that we point to the other threat models and reuse information from the other threat models. But that is a bit of a handwave right now. We don't know how we're going to do that right. so I think Ivon some of that is to be decided. but when the document is rendered it is very clear on whether or not this spec addresses the issue or another spec addresses the issue which I think addresses your primary concern.
Wesley_Smith: Craig, go ahead.
Manu_Sporny: That's it.
Greg_Bernstein: Two points that issues come up a lot as we've been thinking about …
Greg_Bernstein: how to do this with data integrity because we are so in parallel to what the signature algorithms claim including when we talk about forgeries ries when we include about things beyond just forgeries.
Greg_Bernstein: The other point was we've seen a general digital credential threat model come out of the Singh group and data integrity really a threat model for that could be considered a threat model for a subset of that which is embedded proofs and barcodes could be considered a subset of that which is associated with the barcodes. But of course it has unique threats. So we kind of get into these overlapping threat models and…
Wesley_Smith: Go ahead.
Greg_Bernstein: how are we mitigating certain things and which things are in scope and…
Greg_Bernstein: out of scope. And I am very glad that Wesley is hitting this before I do for data integrity.
Ivan_Herman: Yeah, just an information.
Ivan_Herman: I think it came up on the last meeting of the working group, but we have now an agreement with Simona that he will be present remotely at the discussion on the face meeting which we have on threat model. So there are a number of issues or questions like what Manu said that we can discuss with him as well there.
Wesley_Smith: Heard generally. I think we at least have a high level understanding of what next steps might be. over to you Greg for data integrity. one very brief note on VC barcodes. I raised a couple of trivially small PRs in response to issues that were pointing out bugs in the spec recently.
Ivan_Herman: Yes. Yes.
Wesley_Smith: If you are an approving type, please go we'll get them and then approve them if you approve them and I'll get those merged. Over to you, Greg.
Postquantum And BBS Status Update
Greg_Bernstein: I'm not used to sharing screens,…
Greg_Bernstein: but can you see this? and I'm showing poll requests right now. So, here's what we've got is we've got postquantum, we've here's the ordering of priorities currently postquantum, restructuring documents, threat modeling, and BBS. And depending on what happens in the next couple of weeks with BBS, we may accelerate and pull that up closer.
Greg_Bernstein: postquantum I put in two different PRs except one builds on the other. The most recent PR is on test vectors for selective disclosure. I am glad people approved it. I would like to get people to approve the other one that is the base text which includes going on the selective disclosure crypto suites. And so this is the write up of the algorithm I outlined and told you guys before. It is a salted hash approach. It's relatively efficient especially compared to the size of the signatures.
Greg_Bernstein: I put in some information in there about that. we've got test vectors for these. all test vectors are tentative until somebody else can verify them and such like that. so I'm going to hit up my reviewers again to take a look at question mono.
Manu_Sporny: Do we I glanced and…
Manu_Sporny: saw ski sign on there. Do we have test factors for ski sign as well or am I misreading? at the appendix. It's fine if we don't. I was just surprised.
Greg_Bernstein: I did we have test vectors for regular ski sign.
Greg_Bernstein: I did not do ski sign for selective disclosure for two reasons. I don't have a nice JavaScript implementation.
Greg_Bernstein: It's not that and two ski sign is right at the border of where we might use the technique like we used with ECDSASD with lots of signatures versus a hash and a salted hash approach. But I did create some test vectors for regular C ski sign questions.
Greg_Bernstein: Maro and Dave.
Manu_Sporny: Yeah, that's great.
Manu_Sporny: That's fantastic. Thank you, Greg. That's further along than I thought we were going to be. So, thank you very much for that. heard on the selective disclosure stuff. Yes, we'll need to talk about, that. do you have any plans to look into Ski Sign HD? those I don't know how stable it is just so everyone on the call knows a ski sign made it into the next NIST competition phase so that was very very recent Greg saw that they had accepted Ski sign.
Greg_Bernstein: Haven't seen that.
Manu_Sporny: It is the one that has the smallest signature sizes and there is a variant of it called I think Ski Sign HD or something like that that has I think 64 byt signatures which would be amazing because we would have a postquantum signature that would be effectively the same size and as an ECDSA and EDDDSA signature. that's kind of the holy grail I think.
Manu_Sporny: Pi Sign HD, sorry. as Dave pointed to in the chat. do I guess Greg, say you hadn't heard of it yet. So never mind on the Next question was going to be like it would be good to understand …
Greg_Bernstein: There was an interesting highlight particularly in that NIST report about the next candidates…
Manu_Sporny: how brittle that approach might be or I think there might be a top out on the number of signatures you can do or something like that. Anyway, thoughts.
<Dave Longley> PIsignHD ... PIsignHD: A New Structure for the SQIsign Family with Flexible Applicability
Greg_Bernstein: because some of the candidates were being accepted and considered for special properties because they had some candidates that had very small signatures
Greg_Bernstein: but public keys. And so for a barcode situation, a small signature but a slightly larger key isn't as much an issue. And so don't rule anything out because as long as we keep the verifiable credential application forefront and it can benefit from smaller signatures…
<Dave Longley> 519 bits => 65 byte signatures
Ivan_Herman: Okay.
Greg_Bernstein: but slightly larger keys because sign as it exists is overall most efficient in terms of private key size plus signature size. But Dave Yeah,…
Dave Longley: Yeah, you're kind of speaking to something I was going to talk about that the latest NIST report for the next round of the competition had things like Mayo in there which has larger public keys than ski sign but it also has small signature sizes which meets the use cases here. So I wanted to make sure we were considering adding those things that might make it all the way through the NIST competition and would meet the requirements of BCBs.
Manu_Sporny: How big were the Mayo signatures,…
Manu_Sporny: I thought they were still several hundred bytes in size,…
Dave Longley: There are 96 bytes.
Manu_Sporny: but Interesting. Go.
Greg_Bernstein: they're getting small.
Greg_Bernstein: So now let me remind folks we refactored the postquantum thing to really make it easy to all we have to do is add something to a table. The algorithms are very generic because NIS said hey we're going to use this common API so to add or remove something is not that hard. Okay, and same thing I extended that to the SD procedures. Currently for this postquantum SD we're doing SLHDSA and Falcon because they have large signatures.
Greg_Bernstein: If we have small signatures and we want to do what we do with ECDSA type approach with multiple signatures which leads to a smaller thing going between the holder and the verifier we have that option still okay because we have these procedures okay I think we're almost out of time but Ivonne what do we need to do so we can get this into besides of course getting these two things the two PRs put in.
Greg_Bernstein: What do we need to do to get ready for this first public do working document or what does it mean? Okay.
Working Towards First Public Working Draft
Ivan_Herman: So for this task force…
Ivan_Herman: because part of it has to be voted on the working group and part of it has to be
Ivan_Herman: cooperation between the editor and myself which is a well-rooted and well-known procedure for this task force it may be much more complicated because we have to agree on a name and that's notoriously long so you are talking about postquantum we are talking about quantum safe we are talking about who knows what we have to agree on the short name as we call it in the WCC jargon because once we have a short name then later in two months changing the short name for whatever reasons is a pain in the backside.
Ivan_Herman: So we had better finding a short name that we can live with all along.
Greg_Bernstein: Okay. …
Ivan_Herman: That's what we have to agree upon here.
Ivan_Herman: And then we officially semiofficially tell Phil and Brent that we want to have that and the rest is routine so to say.
Greg_Bernstein: I don't have strong opinions on names. I just take what other people have been recommending. come on in.
Manu_Sporny: Let me suggest that we don't rush it. We have two minutes left. We can't decide this time.
<Dave Longley> +1 for a small signature section, vital for VCBs
Greg_Bernstein: Okay. Yeah.
<Dave Longley> (or selection of options at least)
Ivan_Herman: Yeah. I agree.
Manu_Sporny: A quantum safe is fine except it's not really safe, completely safe.
Greg_Bernstein: Yeah. I was thinking there's a lot of these issues old issues not the newest ones…
Manu_Sporny: It's resistant. Is those kinds of details that we want to get So let's do that on the next call. suggestion.
Greg_Bernstein: but the older issues I think we've resolved a bunch of them I can go through and try and close them out that's kind of something we do before we try and publish but any items that I can take on right now to help us get there.
Greg_Bernstein: I mean,…
Manu_Sporny: You could categorize them,…
Manu_Sporny: Greg, and suggest why they should be closed. We have to be a little careful on just closing issues.
Greg_Bernstein: Yep.
Manu_Sporny: Editors can't just do it by themselves. we have to make sure that the group agrees with, your reasoning to close and then we'll close it.
Greg_Bernstein: One more question.
Greg_Bernstein: previously on all the DI documents crypto suites even if we had approval we would wait a week before merge those kind of rules.
Manu_Sporny: We have to do that here.
Greg_Bernstein: Okay.
Manu_Sporny: Yeah, we got it still. Yeah, that's the same process here.
Greg_Bernstein: Okay.
Manu_Sporny: You can't merge right away. You've got to give at least seven days for people to get their comments in.
Greg_Bernstein: I didn't have that much time while this was a CCG document to get used to anything else. so that's fine. So, I mostly worked the more formal system. I think we're out of time. and I can continue on next time and…
Ivan_Herman: Oops.
Greg_Bernstein: give updates on Once again, it's that restructuring of data integrity feeds off of this work with doing the selective disclosure for the postquantum stuff because we're seeing how those algorithms get reused.
Greg_Bernstein: Yet again we have three cases ECGSASD BBS and this salted hash approach for large postquantum signatures.
Wesley_Smith: All right,…
Wesley_Smith: thanks raig. we are out of time. Thank you everyone for being here. and see you next week. Meeting ended after 01:01:03 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.