Meeting minutes
Meeting Welcome And Introductions
Wesley_Smith: Good morning folks or afternoon as it may be.
Ivan_Herman: Good morning. And then you are muted. I didn't hear what you said.
Elaine_Wooton: I responded to Wes and said good morning.
Ivan_Herman: That's now better. Yeah, for the time being it does.
Greg_Bernstein: Let's see.
Greg_Bernstein: Is my audio working this time or last time it was all messed up? my god. Okay.
Elaine_Wooton: You are working, And Ivon, I think you'd mentioned you might not make it in here. Wonderful.
Ivan_Herman: Yeah, I am back home…
Elaine_Wooton: So you're here. Wonderful.
Ivan_Herman: since 10 minutes.
Wesley_Smith: So, Ivonne, I'm curious with this Google Meet setup,…
Wesley_Smith: do we need to use key commands to progress the agenda similarly to what we do on IRC or do we not need to worry about that? Mhm.
Ivan_Herman: with this setup.
Ivan_Herman: Not really. I think there are some things like topic setting and me remarks etc. that we can do on the chat of Google and somehow the script will compare the time stems and will sort of merge the two. So topic setting for example should work.
Ivan_Herman: But other than that, as far as I know, nothing else. look, it's money should know it and…
Wesley_Smith: And topic setting is just topic all caps colon and…
Wesley_Smith: then the topic. Right. Okay.
Ivan_Herman: whatever and resolutions etc. these are working.
Wesley_Smith: All right. Eggs.
<Ted_Thibodeau_Jr> Could the "standing agenda" in the calendar be updated with links to the PR & issue lists in the respective repos?
Ivan_Herman: So that's more than nothing. So it's okay. what I really hope is that the experimentation done by Otto I'm sorry I'm ashamed I forgot his family name the chair of the DID working group that what he's doing is on long-term a better solution but it's still to be
Wesley_Smith: Should we wait till 5 after the hour to get started? What do you folks think is best? Yeah, absolutely.
Agenda Updates
Ted_Thibodeau_Jr: I'll just voice what I threw into the chat. I'm wondering if the standing agenda in the calendar could be updated with links to the PR and issue lists in the respective repos. Just makes it a lot easier to get there, not having to remember all the respective shard names.
Elaine_Wooton: Yep.
Wesley_Smith: Greg, after this meeting, could you send Elaine a list of those links for the respective DI repositories that you're working on?
Greg_Bernstein: will do.
Ivan_Herman: Except that the number of repositories is pretty high for this task force…
Ivan_Herman: because we have how much? One, two, three, four, five, potentially six repositories at the minimum that are under our control. Actually, let me check something.
Wesley_Smith: That's okay.
Wesley_Smith: That's okay.
Ted_Thibodeau_Jr: Maybe for this task course it turns into project pages.
Ted_Thibodeau_Jr: I don't care about the specifics so much as make it a click to get to, barcode, short name, whatever that is.
<Ivan_Herman> Tools | VC Barcodes and Data Integrity | Task Forces | Discover W3C groups | W3C
Ivan_Herman: The administration I did for task forces has its positive aspects. Look at that pointer Ted on which I put on the chat.
Ted_Thibodeau_Jr: Yeah, that helps some.
Ivan_Herman: The advantage of this one is that it is automatically updated if we add a new repository.
Wesley_Smith: Elaine, could you go ahead and add that link that Avon posted to the meeting agenda?
Elaine_Wooton: Yep.
Greg_Bernstein: Yeah,…
Wesley_Smith: Thank you very much.
Greg_Bernstein: we just need to put in
Ivan_Herman: The trick is that there is a W3C.json file in the repository…
Ivan_Herman: which is the one the system uses for all kinds of automatism and it lists this task force as a owner of the repository. That's all it takes.
Wesley_Smith: All right, it is 5 after so I'm going go ahead and get started. We're a little bit late today. I expect people are still kind of working out the shifting calendars and so on and so forth, but once we settle into some kind of more regular cadence, I hope we get more people again. but I think that's fine to get started so for today, pretty standard stuff. Spend a few minutes talking about process announcement things and then I'm going to spend half the time about talking about VC barcodes and the other half talking about data integrity work.
Wesley_Smith: So I will chat.
Announcements and Introductions
Wesley_Smith: First things first. go ahead Ivon.
Ivan_Herman: No, no.
Ivan_Herman: It's just something you start with the agenda items.
Wesley_Smith: Sorry I didn't understand your question.
Ivan_Herman: Yeah, you have no your topic announcements. I have something as an announcement.
Wesley_Smith: Okay go ahead.
Ivan_Herman: So, you may have seen it but better to have it recorded that all the documents that we wanted to publish as first public working draft has been published last Thursday. So I have set up akidna for all of them I have added PRs for all the repositories with akidna I don't know whether there is some additional processing done in these repositories mainly the DI but I would leave it to those who maintain that repository to merge it.
Ivan_Herman: I didn't want to merge it, but I have set it up with a new short names for what we had already before, etc. So, it's all ready to go.
Wesley_Smith: Thank you so much for all the hard work there,…
Wesley_Smith: Ivonne, and everybody else that contributed to publication of those first public working drafts. That's great news. I saw your PR on VC Barcode specifically. I expect we can get that merged pretty shortly. All right. anybody else have any announcements they want to make or would like to introduce themselves? All right. And I think we can go ahead and start talking about VC barcodes. All right. So, I'd love to get people's thoughts about screen sharing. I know in the JasonLD working group, there's been some frustrations with screen sharing, making it kind of difficult from just a listening perspective to understand what's going On the other hand, it makes it clearer if you're looking at the screen.
VC Barcodes PR Review
Wesley_Smith: So for things like poll request review, do you folks think it's better to not screen share and just kind of dictate and have people follow along or do you think screen sharing is okay?
VC Barcodes PR review/ issue processing
Greg_Bernstein: I like to use both. If it's too hard to read, I will go and look at it. But it's nice when we can follow along with your screen. Wesley Smith:
Wesley_Smith: All I will start with screen sharing then and if anybody feels like it's making it difficult to kind of follow along without paying, a ton of attention or anything along those lines, please let me know and I will change that. All right. So, do you folks see my screen?
Ivan_Herman: Mhm. Excuse me.
Wesley_Smith: So, the first thing I want to talk about today is this PR open on All right.
Greg_Bernstein: Yeah, I assume this is a meat thing.
Ivan_Herman: Very much blurred for me. I don't know whether it is. No. Okay. It get better. it's very blurry.
Wesley_Smith: Anybody else having quality issues?
Ted_Thibodeau_Jr: Yeah, it's doing something scaling.
Elaine_Wooton: Y blurry.
Wesley_Smith: That is all then why don't we go ahead and trial not screen sharing for this PR then? I will drop a link in the chat to the PR. So, this PR is on the BC barcodes stuff. I would say it's a small to medium scoped PR. It's fairly editorial. It's mostly just restructuring introductory text in the specification. and specifically, it is to address Ivon's point that the actual VC barcode use cases. there are two major use cases and they're somewhat conflated and unclear in the document.
Wesley_Smith: Essentially what the text that this PR adds tries to do is it tries to make it clear that you can either if you want a VC barcode on a document, you can either put a new barcode on the document and in that barcode you put a credential that has all the data you want inside the credential or if there's already a barcode on the document. So there's already data from the document in a machine readable form, you don't need to do that. All you need to do is append a credential to the end of the existing barcode. and that credential doesn't need to contain all of the data from the document itself because that data already exists in the signature on that credential just needs to sign over the data as it already exists in a machine readable form on the document itself. So that's what this PR tries to clarify.
<Wesley_Smith> Clarify the two major VC Barcode use cases. by wes-smith · Pull Request #44 · w3c/vc-barcodes · GitHub
Wesley_Smith: I think that as I said, this is basically just text in kind of an introductory sections on that topic, but some of the main technical content in the specification will need to be reorganized a little bit to clear up this sort of breakdown dichotomy as well.
Clarify the two major VC Barcode use cases. by wes-smith · Pull Request #44 · w3c/vc-barcodes · GitHub
Wesley_Smith: And there is go ahead.
Ivan_Herman: So I'm sorry I asked so many questions from that one…
Ivan_Herman: because it was not clear to me and there is still something which you just said which strikes me.
Wesley_Smith: Go ahead. only.
Ivan_Herman: When you say it appends at the end of the barcode, what does that mean for a QR code?
Ivan_Herman: If the barcode is a QR code, it doesn't make sense to say the pens to the end. Yeah.
Dave Longley: I don't know if you want to answer that. my response is somewhat in response to that. I had similar struggles with at least one sentence in the PR and I think it has to do with separating whether we're talking about the data in the code The barcode being an optical code that is pixels ink on a card or on a piece of paper or whatever.
Dave Longley: And I think we need to do a slightly better job of expressing that because when we talk about Ivon was just saying the inserting something at the end of a barcode I think is probably too in the details and thinking about a PDF 417 and putting information at the end of the data that is expressed in a barcode which then changes how the barcode's expressed but depending on what type of optical code it is It might literally look like more ink on the end of a barcode, but in the case of a QR code, it's not going to be expressed in that same way.
Dave Longley: So I think we need a slight clarification that the two different kinds of VCs you can have here are one where the VC itself is all of the data that gets expressed in an optical code or you take existing data that's already expressed as an optical code and you augment that data in some way with a VC and that VC then expresses some kind of information about the other data that's being augmented. And then you produce a new barcode from all of that…
Wesley_Smith: Yeah.
Dave Longley: which may not involve just appending some more pixels on the end of something or it might be totally different. And go ahead of
Ivan_Herman: Thank you very much, Dave, because I thought that I was the only one who doesn't understand anything. I had exactly the same problem with the pixels versus the data that pixels refer to. so that's very much in line with and that also something that is not only for this introductory part not for the only. The same kind of problem arises in the description of the examples that follows this part which mixes these things and even when we come to the crypto suit later which makes use of the existing data there again it's a bit unclear where the data comes from and what kind of data is put there.
Ivan_Herman: So that's not only for the introduction, it's for the whole presentation of the document that this is relevant.
Wesley_Smith: Yeah, absolutely. Good discussion. strongly agree. I will note that with respect to one clarification when I said append to the end of the barcode, that was loose conversational language. I don't think any where anything in the PR uses the term end. it doesn't need to be the actual end of the barcode. you augment the barcode somehow. I think that maybe it would be useful to make clear that from the perspective of VC barcodes and this technology, barcodes are essentially immutable things, if they exist, they exist. And you're not when we say we're changing augmenting an existing barcode, it doesn't mean augmenting the ink and pixels of a barcode that already has actually been printed.
Wesley_Smith: it instead refers to the data. need to figure out how to communicate that nuance somehow. Definitely agreed. one thing that I would like to bring up which I'm curious to have the group's perspective on. So, let me see if I can find a link to it. we define a type optical barcode credential. and however the current specification text and again let me find a link here. I believe the current specification text only uses the type optical barcode credential for the augment an existing barcode use case.
Wesley_Smith: So, if we were to just take a VC and put it in a QR code and print that on a document, which is a totally legal and very useful thing to do with the VC barcode the spec contain the optical barcode credential type. even though it at least appears to be something that could be well described as an optical barcode credential. So, I think we could maybe generalize that type, but I will note that if we do that, we'd have to make sure that we don't need to get the coupling back between the optical barcode credential type and…
Wesley_Smith: the constraints on the other use cases mechanisms in some other way. Go ahead.
Ivan_Herman: I don't think I agree with…
Ivan_Herman: what you say. So if I take the simple case where I generate the barcode from an existing VC with all the signatures and whatnot. for me in a way that's a rendering method. I don't want to mix the two things but it's the similar thing. You are rendering something which is there and the VC itself doesn't change whether you render it by printing the JSON and giving it a piece of paper or by putting it into a barcode. So that's separate. The notion of a type is only for the credential itself.
<Wesley_Smith> Verifiable Credential Barcodes v1.0
Ivan_Herman: the other type when you have the augmented thing. In a way, I would also question whether it is a good idea to have a separate type for that for the same reason. But you could say that if there is an added semantics to it namely that it is a type that requires a specific type of crypto suite. namely the one which uses I don't remember the name the one which is defined in this spec. so that's a kind of an added semantic to the credential as a type.
Ivan_Herman: So it can be justified but when you don't use that there is no justification to a type or change the type in my Yes.
Wesley_Smith: That makes sense.
Wesley_Smith: I think another way to phrase what you were saying is in the first use case once you get to the VC you're done. You've already understood everything that you needed to understand to but in the second use case, you're not done because you need to go look at the rest of the barcode to produce the hashes that you need to verify the signature and so on and so forth. so that makes sense and I totally agree. my concern more is about maybe it's just a naming concern honestly. Optical barcode credentials sounds a whole lot like both of those things. but there is value to having a type that is coupled to some of the semantics as you said in one use case but not really in the other use case.
Wesley_Smith: So, Dave Longley, go ahead.
Dave Longley: Yeah, Avon just said a lot of the things I wanted to say in response to that. So, I'm strongly in agreement with what Avon just said. I think in the first case, we're just talking about a VC. You can render it however That could be JSONLDD text on a screen. It be a QR code, could be some other kind of optical barcode, could be whatever rendering you want. and in the second case we are talking about a VC that is specifically about other data that is typically rendered and specifically in this case for this spec in an optical barcode. that's where that type comes from. It's a little bit awkward and there's a little bit of conflation because you do care about what the data format is behind whatever barcode it is you're trying to augment.
Dave Longley: fundamentally you are looking at an optical barcode. There's some kind of data that's behind it and you want to add a VC to augment that data and then reproduce that same barcode in that same format. That is the whole use case. and so optical barcode credential doesn't fully capture that. It doesn't capture the full typing of what it is you're augmenting. if I remember correctly, I think unfortunately there's not another type that's on there that would speak to what kind of data it is, but I think the specs also going for a general solution especially when it uses the protected component index and there is other information there. So sorry the spec was loading slow. I was trying to take a look.
Dave Longley: So there is other information when you use an optical barcode credential where you talk about the subject which is the optical barcode or the data behind it and the subject of your credential at that point to give an example from the spec is an AMVA driver's license scannable information. that actually makes a whole lot of sense. So the subject you're targeting with your credential is the scannable information that's inside of that optical barcode. And then that protected component index is saying which fields inside of the scannable information are protected by this VC that is an optical barcode credential. the more I just read all that, the more comfortable I actually got with so I don't know that I actually have an issue with the way it's currently modeled.
Wesley_Smith: Okay. …
Wesley_Smith: thank you. Avon, go ahead.
Ivan_Herman: I'm sorry.
Ivan_Herman: I have a question for what Dave said just to make it very clear. You said that the subject of the VC is the data behind the optical barcode. For me until now my mental model was that the subject is whatever is in the credential. It's just that what is described in the VC is not the whole information
Ivan_Herman: about that subject. And these two statement are not identical.
Dave Longley: Yeah, I actually meant to put my hand up, not thumbs up that day because I think in this so when we're talking about the first case…
Greg_Bernstein: That's
Dave Longley: where you just take a VC and render it however you want, which could be an optical barcode, the subject is whatever the credential is about and so on. I think in the optical barcode credential use case, the subject is the scannable information that's already in the barcode and you're making a statement about that information and saying these parts that thing has a bunch of components inside of it. These are the components that are protected by this credential. And so this credential is stating the information in this barcode or the other information in this barcode is protected or…
Dave Longley: these other fields in other information in this barcode are protected by this credential. And so this credential is really about the other information that is in the same barcode in which it resides.
Wesley_Smith: Plus one.
Wesley_Smith: It's protected component index is just an indirection, it's as Dave said, the subject of the credential is elsewhere and what's actually in the credential is just a lookup mechanism that specifies exactly what data elsewhere is the subject of.
Wesley_Smith: Go ahead.
Ivan_Herman: I would love to see that statement put clearly in the introductory part that this whole PR is all about…
<Wesley_Smith> Verifiable Credential Barcodes v1.0
Ivan_Herman: because that was not clear for me at all. Now I have a different view of the whole thing and it should be clear in the introduction already.
<Wesley_Smith> there is no information in credentialSubject other than an "index" against the externally available subject information
Wesley_Smith: Yeah, absolutely can do that. Ela, go ahead.
Elaine_Wooton: Yeah, I don't if it's confusion or not. so the optical barcode credential is going to be the thing that you add that is in addition to the data that was already there for the second use case. And then in the third to last sentence we have that whatever it is it says is protected by the digital signature. So I think we need to make clear what the digital signature is as compared to the optical barcode credential. Elaine Wooton:
Ivan_Herman: We lost
Elaine_Wooton: And I'm not I accidentally hit the button. So it may be that it doesn't me need to be made clear, but it's not clear to me…
Elaine_Wooton: what the relationship is by. So, if the thing that we're augmenting with is the digital signature, then isn't the digital signature the optical barcode credential? And I think it's not,…
Wesley_Smith: Yeah. No,…
Wesley_Smith: it's a Sorry.
Elaine_Wooton: but I think we need to make it clear. And I'll tell you why. Because the digital signature, that's the term that AMA is using for a bunch of things. So, we want to make sure that
Wesley_Smith: No, it's a really good point. So what we're adding is it is a digital credential which contains a digital signature and most of the time when you see that pattern the digital signature in the digital ial just covers the digital credential itself. but here we use a different mechanism so that the digital signature covers not only the credential but also the other data in the barcode. so we need to be explicit about how that works. I know that there's some technical discussion about that later in the specification and…
Elaine_Wooton: Yeah. Yep.
<Dave Longley> the second case is: "there's already some data rendered as a barcode, let's make a VC about that data and then generate a new barcode that has both the VC and the original data in it"
Wesley_Smith: it's specified algorithmically and so on. but as you're pointing out that doesn't really help somebody trying to read the introduction and understand what's going on.
Ivan_Herman: I…
Wesley_Smith: All right. Ivon and Elaine if you guys could go ahead and add brief comments to that with respect to what we talked about today that would be really helpful. I would love to be able to just make those changes immediately, but unfortunately today I cannot.
Ivan_Herman: what I hope is that the system will work and whatever we discussed will appear automatically.
Wesley_Smith: True. Excellent. Okay. I love that.
Ivan_Herman: If I put a topic with the reference to the PR. It should go through all the mirrors that we have. Then at the end of the day, it will be there.
Ivan_Herman: I hope.
Wesley_Smith: That sounds so thanks. That's probably going to wrap up discussion for that We're running low on time for VC barcodes. so I will make those changes and I expect we'll want to have another discussion about that before it gets merged. So maybe we'll close out that topic next week and hopefully merge that Ivonne, I saw that you raised a PR adding some sort of script support workflow script to the barcodes repo. I have approved this. I don't know what you are envisioning in terms of the future of that if it needs group discussion, if it should just get merged. What are you thinking?
Ivan_Herman: I would like money to have a look at it just to be on the safe side.
Ivan_Herman: Several eyes is better than one pair. But in theory the only thing we have to do is to merge it and from that point on the acid now will work out.
Wesley_Smith: Go ahead, Greg.
Ivan_Herman: But it's better if money manu or someone who knows how these things work not only me have a look at it. That's all.
Greg_Bernstein: What does the Akidna script in general do?
Greg_Bernstein: Do I know what kidnas is wonderful little animals? I don't know what the script does.
Ivan_Herman: The akidna script is a YAML file for the GitHub. What's the official name with GitHub workflow script?
Ivan_Herman: I always for mix up the name action akidna action script …
Dave Longley: Some GitHub actions, maybe GitHub workflows.
Ivan_Herman: what it does is that once a PR is merged then it will run a script which is provided by WCC …
Ivan_Herman: which picks up the document and the possible references to images and other diagrams and whatnot and it will automatically create a version dr in practice…
Greg_Bernstein: Okay, that's the publishing thing.
Greg_Bernstein: Okay, the draft publishing. Okay. Thanks,
Ivan_Herman: what this means that it blurs the difference between an editor's version and the published version of the draft. the content wise the two are the same.
<Benjamin_Young> GitHub Workflow Action YAML Thing
Wesley_Smith: All right, that sounds good. if we need Manu's review, I expect that isn't super timesensitive. I know Mu is traveling, so he might not get to it for a little bit. that's fine. I think that probably wraps up the VC barcodes portion of this call. thank you guys for the time. Greg, do you want to take us into DI land?
<Dave Longley> :)
Greg_Bernstein: …
Wesley_Smith: I'll topic it in the chat.
Greg_Bernstein: I do have a couple questions that probably might be answered by Ivonne. those FPWDs which stand for first public working drafts are going in or have gone in which means we're going to have the new short name. So we're going to have 1.1s on these documents.
Greg_Bernstein: So, are we ready to start formal PRs and…
Greg_Bernstein: updates on the 1.1s? is that work able to start now?
Ivan_Herman: It has become formal last Thursday.
Ivan_Herman: And…
Data Integrity PR review/issue processing
Data Integrity FPWD Process
Greg_Bernstein: So, that means all the processes we're used to doing as far as updating will apply to these 1.1 documents.
Ivan_Herman: yes and the respective akidna scripts in all those repositories are meant to do exactly that.
Greg_Bernstein: We have one document which is the quantum safe document which is a CCG document. and we've done a lot of cleanup on it. what do we need to do process-wise to bring that over? I know we've started doing a bunch of stuff and Manu's asked me to get stuff together,…
Greg_Bernstein: did all the link checking and stuff like that. Let me know, Ivon. Okay.
Ivan_Herman: So the first question I have…
Ivan_Herman: which I don't know is whether the document has undergone the finalization on the CCG side. I mean I am not involved in the CCG process. the question is whether it is finalized and IPRs are released and all of that administrative stuff that has to happen.
Ivan_Herman: Let me consider that done and it's up to you to see when it's done then you tell me at that point I will take the repository and I will transfer it to the W3C land from the CCG and then it will become part of this task force's official repositories and then the next step should be to publish that one as a first public working draft as well. The same way as we did for the barcode spec. So I have to transfer it. That's my job. But I can transfer it only or I am supposed to transfer it only when the CCG part is properly finalized.
Ivan_Herman: Yeah.
Greg_Bernstein: Yeah, I don't think I saw anything about IPR related to DI quantum safe and…
Greg_Bernstein: stuff like that. I think we saw a lot of calls that went out for other documents and things like that that are transferring over, but I don't think I saw that. So I will try and check with I mean that would be something I contact the CCG chairs about.
Ivan_Herman: Yeah, but actually Benjamin,…
Greg_Bernstein: Okay. Thanks
Ivan_Herman: you might know the details about how that works, right? You have done that.
Benjamin_Young: Yeah, I'm looking up links right now.
Benjamin_Young: There's basically a commitments page for each specification, but they're painful to find. So once I find them for you, I will send it to you, Greg, and then you can run down whoever you need to get approvals from.
Benjamin_Young: It's basically you're looking through the authors and editors list on whichever specification and then making sure they've all click the button. It's a fairly easy process once you where the pages are.
Greg_Bernstein: Okay. …
Greg_Bernstein: maybe talk a little tech about the technical side of what's in these specs and where we were going.
Postquantum Crypto Suite Issues
Greg_Bernstein: If I mean I was going to give a broad perspective because there was this notion of the DI specs going to 1.1 to update them for clarity and maybe move things around for clarity. And that also links into a possible feature I just put in an issue on with the quantum safe. So, I don't know if this is a good time to introduce that to folks. Okay, Neil, that's a big author list. if we want to go to the quantum safe, I put in there are a bunch of issues, but I put in a recent one and I'll kind of give a little briefing of why I think that's important.
Greg_Bernstein: Quantum safe crypto suite issues. Let me put that into the chat. And also let me remind folks where is the issues for data integrity. Okay.
Greg_Bernstein: I have a million tabs open many people here. I'm just reading your comment. if you look at Let's do it in order. the data integrity issues. If people want to bring that up or rather than me trying to screen share, we have an issue, it's issue 344, move general selective disclosure functions from VCDI, ECDSA to VC data integrity.
Greg_Bernstein: Okay, we have these generalurpose functions in the ECDSA spec that are used for processing A general JSON LD VC. This is specific to JSON LD. and basically turning that into an ordered list of statements, the raw contents of the VC so that it can be manipulated for selective disclosure purposes.
<Greg_Bernstein> Issues · w3c-ccg/di-quantum-safe · GitHub
Greg_Bernstein: It turned out that those that we used in ECDSA many of those were also useful for BBS is not postquantum and so the issues come up. Do we want postquantum friendly selective disclosure? So that brings us to the issue on the quantum safe side of things. are people following this by not seeing a screen? Okay.
Greg_Bernstein: So once again, an organizational thing about moving selective disclosures from a specific document where they're used which uses the ECDSA signature algorithm talking about moving that stuff some of it that's general over to the data integrity spec 1.1 partially is because we were reusing those functions as part of BBS too. Once again, BBS has been somewhat stalled and BBS is not postquantum. However, BBS has very nice features as far as size and privacy.
<Greg_Bernstein> Issues · w3c/vc-data-integrity · GitHub
Greg_Bernstein: The approach we use in ECDSA selective disclosure doesn't work terribly well with postquantum signatures…
Issue · GitHub
Ivan_Herman: Goodbye.
Greg_Bernstein: because However, there are other approaches that could be used. So if we go to Ivan posted integrity issue 344. if we go and look at let me get the exact issue up quantum safe issues issue 22. Let me throw that into the meet. So, we're doing time wise technical discussion. Okay.
Greg_Bernstein: So let's take a look at support for selective disclosure with postquantum signature types. And there's two parts to this. Do we want the feature? It seems like it's a good feature. We wanted it. We had it for ECA. Here's So, in this I outline a proposal for how to do this. And I review some numbers here. the size of an ECDSA signature was 64 bytes.
Greg_Bernstein: And what we did in ECDSA SD is we basically for all the optional statements in a VC turn those into a set of statements for those that are not mandatory. We sent over basically a set of signatures on each of those statements processed The problem with that is from 64 bytes for an ECDSA signature, we go to things like over 2,000 bytes for MLDDSA, almost 8,000 bytes for for SLHDSA and even Falcon at 666 bytes.
<Greg_Bernstein> Support for Selective Disclosure · Issue #22 · w3c-ccg/di-quantum-safe · GitHub
Greg_Bernstein: The only one that gets close and it's not yet adopted for standization is ski sign at 148 bytes. So there's currently three general approaches that people have been doing to do selective disclosure. There's separate signatures for the non-mandatory statements. use a signature scheme that has built-in support for it. It has a signature that doesn't grow with the number of statements. Okay, the proofs have some growth, but not Unfortunately, there's no quantum safe signature with this capability undergoing standardization.
<Dave Longley> +1 to SD for quantum safe
Greg_Bernstein: Not that there couldn't be but right now there is not. Another approach is known as a salted h approach. And here's a reference to a general paper about that was given about compact and selective disclosures for verifiable credentials. It uses salted hashes and then some optimization schemes. However, for our purposes, we have to make sure that the optimizations don't introduce any vulnerabilities to quantum computers because I noticed in this paper, one of the ones they were using was elliptic curve based accumulators and such like that. And that's not standardized yet. so what does this mean to use the salted hash approach?
Greg_Bernstein: Basically for every statement you need to add a salt and a hash. So assault being used out there is 16 bytes and a hash for this level of security at 32 bytes. So we're talking about adding 48 bytes. The only thing and it's like that doesn't look too bad compared to a 64- byt signature except all those salts and all those hashes need to be passed on. It's not just a list of those that are selected. So what gets sent over but it seems like a very reasonable compromise. Okay, this is the mechanism that's used in SDJWT for security.
Greg_Bernstein: However, we're not talking about using SDJWTs here because we have a whole different mechanism that's very efficient for s mandatory portions of a BC and when it gets to the holder for the holder specifying which things they want to selectively disclose. That's all done through a standard mechanism known as JSON pointers. So after that intro I basically outline what I call salted hashes with Why canonicalizing group? That's our main function that we developed.
Greg_Bernstein: I think Dave developed in particular that I've used and producing all these lists of ve non-mandatory statements taking those apart putting them back together into credential after selective disclosure has been done and coming up and signing all these things in various ways. So that this is an outline with details that I won't get into all the details here. for this approach I will say I to help me walk through all these details. I did put together prototype implementations using the same code that I use when I produce test vectors and things like that.
Greg_Bernstein: So the reason why I bring this up even though this has not been implemented yet is when we move those selective disclosure functions most of them if we're reusing them DI spec others that are particular to an approach go into their corresponding specs. So if we wanted to select a disclosure for postquantum signatures, it would be good to work that out before refactoring the DIP spec and putting selective disclosure functions and aortioning things.
Greg_Bernstein: So kind of long- winded, but I'm saying if we want selected disclosure and post quantum, we should work that through and then look at refactoring the DI s Make sense? Questions? All Greek for anybody or we got thumbs now that makes sense to folks. So, it sounds like we need to prep the CCG document to bring over.
<Dave Longley> for clarity: every presentation of an SD credential that uses salt+hash requires all salts+hashes for all statements to be sent vs. if you sign each statement separately, you only need to send the signatures for each statement
Selective Disclosure Tradeoffs
Greg_Bernstein: question is, do we add selective disclosure to the CCG document then bring it over or bring it over…
<Dave Longley> depending on how many statements are in a VC, you can get very different overhead.
Greg_Bernstein: then add selective disclosure? Ivon? Bring it over…
Ivan_Herman: the second.
<Dave Longley> (and selective disclosure *usually* involves sharing very small set of statements, i.e., you are trying to be selective :) )
Greg_Bernstein: then add it.
Ivan_Herman: Yes. I mean the reason being that earlier we put a stake on the ground for the working group that we do select we do postquantum the best
Greg_Bernstein: Okay, that's great. Okay, I like it. because the tech working on the tech and implementation and discussion of that can go at any time but it's from the point of view of saying we've got postquantum that sounds like a good All right.
Ivan_Herman: That's in a kind of a general message that at public spaces when we talk about VCs then we have to make it very clear yes we are working on postquantum and B we are working on postquantum with selective disclosure these two statements are very important from the messaging point of you and unfortunately the reality is that for VCs we are in a messaging war with others
Greg_Bernstein: And I very strongly feel that also on the selective disclosure part because I feel we can do it much better than the others. Salted is a cryptographic technique. SDJWT has a lot of other baggage with it which I find difficult and after doing all the test vectors for different approaches to selective disclosure this being able to handle another variation is not difficult because of all our processing.
Greg_Bernstein: Are there any questions that we've gotten? I know Ted's reviewed, at least my editorial updates. we did the HTML checking.
Greg_Bernstein: We need to do the Anything else that we need for Okay, Benjamin.
Ivan_Herman: Once these all are done…
Ivan_Herman: then I step in.
Benjamin_Young: Yeah, upon related to that,…
Benjamin_Young: there is no IPR commitment page for this specification yet because I think somebody and I didn't know who it was last time, whether it's chairs or staff need to do something that moves it into the final report stage in something.
Greg_Bernstein: That's right.
Benjamin_Young: It shows up on a good day on this page for the credentials CG. but there were some that didn't show up there that still had commitment pages. but ultimately until we have that, until we have a licensing commitments page, there's no way to get those commitments that I know of. But I don't know what the smoke filled room actions are to move the draft draft community group report to a final report.
Greg_Bernstein: Okay. Yeah.
Benjamin_Young: So mostly asking a bond for that. Greg. Okay,…
Ivan_Herman: I don't know I knew I have never been involved with the CCG and…
Benjamin_Young: So, it just magically happens.
Greg_Bernstein: The Okay. Okay.
Benjamin_Young: Yeah. …
Ivan_Herman: the CG process details etc. I don't know. I step in when it becomes working group process.
Benjamin_Young: do we but we do have full approval from the working group to move this over rate. So if I Okay,…
Ivan_Herman: Yes, we do. Yes, we do. That's not a problem.
Benjamin_Young: I'm going to create an issue then on the quantum safe repo stating that these actions are needed and ping the chairs. Is there anybody else I should paying to make that happen?
Ivan_Herman: You should ping our big magician called money.
Benjamin_Young: I was afraid you were going to say that all roads lead to mono like Oz or…
Ivan_Herman: I know but he knows that halfway sleeping so
<Benjamin_Young> Credentials Community Group
Greg_Bernstein: Just playing.
Benjamin_Young: something. Okay. I seem to remember him just pleading into somebody's inbox and then it happened. so we'll find He's out for the week, but I'll post the issue and…
Greg_Bernstein: Okay. U any opinions here besides mine about selective and…
Benjamin_Young: ping all the people's. Thanks,
Greg_Bernstein: probably Dave about selective disclosure for postquantum. Okay.
Dave Longley: Yeah, I'm definitely in support of bringing that feature forward for quantum safe crypto suites as plus one for generalizing the transformation functions we have that allow a variety of interesting cryptographic techniques to be used on top of them including signing everything each selective statement with its own signature or using solded hash approach. We should explore some other approaches as well since there are trade-offs here. we should be thinking about verifiable credentials that might be very large student transcripts for example that might have a lot of statements in them for… Dave Longley:
Greg_Bernstein: Yes. my god.
Dave Longley: which you might almost always be selectively disclosing a significantly smaller subset of those for which you would get.
Greg_Bernstein: I mean, if you've seen what the CLR examples look like,…
Dave Longley: Yeah. Yeah.
Greg_Bernstein: it's like for every class you take, they include the full address of the school and institution information. And it's like, my gosh,…
Dave Longley: Right. Right.
Greg_Bernstein: can't you compact this a little bit?
Greg_Bernstein: It's like these are all the classes I took at this place and have a reference. But it was
Dave Longley: and certainly for using those things, you'll have use cases where you'll send the whole thing, but you'll also have use cases where you want to selectively disclose. and when you want to do that, presumably it's going to be a significantly smaller set. That's usually why you're using selective disclosure is to just pick a few things to send over. and in those cases that's where you'd get significant benefit with the current schemes that we have for ECDSA you only send the signatures for the things you're sending over that both saves a lot of overhead and…
Greg_Bernstein: Yes. Yeah.
Dave Longley: also some better privacy characteristics. But when we go to postquantum we won't be able to do that with large signatures. We might still be able to do that with ski signs. So we might want to consider using the same technique for ski sign and say hey if you really want to get those savings just use key sign. That's one approach we could take. if we're using the salted hashes approach just to be clear to everyone on the call. You always have to send all the salts and all the hashes for everything for every single statement even the ones you're not disclosing. And that's where if you have these large VCs that can become a problem.
Greg_Bernstein: Yeah.
Dave Longley: The smaller VCs doesn't matter. and so we might want to exploring a few other options. There's some ideas people have. of course, nature owes us nothing if we can't come up with something that works in a postquantum way. there was a paper that Greg linked to that we looked at, a while ago that I think used an accumulator, but I don't think it was a postquantum accumulator. and so there are some other things that could be explored to try and reduce the size of what would be sent over for large VCs and we should consider that though we do have these fallback options maybe make use ski sign if you want to do that knowing that that one is still part of the NIST competition they have not selected so NIST ran another round of postquantum or is
Greg_Bernstein: Yes. Yes.
Dave Longley: currently running another round of post postquantum crypto ski sign is in there. It is as far as we know doing well. they mistran another round because they needed to get things even smaller because the stuff that came out of the first round is just really large for a number of use cases including this one. So that is the state of things. We should definitely get SD into the group and we should explore some other options and so on.
Ivan_Herman: So one worry I have not being an expert of what happens here but just from my process point of view you say that some of these algorithms are still undergoing a review by mist at the end of A meaning when we publish the recommendation we should be able to refer to stable algorithms that potentially are already by…
Ivan_Herman: then blessed by mist once and for all. That's important.
Greg_Bernstein: it's so important and…
Greg_Bernstein: the timing is so critical that the document that I was working on was to make it easy to drop things if they don't make the cut off. Because right now we have two standards. FIPS 205. Falcon is supposed to be out this year is FIPS 206. Okay. And then ski sign, which is in this next round. and…
Ivan_Herman: Okay, good.
Greg_Bernstein: we've set it up the document that it's easy to lop off sections for instead of a separate document for each of these. It's almost like we just have a table with entries it's also helps that miss kind of standardize the API for signature algorithms too.
Greg_Bernstein: I think we've reached the end of our call. Benjamin
Benjamin_Young: Yeah, I just wanted to say that I think the next right actions as far as I can tell for the CG report is for someone and…
Benjamin_Young: I'm willing to do it because I did it five other times, to generate the CG report based on the current state of the document, assuming I don't see any PRs in flight. So, it just is a status change to CG report and then a submission to the main W3C CG reports page. if memory serves the magic happens after that and I don't know who does it or how they do it or when it will be done but then we should have a licensing commitments page available to…
Greg_Bernstein: Okay, correct.
Benjamin_Young: which we can cats. so if y'all are okay with that, I will take the first two actions in that story and then we wait.
Greg_Bernstein: Thanks, hurting cats. There was a lot of people that jumped on to author this thing and…
Greg_Bernstein: they all disappeared. So, Yes.
Benjamin_Young: Yeah, good luck finding them all again.
Ivan_Herman: They got their name on it and…
Ivan_Herman: now they are gone. Pardon?
Benjamin_Young: It's called graffiti, I think. Usually
Greg_Bernstein: All right.
Wesley_Smith: All right.
Wesley_Smith: Thanks everybody for the time.
Wesley_Smith: It is 11 on the dot, so we had better wrap up. I will see you folks next week.
Elaine_Wooton: Thanks everyone.
Elaine_Wooton: Thanks. Bye bye.
Greg_Bernstein: right. Meeting ended after 01:01:17 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.