TG ZKP Task Force Meeting - 2026/09/08

Hey. >> Hi. How are you? >> Good. You're >> very well, thank you. >> Hi. I have some uh connection issues, so I put my camera off. >> I often do too. My camera might be turned off later as well. How are you doing Dennis? >> Hey folks, I'm good. Last day of the vacation. Thank you for spending it with us. [laughter] >> Hello everyone. How are we doing? >> Very well. How about you? >> Yeah, good. >> That was an epic LinkedIn post. Um I've never seen someone tag so many people before. >> [clears throat] >> Yeah, I don't like doing it. So, once off, get all the energy into one post. And >> it's [snorts] still early morning for me. So, I post a link to the post so I can see how epic it was. >> Oh, you're tagged. Don't you worry. >> Yeah. [laughter] >> Oh, >> okay. Well, I'll find it that way anyway. But if you do have a link, >> I'll get it. >> Uh I'll get I'll get to it faster. Still uh spent the last hour writing my uh reaction to the editor's discussion we had two hours ago. >> Yeah. [clears throat] >> Never stop. >> I said I couldn't make that. any any milestones or notes you can convey? >> Oh, no. It's just a discussion around >> Oh, that's the wrong one. >> Verifiable statement credential. >> Um, >> sorry. >> I had something else on the clipboard. It is related. >> Okay. that one. Okay, >> everybody make Geneva safely. >> I'm sorry. What was that again? >> Geneva safely. >> Yeah. Sounds like your mic is got static in it. >> Maybe an unplug repug situation. >> I'm going to hang up and call back. >> Yeah, it did sound It was sounding a little funky there. >> Wow. >> All right. Well, welcome Arca. Um, >> as you can see, >> and >> we have two new um faces in the call today. >> Yeah, Ara and Urkan, who I don't I don't know if I've met Urkan before. Uh, I'm I'm post dog of Sanjam. I think we had one joint meeting like few months ago, but yeah, I think that's it. >> Okay. Okay. Yeah, I've been over to the to Sanjum's offices a couple times. Uh it's one of my favorite destinations in Berkeley. Um but it's been too long. >> We go to the new office. You have a new fancy office. So we should meet. >> Cool. >> Do we expect anyone else joining from Berkeley? I am not sure. I mean, we can get started and if people join, thank you. >> Okay, cool. Um, well, thank you everyone. Uh, to to the new faces, uh, Archa and Urkan, my name is Scott. I'm a co-chair on this ZKP task force alongside Mitchell. Um, before we start, just have to point out the antitrust notice. Um, and perhaps we can just do a quick round of intros. Um, my name is Scott again to be redundant. I'm with a company called Realize. I work on privacy preserving biometrics and ZKPs are a passionate area for me in that in that context. I'm so happy to co-chair and very excited to have this conversation today with with you Berkeley folks. Um, pass it to Mitchell. >> Hey, I'm Mitchell. As a co-chair, I guess I I do privacy and decentralized AI research. Um, [clears throat] and I've been following the first person project for over a year now and contributing to the um trust over IP stack. And of course I've read the the paper which is now um the proof of personhood paper that's a root documentation for the um working group have have a few other hats but yeah that's what's important here. Um maybe Ara if you want to >> Yeah. So hey uh yeah I'm Ara I'm a research scientist working in cryptography I I mean I was a a posttock at Berkeley which is I guess uh I get uh included in the Berkeley team but I'm like now a cryptographer at ZK bricks which is a small startup working knowing cryptography things largely so yeah I I guess uh part and got in touch with Dr. sort of got us into uh the whole first person project which I think has been like a year now that we've been working on it. So yeah, excited to hear uh criticisms and questions uh about the work. >> Awesome. >> And uh yeah, I think everyone knows me. Um, so I'm just here I'm also trying to monitor the other task force meeting that's going on at the same hour. Uh, just but uh but but I'm mostly going to attend to this one because uh I just been looking forward to getting the uh connecting with the Berkeley uh team who as Aracus says has been working on this uh uh problem space now for gez 18 plus months. So, uh, now that this task force is going, it's great to have them, uh, uh, to to connect in and and, you know, connect antennas here. So, let's [snorts] that's all. Go for it. >> Cool. Uh, would you like to introduce yourself? >> Yes. As I mentioned, I'm a post of Sanjang. So I work on cryptography mostly like both quantum crypto lately and I wasn't involved in the first person project like that al but now I'm working with and others on the follow up of the project that >> oh cool I see Sanjum just joined >> sorry got late just dropping up my kid at school >> good nice to see you would you like to give a a short intro for folks like me who haven't met you before. >> Yes. Hi, I'm Sundum. I'm a professor at UC Berkeley. Uh I've been uh working in cryptography for uh around two decades now. Um yeah, very excited to to learn the problems. Uh was very excited to hear interest in our work and so um would love to know what the problems are and uh talk further. >> Awesome. And I think we got Dennis and Eric and we are have gone around the horn. >> Uh yeah, let me let me do that quick one. Uh so I'm Dennis. I'm the like working in the cryptography space. I'm a software engineer who is working in the cryptography space from like 2019. Uh yeah and like last five years I believe I'm digging into the GP. Um that's it. And I believe I met once Bartley team already. Yes. [clears throat] >> Hi everybody. Uh my name is Eric Drury. I am uh I'm with Trust OverIP Foundation. Uh I work uh as an independent consultant in digital trust and digital identity mostly in the telco space these days. And um I've been following the first person project and decentralized trust graph for a while, but I can't make those calls because I' I have a conflict and uh this is a call I can make and I'm um uh interested in keeping up with what's happening with ZKPs and so this will be a a learning experience for me. I'm happy to to to be here. >> Cool. Well, thank you everyone. Uh to kick it off, thank you Berkeley folks for for joining us. Um we really appreciate it and we're happy to adjust the time to accommodate you. Uh the goal today is I guess I'll call it simple. We'll see how it plays out. Uh we want to agree the first proof we're going to build the path to build it on and get your read on both. Um we're working on a prioritized list of the proofs we need. Um Mitchell's got a concept. Well, we've been calling it a cookbook. uh and and today would feed straight back into that. Um the steer that we took in the past couple of weeks that I think makes this call particularly exciting is we wanted to stop just kind of talking conceptually about ZKPS and act in the abstract and rather than that pick one real proof make it real for a real credential and actually build it. Uh and in that spirit we actually have something to share. um the the first proof that we could talk about ADR00001. Um did my did my intro make sense or any questions on that before we start walking the agenda? Cool. I will put this into the chat. Oh my god. Come on, buddy. So y'all can follow along with the uh link I just threw in the chat there. So Glenn wrote up um ADR00001 and it's a community anchored proof and the thought is this could be our first target. Um the scenario is relatively simple. Nia wants to access a to a restricted project and the rule is somebody already in the community must have a working relationship with you. Uh today Nia can prove that can only prove that by handling over her credentials which exposes exactly who vouched for her and hands the verifier something that recognizes her on every future request. So what we want instead is for NIA to prove a member of the community has a working relationship with me and I'm also a member where the verifier learns yes and nothing else. Um and we we picked it because it seems small enough to build. It's already described in the credential spec. So implementing it would be conformance and not just inventing something new. Uh and it couldn't be quietly faked by just disclosing fewer fields. Um and then the hard part is that third clause as we see it. So Nia has to prove that the person who vouched for her I should be sharing this. Sorry. We have um uh Nia has to prove that the person who vouched for her is also a community member while the person is offline and never asked. So the question to the Berkeley team on this one is does proving something about a third party's credential like that sit cleanly in your framework and is this does this feel like the right smallest first proof to build? Um I can let the others chime in as well. But yeah, so this is in fact one of the motivating things for the starting of this project specifically with the Linux kernel folks that was sort of their use case that they had. Uh so while this explicitly is not what we do in our like existing paper like the followup that mentioned that we're working on does exa exactly tackle this problem and like it's it's modeled a little closer to what Glenn has done mentioned Glen Gore at Affinity is doing uh the stuff that they're doing where they have like a VTC and so on it's modeled more closely to that but yes this is exactly sort of the use case that we're looking for in uh and then >> so let me elaborate here a little bit. So I think uh just using ZK proofs on top of it uh has a little is a little more complicated because you have to prove oh someone vouched for me and then I signed off on you. So you could have like a sequence of steps but because they have this uh uh helper as we are calling um the the the agent for the community uh and and this agent can be present and kind of verify this stuff right so I can go and and show oh here's the person who voted for me give me a signature that I'm part of the community now of course this destroys any kind of privacy because you have to go to this and hand over the person information about the person. But you could for this specific task uh do it in such a way where you've proven zero knowledge that someone has convinced you and you get like a blind uh signature on your own identity if they did uh vouch for you. So you get the similar kind of properties that ZK would have enabled but limiting by paying this extra cost of this kind of agent being online and you having to communicate with this agent. Uh so that's the the the system that we're currently building that we anticipate is going to be practical and so on. Um >> so a couple questions. So that would use like a connection with the VTA. So the verifiable trust agent is acting as the verifier in this kind of circuit that [clears throat] is being generated about the graph. >> So I'm forgetting the terms when you say VTA for the community, right? The >> so a VTA is a verifiable trust agent and a VTC is a verifiable trust community. But the agent sits one layer below and I think this is the role that you just >> Yeah. Good. So VT VTA for the VTC. Yes. >> Yep. >> Yeah. Exact. I was going to say the same thing. Yep. That's right. I'll note just because it comes up sometimes folks will go to the shortorthhand of talking about the VTC as it's taking actions and whenever they say that they mean the verifiable trust agent acting representing the VTC >> and so >> yeah it's a VTC uh there um Scott not DTC >> yeah wow direct consumer Yeah, but it's always the VTA. So every node in the trust graph is represented by a verifiable trust agent VTA. So whoever is dealing with whoever, that's always VTA to VTA communications. The VTAs might talk to other things. Um but when they're communicating, you know, with with other nodes in the graph, it's always VTA to VTA. And it's always using what we call trust test. Got it. So, and the way that I really en enjoy the structure is that we can then put a VTA in the role of either the verifier or the witness. And I think that is what the direction of the cook or the book. Um, I'm calling it CK book. Uh, now in the spec document is trying to identify is like what who needs to be what role based on the relationship and then have a bunch of constructions that I'm kind of like half pulling from the personhood paper um and then repurposing them with the new spec. Um so maybe this would be a good point for me. I I've done some preparation in terms of um the CKP TF question reader. Um it will look like a lot. Uh I suggest it's more a homework. point your agent with your context at it and answer the questions and get back to me asynchronously. Um Oh, you want me to share? Yeah. Yeah. >> Yeah, I figured you would. I could. >> Um, okay. So, a couple things just in terms of status update because I I like the way that this conversation is leading into that. So, let me get the the reader up. Um, so yeah, this is a HTML which kind of like paths us through the the working group, but I'm going to kind of gloss over it and many of the questions here. Let's like pick the ones that we can grab understanding on straight away based on the overlap of where our head spaces are with the VT um, a VTC and the different ways. But here's kind of a review um style approach. Does does that sound good? Are we we could good good to go on this? Okay. So, which part of the framework generalizes beyond personhood? Um I think this actually comes up with the conversation we were just having. Which definitions of security results if a person credential is to replace with the general membership? So, it has implications and it has the way that we've changed um in the spec here. >> Okay. No comments. Um so I guess I I would say that the the the first person the first paper the proof of personhood paper was I guess the first step towards this where the f the proof of personhood focused explicitly just on credentials and VRC's and just proving relationships and showing that you have a bunch of VRC's. Uh we didn't do the membership of community explicitly. we didn't model it and that's sort of what we're doing in our follow-up work and hopefully we'll have that public uh soon. Uh so that's that's sort of what captures I guess the use case that you were discussing and as Sanjun sort of elaborated on the stuff that u capturing what affinity is trying to do but you know adding a privacy layer on top of what they're doing right now. >> Okay, cool. Thank you. I think that that answers that pretty clearly. That's why I kind of wanted because we were already running through this information. Um, which credential objects and predicates are mandatory. So, this is again in the um what Glenn shared. I I have some written down for objects that I think would be mandatory in in this sort of construction or structure. one is like the membership credential and then the other is the VRC or the bouch. Um there are two things that I would like you guys to provide comment on and that's the um inclusion of the like selective disclosure and freshness policies into the spec. Um, and I know I'm kind of throwing random questions, but um, what do you think about these two terms in terms of us including that in the spec? Does it have overlap with the progress that you're making as well? >> Uh, could you elaborate a little bit on what these mean in the context like selected disclosure and freshness? >> Yeah, so freshness I'll start with. Um that's kind of where once one of these presentations happens um it the information kind of experiences diminishing returns like you prepare the proof or the declaration of your place in the trust graph or the membership and then after that moment it's not as fresh that information or like the composition of the proof. Um, so it's kind of trying to add a ceiling to some of our definitions around those expressions. Um, and then in selective disclosure, it's more around um, less so for the Linux kernel project, but more when you want to share like a portion of a more private um, graph rather than uh, sort of your place in the in the whole maintainer um, verifiable trust community. hand up. >> I'll go if you want to respond. >> Mitch, what can you explain a little bit more about um what how you contrast selective? Usually I see it as selective disclosure. You have selected disclosure. Um but how that contrasts with uh just a zero knowledge proof um that you're what is the difference you're after there? I think the the difference around the Yeah. So, I also read selective disclosure cuz that's in our language all the time, but they say selected disclosure. So, I think it's more related to the um comment we had earlier that it's not necessarily a CKP. It's like a disclosure. um of the membership credential. So that sort of >> um >> perspective within the graph >> I guess. >> Um yeah, I guess Nicholas has a question and maybe I have a couple of follow-up questions. Um >> yeah, what my question is probably something similar to what you're going to ask. I was just going to ask about how you specifically uh calculate the freshness policy. So, in terms of freshness, that I think is something that we've put on the table as a um like a drafting rule in the spec to try and include a number, but I think it's actually under the um governance of the the type of um selected disclosure or the proof. So yeah, that also follows up to the question that Drummond had. I think selected disclosure is just a weaker term for the type of zero knowledge proof that's being presented. >> So by freshness, sorry uh u to jump ahead. Do you mean like sort of an unlinkability property that I use my credential or I use it again and you want it to be unlinkable across the users? >> Yeah. >> Yeah. Typically that can be done. Yeah. So ZK proofs provide both of them uh uh in the strongest possible sense that it's forever fresh. So you don't have a freshness policy and you can do se selective disclosure whatever you want. It's really a question of efficiency of whether what setting you want and how efficiently that can be done. Um and that depends on the exact uh statement of interest and uh and so on. But in most cases presently I would say yes you can do it. >> So the only one caveat I would add is that where it doesn't hold is we have this in the paper we have this thing of like when two people interact within the same context they're like deriving pseudonyms for that interaction and that context. So if the same two people interact again in the same context the same pseudonyms are derived. And this is >> something that we sort of did. Uh and so there if the s those those two parties in the same context interact twice, they'd be able to link those two interactions. Uh which is not it's not an inherent issue with the system. This is just how we designed it. Uh and so on. But if this is something that you want to be able to say, okay, even if they interact uh together, they shouldn't be able to figure out that they previously interacted in the same context. That's something that can be incorporated, but it would need some additional mechanism to make that work. But right now, that's probably the one caveat where the unlinkability or freshness doesn't hold. Okay, that's clear. I think that's also the gap that once the Linux kernel more open community test case is shown will be what we need to to navigate when there are more private cases. So does the directed identifier reuse suffice for chosen disclosure policy or is an issuance time linkage proof required? >> Uh is this exactly the pair wise uh pseudonym that we were discussing? >> Yeah. So it's the house with no names is the term um where once you're sort of pairwise in the um verifiable trust graph there isn't like a a linkability. So I think this does I guess the question focus here is around the the offline linkages. Can you explain this a little bit uh further Mitch? Um, I'm trying to decipher what the issue is. Is it that the voucher is offline? And and so so if the voucher I just I'm I'm working through the scenario. So the holder is going for instance to the VTA or the VTC and representing or or or showing a credential or providing a proof of a credential that someone else has vouched for them within the uh um trust community. Is that right? Is that the scenario we're talking about? >> Yeah. So, it's the QR code style exchange with an offline no access to a um BTA. >> Okay. But I'm trying to understand is it are you is the if the holder is providing a proof I guess I'm backing all the way up to what credential are we talking about providing a proof of here. >> You see what question I'm asking? Is it >> Yeah. >> that you have a relationship with another member of the community? >> I think so. Yeah. The VRC's are present. >> Okay. So, so if you have um uh you know, I'm I'm going to say Alice uh has a uh a relationship with Bob and and Bob is a member of the community that Alice is wanting to show prove she has a relationship with someone else in that community. Um this is this is like the Linux kernel situation. Then the question I'm I think the question you're asking if Alice goes to the uh uh Lennis Colonel community VTA and says uh I've got three other relationships in the community. Here's um here's proofs of those three relationships, but those other three uh members are not online at that time. Is that is that what you're >> Yeah. with the offline storage of that community or state, >> right? Okay. So, so is the essential question how does the VTC handling being able to verify or the the VTA agent for that VTC? How are they handling the uh verification of the of the uh signatures on those proofs? Um if those members are offline, if their VTAs are offline >> um uh so I I think it works offline and like just the simplest case, let's think of the non-privacy preserving version where the communities like VTC's VTA I guess issues you a signature. Uh so I like the now as a user I get a signature. My VTA I guess has a signature. Now I three people vouch for it in the non-privacy preserving version. I collect three signatures. I go back to the VTC or the VTA of the VTC and I just give them the signatures. They can verify the signature. The the people who gave me the signatures no longer have to be online because as long as the signature verifies, the VTC knows that you know I was the one who provided the signature otherwise somebody's being somebody's forging my signatures. So th those VTAs no longer have to be online anymore. Once they give me their signature, they can completely go offline. There doesn't need to be an interaction with their VTA anymore. So this this kind of thing where nobody has to be online after that. Well, so the only thing that has to sort of be online is the VTA of the VTC. What we're doing on top of this is adding a privacy layer, but the the flow of the interaction would still remain the same. Okay. Yeah, that clarifies it. And I think that makes sense with when we think about the VTA bomb infrastructure, the VTN. Um, like we can keep that online. I was setting this up the other day. Uh, where are we? Um I think this is more of a like per use case uh question followup and it connects to uh this work that I was um sharing earlier where each of these uh different cards or records within the spec of sort of types of of the proofs and that's extracted from the paper. So, I'd like to just share that with the group. Um, it's within this CKP spec repo. Um, and it is the first pass at the spec upt version. Um, so yeah, I know a bunch of words. Uh but this was the source documentation I used for building the questionnaire. So I'm hoping that like a lot of the responses I can then integrate and feed into um the spec. And you can see book of CKPS is at the bottom here which is kind of where I see the collaborative side of this going. um if that's possible, but we can continue if this is relevant. Um and we find this constructive. I'm just going to pause cuz uh I'm going a bit outside of the agenda now. So Scott, if you wanted to jump in and pull me back, you're welcome to. Uh, well, I liked I liked capturing that idea that we could use the ZKP spec as a sort of playground for collaborating. You met with the Berkeley folks on the call. >> I mean, this one. >> Yeah. Yeah. Yeah. Um, cool. Well, the the next item we had was the construction selection. Um and so that was the idea there was how we actually build it. We have the the four candidates on the table. Um hand roll long fellow circom if I'm saying that right. And then we just learned about world's prove kit. Um, plus the trusted setup ceremony and non-interactive questions. Um, so was looking to have uh Dennis and Mitchell uh kind of walk through those and have the Berkeley team react to it. >> Yeah. So, so this part I don't know if you guys saw the proof. Come out last week, but it's actually kind of interesting. So kind I wanted to sorry it's not on the domain as well as it's prover.kit. Sorry, I'll find it. >> There it is. proofkit.org. I'll put it in the chat. >> Thank you. This came out last week um from from world and they were able to reduce the size. Uh thank you. And I kind of wanted to get some reflections and feedback and commentary uh from you guys on this system cuz from my first read it's quite cool and nifty and could be useful. Uh but is it directionally good for the trust graph spec? Uh is this another option? Um yeah uh we've had conversations I know Dennis and I and um Scott have had conversations around sort of the different tooling around this and I know that yeah you guys presenting tooling as well. So maybe let's open up with that conversation. Um so I I would say first to preface I'm not like the best place to answer exactly which ones uh to use. Uh but so the one thing that we did do was uh in general when you write out your predicate or any constraint that you want to prove one way is to say okay look this is my predicate I'm going to go to like the best ZKP tooling and use that and this is what I get out of it. What we did was try to have a more custom ZKP that that was more targeted towards the kind of predicates and the kind of application that we were building and this is true of sort of the personal paper and the followup which is specific to the Linux kernel thing which is not to say that one can't use the generic CKP solutions that already exist. Uh we wanted to see if like because there is an over because it supports everything. There is an overhead in using it and we wanted to see if there was something direct that we could build like the at least for the proofs of personhood and so on. It was like an unoptimized you know just to see if it works out. It was an unoptimized implementation but uh yeah it could be made better. Um but we also didn't I guess compare too much with the newest ZKPs. >> Yeah. So let me add there. So uh in kind of uh the moment you get to choose all the cryptographic components of the system, you get far more efficiency uh um and you can use kind of build stuff that's simpler. um uh [clears throat] you don't necessarily have to go to arbitrary computation proving that and so on and that's what we did there as said uh I looked briefly at the um proof kit that you shared. So what this does is it allows you to do client side proving while offloading a significant chunk to external server. So this can be really useful if you wanted to maintain user privacy as they're preparing their proofs but are on computationally weak devices. So um these are kind of like but then you need like a server to do the computation and there's communication cost and so on and it depends on uh uh your application. If that makes sense then then great. >> Uh um it doesn't necessarily have to be so kind of two dimensions. one you if you control your crypto you get to choose your proof system build and choose your crypto around the proof system you get efficiency in every aspect but if you can't choose your crypto like you know maybe the signatures the credentials that you're proving are coming from externally then you sometimes are forced into using uh arbitrary uh circuit stuff and now depending on where the proof is being done and how it's done proof kit could potentially be a a good choice It's really helpful. Yeah, because I think that's something that this like task force identified fairly early on. Um what's that note about I guess handrolling the circuits uh in order to make the choices yourself and whether or not or how we were going to manage that that list um of recommendations depending on the trust's purpose um and that's where the idea around this book um came to. So yeah uh thank you uh for that feedback. It's really helpful in that direction >> and like just a note like to to that one. I believe in our use case we are in control of our crypto suits. Yeah. So like so like we not linked to some pre-exists issued credentials etc etc. Yeah. This means like we are should be flexible here in terms of the structure and the signature schemes etc etc which could be efficiently calculated in some zip schemas. And I believe like like ju just one like in one one more word like to what the sanjam said uh it's um so it's kind of clear that when you have the some specific problem using the custom tooling you could uh create the most efficient uh solution for that one in terms of the GP schemas etc. Yeah. and and that actually relied on the like what the tooling you will use uh for the ZP and especially in custom but that comes with a cost of the so so so the problem is kind of clear use some domain specific language or whatever like some general purpose uh ZP schemas which actually will allow you to easily create any logic or whatever like what is possible like to create to cover your problem any problem most of them. Yeah. Uh or create the most efficient using the custom tooling where you will need to you know like some time to actually probably create some tooling for for for yourself but that will be the most efficient for that specific problem. >> Yeah. Uh I agree and I think this is why we sort of uh laid out the construction to be modular where we said you know you do all of this and then you add ZKP on top of this and here as you said you have a choice whether you want to have it be something custom uh which would take more time and more domain specific knowledge to build something that's custom which is the best optimized for it but there's nothing that stops you from using an off-the-shelf CKP to use it. It might just be slower, but it's still an option uh to use. Yeah. >> And do you think that that trade-off sits in I guess the governance of the verifiable trust community or is it lower? Um, I I would think it's lower, but uh, >> but yeah, I >> I guess the question is, is that something that the community chooses or and then adopts or would that be something that you could choose as an individual within the the community, the sort of different um, techniques and constructions? Um I mean in theory you could choose but this becomes uh like as the number of choices increase that becomes sort of unwieldly for uh the other parties who have to support all of these. So uh at some point it does make sense to limit uh if not just one maybe a couple uh choices and then keep it at that. Yeah, Sanj. >> Yeah, I think the most critical uh choice is in the choice of the uh signature schemes that are used to issue the credentials in the format that's used because that's not changeable. it's not changeable in the sense that once you issue the credential if you want to change it you have to go get everyone to get like a new credential or so on >> with the ZK proof it's easy to switch right so what you could do is like just a software update uh if you're using an older version of the software it's fine a server can support an older version of the software uh so there can be backward compatibility in that sense and you can switch to a new zk proof you find bugs it's okay it's it's not a concern you can fix them. Uh but the if you have to have everyone get a new fresh credential that's a challenge. >> Exactly. I believe we like we lived and note about that on our early stages when I mentioned that actually this signature of the credential is strongly linked with the ZP schema after. So means like we like we limit it to choose the signature scheme of the credential first and based on that it will lead us like to what we could do with Zik. So like it's a little bit different angle but like like because of the same idea. Uh only sometime like just a note about the CP switching like I totally agree but probably with one exception which like this bother me but I do not know the good solution or probably like it will be good like if you if you will put your head on this as well. Uh what is bother me it's about the um postquantum resistance uh means like you know like if we choose initially if we choose the KP schema which based on the pairing pair p parenting best uh curves yeah means then even if you will switch like that moving forward means the previous proofs will be compromised and you got my point. Yeah, like this is and especially and especially to the signature schemes of the credential as well. But you know like like it's applying to like the thing the same thing for the signature scheme but with one exception that if we talking that like that credentials will be shared only through ZP manner then probably in some use cases that signature could be not quantum resistant but ZP should be but hopefully you got my point yeah it's kind of little bit like not not really safe but if you're sharing only through the ZQP then probably signature is not so problem to be the PQC resistant in this use case. [clears throat] Yeah, that's a good question. I mean like if the signature scheme has to be postquantum if it's not postquantum uh potentially all bets are off and the post one to hold. Yeah. So yes, that choice is critical. Uh if you want postquantum resilience, you have to choose a scheme that's going to be postquantum resilient. And uh if the choice is made something that's pre-quantum now just because it seems easier or something, uh then there would need to be a switch where everyone will have to switch from uh the known postquantum to the u postquantum. um [clears throat] to add, I don't think the ZKP being postquantum by itself will mask the fact that the signature scheme is not postquantum. So for this first use case that we're looking at is the I mean is the approach then to to choose a signature scheme first or do you have to go through the whole sequence because Sanjam you said it would be a sequence there might be a blind signature at some point and then and then the ZKP on sort of different hop. >> Yeah. So here's the question. Is there a desire for things to be uniform or is there um sort of like an understanding that look different applications might have different use cases and so maybe signatures might need to evolve and so on. Um because I if we're envisioning kind of like the proof of personhood kind of use case then we're looking at now the community use case and so on. As we kind of writing papers we're interested in new cool stuff to do and efficiency. So we are happy to cook up new schemes right so that that's uh we don't necessarily carry baggage as we do the research uh now what's the optimal scheme that works with all of them uh is a question that has to be figured out I guess apriory um but if there are like other use cases then you know that might affect the change in the signature scheme now obviously this is not something that you know you can figure out all the use cases infix so there's the question like what is a good enough scheme I I'm not sure if we have tried to answer that question again if you throw in the question of postquantum that becomes trickier um we can go back to the drawing board and and think about that question if uh that's a in our experience BLS has has worked well in general but we would have to double check uh >> which one which >> BLS signatures have tended to work well for a lot of the applications But you yeah in this case like archive where do we stand? >> Yeah I I think BLS has worked but yeah I don't know the answer like this I don't have a more detailed answer. Yeah, >> this is >> we're looking at some other ones more recently which are better for the community membership like point centers right right >> there are other ones which are working better for that uh we don't have the exact uh u of like rough numbers which isn't ready for kind of public use in that sense but um >> yeah I guess >> I think the the BBS signature is uh the BBS signature I think is nice it's also standardized And I think it's uh it's relatively well supported and I think there is uh some ongoing postquantum proposals to replace like PBS in a quantum setting. So if it comes to that that's also something uh one can look at at some point. >> Yeah, that's Dr. made another great point that there would be a desire to choose something that's broadly interpretable with other things as well, not just in this setting. So um that's a good point >> and >> yeah Drummond says that we need broad interoperability if in the chat I mean and then one of the I mean the reason that this first well this first use case was chosen because it seemed to be fairly simple and it might be a good idea to look at that one and and figure out where the tradeoffs are. uh if you know if you make decisions specifically for that use case where will that not work in in broader uh use cases. Yeah, I think we do need to take a bit of a crypto agility approach to the quantum signatures um in this broadbrush uh trust graph ecosystem though because there'll be different ways that people want to express um their their trust graph in terms of the credentials where they sit. um are they going to have uh sort of proofs that sit on on blockchains or are they going to use the trust spanning protocol? This sort of thing. So I don't know this just pulls on another one of the threads that I've been working on. I last week hosted um a like postquantum crypto agility workshop in um GDC and we're actually starting a competition um around what like a NIS style competition for for blockchain and I see a similar problem going to emerge here where different people have different um desires and unifying might hard task um in terms of choosing the postquantum signature. So yeah, maybe a crypto agility approach would be better. But that's just to share I guess the counter argument to what everyone desires from yeah this next three years of of those choices. The blockchain community is also by the way facing a difficult choice in terms of the choice of the signatures where it's not going to be one signature for everything. They're going to be aification of multiple signature schemes being used for different aspects. So >> yeah, that's sharing that point and people are arguing a lot [laughter] about that in that community at the moment. So we have to be aware of that it will probably emerge here too. um depending on the use cases obviously and the way that people are presented with the types of of proofs and signatures that we align with the credential spec. Um Scott, did you want to go back to sharing your screen so we can finalize the agenda? I'm just noticing time. Um, and if there's any sort of like action I've got a few I um actions I guess that I wanted to quickly present before we close. >> Yeah. Yeah. Yeah. Um, this might be the most notes I've taken since college, but it's been awesome. Um, uh, let's see. I I figure we can just switch open items to the actions. What would you like to capture? Um, I think like the the structure of the reader, um, I'm not completely sure it it lands in the working groups as well as I thought it would. So, if um, people could find asynchronous time to view that and see if any particular questions um, occur and provide response, that would be really helpful. Um so then we can yeah use that judgment to inform the next steps of the spec creation. Um and then the other action is or the the question and request from the Berkeley folk is uh this new paper that you you've suggested um perhaps we could have a followup once it's it's ready um in order to I guess socialize that and the use case around the Linux Linux kernel and the if that's more specific or if it's going to answer some of the questions that we have as the spec document emerges. Um, they would be my two. Cool. And then I think just what Eric noted, we were originally wondering if ADR00001 should be our first proof and the argument that maybe it's too simple and could pan us in a corner. Does that seem like something we want to track here? >> It does seem like it would already show highlight a bunch of u design choices. So I don't see it as being too simple. >> Okay. [clears throat and cough] [snorts] So what you know going forward is is really the focus going to be on this use case of sort of dissecting that and and looking at the flow and and looking at design choices is that how we're going to use this this task force or is it broader than that? Yeah, I think uh we wanted to start with that magnification and then bring the ideas in and then go broader. So that it's definitely a good read on it. Um but I think we've practically got all of the tools and things that we need for the first proof already. um unless there's changes based on um I guess uh what comes out next. So we might might be that's that's kind of why I took the next step of going broader to trying to present the spec and greater questions. Well, what we what we do want to do is start um you know continuing to add sort of the proofs and prioritize the proofs that uh we need. That's why that that very first proof is uh sort of essential for um the Linux kernel community use case. Uh and I think I suspect we might get a couple more coming out of that because that's our highest priority to uh uh to deliver on. Um but then as we start you know working outward into the other uh sort of core use cases the idea is that we just maintain this uh that this task force maintains this list of the highest priority proofs that we need uh as as input to you know this question of of how we hit this trifecta of you know interoperability, high performance and and you know reliability that we've been discussing in the chat. And then so as we sort of construct all the um the artifacts or whatever around a use case, it might point us in directions and say well this use case is really about privacy and this use case is about you know something else speed or or or something. Um because then yeah then we will have to ex um look at different families and different uh schemes whatever. >> Yep. >> Agreed. >> Um cool. Well we are at time. I will be posting um a summary of all of this and I figure we can stay in touch on our signal chat with the Berkeley folks to keep developing uh the the conversation and where we go with this. Um thank you very much everyone unless there's anyone else wants to say anything else. That's that's where my mind's at right now. Learned a lot. >> Yep. Thank you. >> Yeah. Big thank you to um >> Thank you >> T and Araca uh and everyone for for uh >> joining us here on this uh uh journey. You can see we we got you know the ratcheting up and in terms of the urgency of of making decisions about what we're actually going to be uh implementing. So thank you very much for taking the time to to join up with us. >> Thank you. Khan. Yeah, every everyone >> really appreciate it. Take care everyone.