TG ZKP Task Force Meeting - 2026/08/11

Hello. >> Hey, how are you doing? >> I'm good. I'm so much really not on the move today. >> Oh. >> Plans changed, so. All good. Should be able to present. >> Cool. Well, you might be presenting to me. >> [laughter] >> Yeah, I'm not sure um if we have the the pick-up from the community of trust over IP yet. But I think if we if we keep cooking and produce some things that will will be really relevant. Um but we yeah, we should give it like 5 minutes. >> How was Scotland? >> Scotland's beautiful. I really love it. Yeah, it's yeah, you can kind of go anywhere and there's like a little bit of history and a little bit of the birth of civilization just here and there and you can I yeah, I went to a lot of museums and a lot of um sort of locations of cultural significance, which was really cool. >> See anything William Wallace related? >> Yeah. >> Awesome. >> And I went to like a little island called Iona, which is this um known as like the birth of Christianity in the in England or in the UK. >> Wow. >> So, that was cool. Um Yeah, a bunch of Celtic stuff as well. That's going on. It was like a lot. We had quite the big itinerary planned. So. >> And you like were able to achieve it all or not? >> Uh not all of it. Some of it was actually blocked by um the fires that are going on. >> Oh, wow. >> But otherwise um >> Hello. Hi, this is because >> Hey, how are you? >> Hey. Joining here for the first time here. Just uh want to understand what's going on. >> Great to have you. >> stuff. I heard you guys uh in the in the big meeting that we have, you know, with uh Drummond. Um but >> [clears throat] >> uh thought I would join over here to see what what we're doing. >> All right. >> And if I can help. [clears throat] >> Well, wonderful to have you. >> Thanks, Scott. I think we have met before. >> I'm blanking. I apologize for that. >> Yeah. Uh you were joining you were joining this Trust over IP Foundation stuff. >> Oh, okay. Yeah, yeah, yeah, yeah, yeah. >> Yeah. >> Yep, I have an email from you. >> [laughter] >> Or your address is in my in my Outlook somehow. Got it. Well, Mitch, would you like to start at this point? >> Yeah, um quickly letting everyone know about the antitrust policy notice. >> I I will I will do my procedural stuff if you can see my screen. Uh >> Yep. >> So >> Am I recording, right? I think >> Yes, yes, they are. They record as soon as we log on. Uh so, welcome back. This is our third working call. Uh we have the antitrust note at the top of the page. I will be taking notes. Uh and good news heard from both Martina and Mitch that they've both been talking to Hart and Hart says he and the Berkeley team will weigh in on our open questions soon. So, keeping the fingers crossed for that. Uh and today we are joined by uh Vikas. And I've added you to uh the the list here. And um what is what is your background just to capture it and like your um the lens you're looking through as you relate to this group. >> Yeah, so uh I'm very interested in the decentralized uh way of communication and stuff. Uh between uh between any two two entities you can think of. >> Mhm. >> Um I have been involved with Trust Over IP Foundation for at least 10 year uh about like four to five years now. Um I lead a program at IEEE on digital trust. Uh which is uh trying to figure out different ways of uh you know, how uh two uh entities can interact with each other in just trustworthy manner obviously. Um, and what else? I've been in the industry for 25 plus years and was working for corporate world before and especially at Microsoft have have had hand in building some cloud technology stuff especially Office 365 and going into Azure. Um, been working in many centralized applications for for a while you know, so I've directories and and uh and stuff like that uh all throughout. And uh I'm a founder of uh uh this company called Wapplly uh at this point of time uh which is essentially working on the decentralized uh stuff. [clears throat] And the trust. >> Got it. Awesome. Thank you for that. >> Yep. >> Uh so recapping since the last call, uh we captured our B2 working position on GitHub, uh name and track issuer verifyer collusion, uh default to role separation. I filed a couple of biometric side positions on uniqueness and multi-issuer. Uh Jeff Turk pulled us into a credential spec issue about identity linkages and there's a little bit to say on that today. Um, but otherwise a quiet week on the repo and more more work that will be conducting today uh live on this call. And with that, I would pass it to Mitchell. Um, so first up for newer folks and and me for sure as I'm learning, um Mitchell's going to give a plain language walk through of the Berkeley paper since it's our root reference. >> Uh could you cease uh sharing so I can't I can share? >> Yes, I can. >> Are we good? Can you see both side by side? >> Yeah, that's awesome. >> Um is it zoomed in enough or am I >> I yeah, I can read it. >> Okay, cool. Um yeah, so we are basing a lot of the work and at least like the provenance of the ZKP work toward the trust graph um on this paper a cryptographic framework for proof of personhood. Um I think it was like a year odd now that they published this. Uh but high level uh it puts our um credentials so the verifiable relationship credential and the personhood credential um into uh zero knowledge proof systems uh and then identifies some of the gaps that may need to be filled as well as some of the constructions of the zero knowledge. Um so in terms of context setting, I kind of have a presentation here just in HTML which uh explains the root paper and I'll kind of bounce between the two. I know it's like a lot to to read on the screen, but I'll read this side to the right and then navigate the left so there's some intuition when you guys open the paper yourselves in the future as to what goes where and what is important um and what actually is potentially going to need to be discussed and superseded. Um so the paper us well uses Captcha as the um or Captcha as the basis of I think proof of human versus proof of robot and I myself think that it's a good justification, but with AI and agents, CAPTCHA doesn't really work anymore. Um I think one of the reasons and this is like a more personal reference, but I think a lot of and this is something that's, you know, unique actually. Um a lot of gaming companies that uh created these like repetitive human tasks, like things like RuneScape, um are very useful for training data for solving CAPTCHAs. So, that's that's quite an interesting anecdote on this. And why we need to move on. Um So, then the next problem is the MDL passage. So, this was an an event that um occurred in the US where a DMV server um had this like honeypot design where people's uh documentation and details and private PII practically um was in this server that was honeypot vulnerable. Um and it's why we need to hide a lot of these credentials if they're going to be government issue like bureaucratic identity um behind zero knowledge proofs, so they don't need to sit in these honeypots. Um the other context was the Discord case where uh Discord, sorry, um case which we had like lots of government IDs. Um Worldcoin was also given context here in the paper. Um There were a few regulators over the last couple of years that have had issues with World. Um Japan, Hong Kong, um yeah, they they've had issues all around. Uh and this is related to the mostly that their biometric like orb thing was closed source and this EKP system was also closed so there was like no actual way of verifying and checking the circuits for the rewards that people anyway the the system was incomplete and then they did a massive go to market and grabbed a whole bunch of biometric eyeballs and people are worried about it. Um and then finally and this is one that happens a lot in the crypto industry probably less so in traditional industries but we have like rogue nation state actors like North Korea trying to steal crypto from people all the time and proof of personhood is a pretty important solve cuz they're getting more sophisticated and this includes deep fakes this includes um and I'll just like share this with the group now um like one of the tactics is to try and be hired as a developer by a company and then embed it in the company and then receive credentials and use those credentials to like escalate permissioned access within the company and then exploit when like crypto is vulnerable another like attack surface is called like spear fishing where they identify people who could have access to important keys and then they like invite them to a podcast or invite them to investment interview or something like that and then say at the like 5 minutes before the call oh sorry my like Zoom isn't working or whatever or my I can't do meets and then send a nefarious fishing link with a new meeting call and then you click on that and then download downloads malware and gets your credentials and steals your crypto. So the task force problem statement is if we're going to be adding a whole bunch of personally identifiable data and information that is the root of someone's trust network and social fabric into these graphs into the machine world and cyberspace, we need to like be really responsible that ZKPs are carrying privacy assurances and accountability along the way. So, that kind of gets into the intro of the paper and the context setting. And the opening argument is very clearly existing identity approaches fail at the assurance and the privacy layers simultaneously and better cryptography alone was never the missing piece and this kind of speaks to privacy can't be retrofitted. So, you can't just add better crypto after the system is already sort of built. Um Does anyone need more clarification on that point or do we all kind of agree with that privacy can't be retrofitted? I can expand on that a little bit. >> Could you expand just a bit? >> So, with the way that um in my opinion private privacy systems work is that it's the choices at the start of the way that the data and the information and where the bytes sit that matters the most and if you have a transparent system and then you try and add privacy on top afterwards at one point in time it was transparent so the bytes existed at that point in time so with enough compute you can probably capture most of the information that was available on the internet today in like five to maybe not five in like 15 years 10 to 15 years you'll be able to assuming Moore's law and that kind of stuff Um, capture most of the things that were thought to be secrets um that was retrofitted. So, you have a system and you have like a database and then you encrypt it afterwards and then you put all of these EKPs and privacy controls. Well, you can you can go back. So, um we need two pieces. One is like trust um and this is where the trust graphs and the other is like to have cryptography from the start and that privacy system which is built into our work. >> Thanks. >> Um the paper makes contributions in the sense that uh it as as uh mentioning before, it maps these three qualities of proof of personhood user unlinkability. Um proof of personhood uh the unlinkability guarantees around proof of personhood and their like constructions of the proofs. Um and then uh focus on non-interactive zero-knowledge proofs for the voucherable credentials. So, this is kind of the um simplest and most uh tried and tested zero-knowledge construction is a non-interactive. It's like a growth. Um 16. And then the final is around the um voucherable credential schemes. Uh and we'll get into that a little bit in a bit, but it's where you can have two layers to it. Um so, you have one layer which is the non-interactive zero-knowledge proof and then you have another layer which uses those ZKPs to create vouchers um of things that are true and exist in the proof, but are not necessarily revealed. Um we then have the road map. So, there are three core pieces to the paper. Um Technically, one is the personhood credential issuer. So these are not pieces, entities I guess you could say. The personhood credential issuer. So these kind of start with the universities and governments and like Trust Over IP Foundation and these sorts of things. You then have the VRCs which I think we're all familiar with the verifiable relationship credentials. And then you have the ZKPs which are encapsulated in these three theorems which um are down here in section eight. So here's the vouchable credential. Um this is the third one. So this is the construction of the ZKP which is a graph. And then here is how it becomes how the math is able to then do these vouchable credentials. Um and then there are a couple of uh examples and like expansions that they suggest towards the the end of the paper. On like something that we've mentioned in the group is that uh the ECDSA may not necessarily survive like our quantum horizon. Um so this is giving a It doesn't mention that. It doesn't mention anything to do with quantum stuff, but it kind of says that this is like a ZK-Snark isn't the only and we decided to use ZK-Snarks for this, but we can do other ones. Um okay. Let's get back to the right side. The information. Also, noting that Danny isn't here, Dennis isn't here, but um there's a direct reference to the discussion that he's made in um number 16 uh that is complementary with this paper. Um I think you made a few comments, so I just wanted to surface that if you wanted to speak about it, but he isn't um present, but maybe in the report, we can get a note on that or in the discussion. >> Yeah. >> Okay. Um so, in the text on page 22 21 you get into the personhood articles. And sort of how um these are going to be built. Uh personhood articles, this is kind of related to what we were talking about what where there needs to be a separation between um the sort of issue in the birth file. So, um the PIV article substantiates uh how that is done, and the article creates these sort of attributes that then get filled into the zero-knowledge proof. Um on page 22, we have the one-sided error, which is I think definition eight. Um this kind of proves that the attributes within the proof are um as they presented. Um if that makes sense. It The keyword here is one-sided error. where if any um information from either the verifier or the issuer is incorrect, there will be an error in the in the proofing system. So, E here Let me know if we uh too deep in in the math and we should um move on in this point. Uh but E here is around the adversarial spend for um like the budget of compute required to break into the proof. Um and that number needs to be like scaling. Okay. So, we'll move on to page 27 and 28 for the next. This paragraph is quite good, I think, maybe to stop on before we get there. So, the practical execution in the ideal world. So, in the ideal world, um the functionality of the like user and the unlinkability is true. Um and this is included in the oracles. So, there where each issuer I and oracle O is sampled from the distribution D. So, these are two separate systems, I and O, and then D creates that information and distributes it. This note on real-world execution is around the trusted setup. So, uh non-interactive zero-knowledge proofs um require trusted setup. And just as a note on that, when you have a trusted setup, there's this thing called toxic waste. And toxic waste is where the people who are involved in the ceremony have a responsibility um or an assumption is made by uh the group that the information that they helped create or the entropy that they captured in order to do this setup is experiences amnesia. So, it's um forgotten. And the first example of this ceremony was done by Zcash to set up the snark blockchain and some it's it's known that people such as Edward Snowden um contributed to that ceremony. And the way that it worked was there was a room with like some sort of Faraday cage setup where um people went into the room, saw their seed, saw the 24 um five-letter words and built the key and then forgot the seed. Um and that seed was sharded. So, if people all colluded who were the ones or one of them was nefarious and captured some of that information and saved it, um the whole soundness of the circuit would be vulnerable. Okay, let's go to 2728. Um The impossibility of full unlinkability. So, we've kind of mentioned this, but this is where and in the paper they identify um different scenarios. So, you've got your distinct users, your civil users, and uh what is what we um in the group have already spoken about is that the proof is already always carried with something. Um that's kind of what this is about where like based on the substrate that the information is traveling um through, there can be like auxiliary information inferred um of what the proof is containing. Um so there's this context key request or synonymous request versus the relationship attestation issuance. So if there's a relationship involved, then full unlinkability is not possible because there's a relationship on the trust graph that is known the information traveling and um if the context is everyone going to this festival are all presenting um a biometric proof in order to get into the gates, um the context of the festival uh provides linkability of the proofs between the people um who attended. tries to get addressed. Uh and one of those is to do like nullify work in supporting revocation of the credentials and then reissuing them. So say for example for with this festival example, you go to a the festival one year and then the next year it's the same again. Well, we need to do a revocation and a reissuance um at the gate, otherwise linkability increases cuz you would be able to work out everyone who attended both festivals and then people who attended one or the other. Um and that is information. Um Okay, let's skip a little bit here. Back to 24 and 25, which I think is what I already spoke about. That's the ideal functionality. So, this is kind of like a user journey in the paper. And the user journey ideally is you have credential issuance, you have relationship attestation issuance, then the context issuance, which is then built used to build the key or the proof. And then you have the presentation. Ideally, these are all unlinkable during the presentation, and you can also prove that they're unlinkable. And that's this ideal functionality. Um but yeah, we then went through why that may not be the case. This code here, the F _POP Um FPOP is an important term in the repo that I've been developing, but it's the first person's proof of personhood credential. Um Just as a note, this was defined in this paper, and we're continuing and using that terminology. 28 29, and this is Full unlinkability has been defined precisely. So, if a verifier wants assurance that two attestations come from two distinctly underlying humans, not synonymous of one, it has this distinct quality in in the proof. Which is this function here. So, is the F value distinct from A and B. And again, that is related to this like unlikability problem that we need to confirm when we develop the circuits. Um, we ratified this in A2, the context dependent unlikability. Uh, not full unlikability. And the reason is written A5, which is a discussion around against whom, for how long, alongside what, which I've been referencing in the last like 5 minutes of the chat. Um, and yeah, so the impossibility result is addressed and ratified um, already in our initial working group conversations. There's a discussion on nullifiers and revocation. So, revocation is handled as an example predicate, not in native machinery. So, not all of these these need to have revocation um, built in. We should have that as a question um, in the setup. And for the particular trust task or credentials that we're trying to it would be like, is revocation necessary? Um, because the The was revealed at every VRC issuance the original issuer can recognize the credential later even under unlikable keys. So, here is another I think that's related to the device and the VRC. During VRC issuance the nullifier is always revealed and verified as a part of the VRC. A publicly available revocation list may contain nullifiers responding to revoked credentials. So, that's just another one of these things where information is revealed from the zero-knowledge system based on adding features. Um A6 is answering that question. A nullifier means scoped reuse detection, never one unique human. So, we don't prescribe a a single nullifier to a single human and in part solves uh this problem and that's written in the initial spec document that there can be multiple nullifiers or multiple VRC presentations. Um and that's the kind of the beauty of the system of having this like ecosystem-based proof of personhood credential which is then uh parent to uh um like a graph of verifiable relationship credentials. Life cycle's important. Um I've addressed it a little bit, but I think this is a future work item of the um of the proofs that we construct cuz we do have to consider life cycle management, but for now um we don't have a proof to uh like we don't have a use case. Like uh one example of a use case is um like medical data or um financial transaction data is probably better. But financial transaction data of PII, a lot of the AML regime requires for you to hold on to that transactional information and the PII associated for 7 years um depending on jurisdiction, obviously, but uh that means that there needs to be lifecycle management if being used to prove um like things like KYC. Um this section, so 30 onwards, is most of the math in the constructions. The first is the personhood uh credential construction. The second, you get into the security. So, this is the like the black box graph um string that is produced or the snark. Um sorry. Page 30 to 31 is the personhood proof and then 47 to 49 is the graph proof. Um So, a black box construction, the like way that this works is you have a construction that sits within like a trusted execution environment that doesn't see the light of day, um but it then creates the proof, and that proof you can see that the circuit ran correctly, um and that the commitments were made and the verification um is done. So, uh this is kind of a part of the paper where we uh discuss most about the verifiable relationship credentials and the um vouchable side of things. So, um you give someone a black box and a proof and they can reconstruct it without um you losing the privacy. There's a reference from discussion three in our repo to the proof types and the constructions that I think we should maybe just like I'll I'll just get a agent to make a reference to this like page 47 to pretty much 57 um as a way to answer some of the questions in discussion three, but I think I just based based on the fact that a lot of our um like the notes in the discussion has already consumed the proof of personhood paper. Like that should be implied, but I can double check that in our discussion. Okay, where are we at now? So, this is the final um walk-through slide. Uh 63. We're in references now. Or related work. So, um here is like expansions of the work uh and other protocols that have been mentioned in this paper that attempt to solve. And we have uh connections with some of the stuff like uh the Decentralized Identity Foundation. Um Trustless Agents is the Ethereum 8004 proposal which is actually since um this has been published and is now on Ethereum. Uh and you can deploy trustless agents uh as like they're pretty much identifiers on ETH and they use uh mix of an ERC-721 which is an NFT um token and uh like a trustless what's called a like a ZK registry um on Ethereum which uses proofs to hide a registry. So, all the agents are put onto a particular registry within the chain but then a proof hides the which agent is who in the registry. Um the B2, this is actually also already in the works and it's probably one of the main focuses of the Linux Foundation um work with the kernel at the moment for the trust graph working group and this is the maintainer provenance problem that was the defined and emerged after the I think it was like the XYZ I I might get the acronym wrong but there was an exploit um where someone uh was a civil and got maintainer access to Linux and there was a bit of a scare there which then pushed us in the direction of building these trust graphs to maintain key maintainer status and keys um for open source projects. And so then the final crossover is around decentralized business networks. So, like this I think is kind of implied knowledge with this group but trust graphs fit naturally into these ecosystems that are a little bit more open um and uh yeah, decentralized by nature. Maybe not fully decentralized but yeah, have that in a lot of the the way of working. Uh one thing to note is the paper delegates credentials to agents. While ratified A7 and B8 keeps agent authority as separate separate structural evidence outside the crypto. Um I think this is probably one of the biggest problems we're going to come into and this word delegation. And I suggested in the discussions that we should have opened a like in another thread for delegation um completely because that's probably the keyword a lot of and this is an echo from some of the other working groups I participate in. Um but yeah, having agents with identity versus identifiers, like it's pretty known that we want to give agents identifiers not identity, which means that's a delegation action of a credential. Um so it was written in this paper. However, if we're if we see agent identities appearing and them getting personhood credentials and these sorts of things, uh that should be something to keep in mind of keeping the spec clean. Um I'm going to pause here. That's the run-through of the paper. High-level sort of Mitchell Mitchell's version of what's important and um where goes where. Uh and like maybe updating the context since it was published a year ago. >> Wow, thank you for that. Would you be able to share your um HTML? >> Yeah, I put it in here. >> Oh, cool. Yeah, I see it now. That was dumb. >> Sorry, I I put it in the wrong um I can move that. >> I can move it. >> Okay. Okay. >> Yeah. >> Yeah, I put it in the wrong box. So, this works. >> Come on, buddy. No way. >> [snorts] >> Well, I tried to move it and it didn't work. >> Yeah, I think I need to Oh, wow, you've made lots of cool notes. Oh, yeah, there are three copies of it now. Here, let me just um >> Oh, well. >> Oh, no. It's in there. Yeah. >> Some latency with uh the wiki, I guess. >> Okay. Update. Should be all good. Yeah. Uh so, there's a You're welcome. Let me know like Oh, yeah, go ahead. >> I was going to say, please you guys. >> [laughter] >> Okay. Um the next steps and this kind of gets into um our circuit research. Quick Scott, did you run the repo or no? >> Yeah, I did. >> You did? Awesome. What did What did your agent say? >> Uh I have talking points to read. >> Okay. Do you want to Do you want to get started there? >> Sorry, say again? >> Do you want to get started there or >> Yeah, yeah, yeah, that's what I had next on my agenda. >> Okay, cool. Yeah. I I spent a little bit longer, but I think this is that's going to be good route. Um >> Yeah. >> context for >> I enjoyed it. So, here I'm going to be reading things I I worked out with my agent. Um so I ran the research cycle on the lab this week. Uh very impressive real circuits, real numbers. Um every exploration anchored to our decision doc. And it definitely comes across as Mitch said, evidence not spec, built to be ratified, refined, or refuted. Um I'm not going to get into the refuting right now. I think that's more Dennis or Nicholas or someone um more qualified than me. But the the two positions that I can hold. One was the trusted setup is a lab fixture, uh not a production ceremony caveat uh is exactly the honest labeling our drafting rules want. Um and before we lean on any of the numbers as our evidence, I'd want Dennis and Nicholas to independently run the suites. Um they're not here today, but hopefully we can get them to to jump in. Uh and the method itself worked. I pointed my AI at the repo, walked the path math, and had a position record in about a half hour. So it seems like a real low barrier way for non-cryptographers like me to contribute. Um that was my read on it, and I was going to ask others, but others are not here right now. Um any reaction to what I said? >> Yeah, that's I'm I'm quite happy with that read um from the agent and the fact that you had a machine that doesn't have all of my context was able to run the path and get the result. So really happy. Um it tees us up nicely with the next step where I've built um these as ceremonies. So we can actually use those circuits as like being a part of the trusted setup. Um so one important caveat there is that the AI is not like creating the entropy. Um the AI is creating the the circuit. So in order to create the entropy, we need to have this like um, interaction that the humans do. And that's where trust tasks come in. Um, so I've seen people host like a website and get people to like click in the browser window a bunch of random times at random intervals and that creates a little bit of entropy for people to then have as their signature to tribute to the circuit. Um, so that will be probably a future step where we can all maybe in the group, um, call at the start of the call or everyone who wants to at least, um, points an agent at a browser like a hosted website that is sort of running a 20 to 30 minute circuit and during the call all the like buttons and things that they click um, creates that entropy. Hm. Uh, what the auto research um, produces just to sort of re- reiterate, um, which is great that we are re- reiterating um, what Scott said is it's a auto research cycle. Um, it's for decisions and it's for, uh, auditing. It's uh, not for like creating the proofs. So, it's kind of like one of those things. It's it's like the rubber stamp. Um, so we created the wax seal um, or the stamp before we start putting the wax down and the wax is the proof. So, now we can all go and put our own independent stamp on the the proofs that I created. So, we're at the the readout. So, just like a high-level numbers of what that repo has. Um so there's the nullifier membership, which is 11,523 constraints. Um and this word constraints is This is like part of the constructions. It's where the math Um I'll find one real quick for you. So here is a constraint um in the setup. Um Here is another. So some of these are the claims. Here is a constraint as well. So it's it's practically where um yeah, where the the math constraints itself. So then uh you can get this like determinism of the proof. And that's why we need to have so many. And part of actually the research that I do is trying to reduce the number of constraints through um giving agents uh sort of like pre um I don't know how to describe this. So one of the things that I've been trying to build is if you run a circuit with two agents as opposed to one agent, and the two agents know the type or the uh things that they will be operating on in order to build the circuit, but don't see what the other agent is doing. That can reduce constraints significantly um by like 30% uh if you have one agent that's like only doing the boundary making constraints, and the other agent is only doing the delegation um constraints or other things. Still experimental, uh but that gets into the dual issuer um side of of the circuit, where you have two distinct issuers. And that means that we get this unforceable um, like the unsatisfiable duplicates um, of the proofs. Uh, and then the guardian can uh, circuit is the uh, verifier circuit. So, we have the issuer circuit the audit of the issuer circuit and then the verifier circuit. Um, One thing that I've been doing, and this is probably the next step, is this what I was alluding to before. So, I've actually run I ran this today. Um, These are the These are previous runs actually, uh, but I created this website today, so that's why the date is wrong. Um, but I I was running this over the last half an hour, and I kind of want to set up this hosted website. I'm not sure where to host it. We can ask um, the main working group where people can just participate in this and contribute like their machine to running these circuits as like a ceremony. Um, so then we can just get that practice in place as a way uh, as just an understanding of the people who are maintaining the trust graph um, code base that like if zero knowledge proofs are going to be everywhere, then we should be a part of the community that are responsible for maintaining um, the trusted setup of these proofs assuming that we're using non-interactive zero knowledge proofs. >> Mhm. >> So, um, and I think it can kind of also be like a leaderboard or be like a actual trust task in of itself. If If that makes sense. So, like every week we during the call, we're like, "Okay, let's just like point our agent, put it on auto, and after half an hour, we can see that all of us during the call ran this circuit. Um and then it updates on the website, and then perhaps we can in the call uh to like a real live share screen, "Hey, this was me." Attestation, like a stamp um with our own keys. Uh I think that would be a cool like little activity um that helps with both the education, but also like literally the practicality of it all um long-term. >> What? >> Yeah, so that's where I'm at with this. Um So, that This is the verification registry, which is the next build. Um and the framing is this ceremony as trust task. So, the agents orchestrate entropy, they don't create the entropy, the entropy is created by us at the time. Um but the agent's context is the observer. Um So, the verifier. Uh some Q&A preloaded answers that I forgot to mention in our um previouses. Uh does the paper assume enrollment root across issuers? No, issuer oracles are sampled independently. Does construction two survive issuer verify collusion? Is unlinkability guarantees cover colluding issuance including users with leakage limited to what uh the shown statements reveal themselves. Or themselves reveal. So, construction two is probably the one to look at for that issue of verify collision question. Um, can vouching replace deduplication? So, they're complementary. PH uh so, personal credentials carry uniqueness and VSCs carry reputation. Uh this is our post-quantum question. The constraints are based on um the growth uh and KZG, which is elliptic curve. So, um algorithmic agility is mandatory from um day one, which means that we have to be a little bit agnostic. We can't get locked in to only um one type of proving system uh in order to to maintain that post-quantum um resilience. And this is just the growth 16 justification. Um some notes on the types of proofs. So, these are connections to our existing um work. Awesome. There we go. >> Thank you very much. >> So, I think as my action after today, I will push this verification registry piece into the um the main repo, and then you can build it locally, and you can run a circuit and see if it works, um and it shows on the local 330 uh 3,300, sorry. Uh and if it does, then I think we can discuss in the working in the group working group call with in the greater Trust graph working group call um like how to host this. >> Mhm. Cool. >> I feel like I I lectured a bunch today, but hopefully it was good. >> I'm I'm literally here for it. I'm trying [laughter] to learn as much as I can. So, that was awesome. >> Well, I I was a silent observer, but this was this seems like like a lot of work that you put in here, Mitchell, and and I have some learning to do as well here and you know, so I think I'll get it eventually. Um Um I have to do some reading in this thing, but I'm very interested in this topic right now and and and I want to grasp it and implement it cuz a lot a lot a lot of talk is going on in in the industry about this. Um but there's not much implementation actually, to be honest. So, um Right? >> [laughter] >> Um so so great work, Mitchell, and Scott. I'm sure you guys have been like >> [laughter] >> uh been on it for some time now. Um Um and let me know how I can can be helpful. Um and you know, I'll I can be ears, eyes. I understand the value of this whole technology set. Uh I am uh not a programmer per se, uh but I can go into that area. Uh but you know, so let me know if I can be helpful in any ways and how I how that can possibly Yeah. >> For sure. >> Cool. >> I think the the lowest hanging fruit is to be um when we do run these trusted setup ceremonies to be a part of it and contribute your human entropy to the trusted setup that we need for some of these ecosystems. Um I think that's that's probably where I see um this uh not entirely, but this task force will be around a lot of that governance is is for the trusted setup stuff. >> Got it. Nice. So, uh are you guys going to be in GDC, by the way? >> Yeah, yes. I'll be going. >> Oh, cool. Well, we'll see each other, I guess. Uh over there. >> Yeah, we're running a couple um well I'm hosting a a couple sessions, and there's a session um hosted for the Trust Graph working group, as well. >> Nice. So, and I have a couple of sessions, as well. Um I'm approaching it from more from the IEEE side. And one of the programs I've been running there uh has been on cybersecurity for next-gen connectivity systems, and and uh been trying to put out uh the architecture uh which involves better control for an endpoint um uh decentralized uh way of uh communication uh or or rather the identity and stuff, which you know, leads to authentication authenticated verification, and then uh then also uh more sovereignty of data and and privacy of data, and and third uh distributed uh information, which you know, so once it is stored, it is not like in one single place as such, you know, but it comes together in the context of the of the entity which could be human. Uh but it's not in a single place as such. So, uh so so I'm running a session around that kind of uh concept and and zero-knowledge proof or ZKP is very much part of that discussion there. Uh so, can we can we uh can I reach out to you maybe >> Mitchell? >> Uh I would like to run by a couple of slides with you on that front, you know, that I'll be presenting >> I'm presenting there. Okay? >> Mhm. And yeah, when you reach out do do you need a contact or whatever? >> Yeah. Yeah. >> Um That's my email. Uh let me know which session you're um hosting cuz I'll share back the sessions that I'll be hosting. One of the sessions um is on private authentication and information sharing uh between agents for vulnerability uh disclosures. So, one of the like the agent communication systems I've been working on is for vulnerability um like notice systems. So, when uh cyber security incident happens particularly in blockchain uh where someone's been hacked etc. There needs to be communication systems uh for disclosing that, but you need to be protective about that and now that everyone's using agents um putting a bunch of vulnerabilities into agents to do the communication with you is is risky. So, um that's something that we've been developing in another sort of open source community called begin which we'll be hosting the session. Um >> Okay. >> So, yeah, that might be relevant to your work as well, I think. >> Sure, yeah, absolutely. So, I'll what I'll do is I'll send you an email. I'll I'll write down the couple of sessions where I'm participating. Uh, two of them I'm leading, and one I'm going to be a panelist. They're just putting me in there. Uh, so so I'll send you that, and then also, uh, since we're all going to be in Geneva, there is a UN meeting happening on Friday of that week, same week. Uh, for which I have actually signed up to to actually participate there. And I'm not sure if you're aware, but the UNCITRAL has built something called as a transparency protocol. Um, and uh, and and and their their whole vision and the goal is to to enable cross-border, commerce, uh, of, you know, commodities and minerals and and things like that. And you know, so so that requires verification, and uh, especially privacy-preserving verification, which comes back down to ZKP, right? So, uh, so that's something that may be of interest to you as well. If if it is, uh, and if [clears throat] you're going to be there on Friday, uh, I would suggest you should join that particular meeting you know, so they're they're having. I can send you the link for it if you want. >> Yeah, if you could include that as well, that'd be great. I can justify extend expending the trip, or yeah, staying an extra day or something. >> Okay. All right. >> That'd be good. >> Awesome. >> Reminds me that, um, that reminds me of I there's a story of the first people who, um, sort of used publicly known inside of to trade the stock market of derivatives was when all of the boats with trade used to come in to London. >> Uh-huh. >> They got a magnifying glass or telescope and checked the height of the ship to work out if there was like one level of gold or oil barrels or whatever versus another. And that like I kind of I like sharing that analogy because it's it's similar in the cyberspace world where you just need another layer of magnification on the information and you get a significant advantage and that's like what zero knowledge proof solves for practically is that you wouldn't be able to even see the boat docking up. Um >> Yeah. Yeah. >> So but you would be able to know that the boat was docking up. Um but you just couldn't get that inside of knowledge of like how low or above the surface it is. Um >> Correct. Correct. And and uh the the I'm there's a paper that is getting written over there as well. Uh if you want to join that thing. So there is there's a There's a lot of work going on on that front by the way. Uh and this this this work is very relevant to it. I can see that. >> Yeah. >> Uh >> Trust graphs everywhere. >> Yeah. Yes, absolutely. Um So uh Yeah, we should uh we should chat. I'll I'll send you some information but this this thing is going to be big. Yes. >> [laughter] >> Cool. We are we are at time. I have a couple items just to close out if that's cool. >> Sure. >> Uh so we had I had an item for the probabilistic sampling prototype that Dennis had shared with us. He's not here today so we won't be having that uh discussion. Um also just wanted to for the record uh as I mentioned at the top of the call, Jeff Turk shared a cred spec issue about identity linkages for our take. Um the short version, there's ZK P constructions assume you can prove several DIDs belong to the same person, but the credential model does not encode that linkage yet. And our position is it's a real dependency, not a blocker. And the ZKP honest answer is that those linkages should be proven as hidden witness relations, not exposed as fields, or you could recreate the correlation problem. Uh I shared that as a as a comment. Uh Mitchell, you could obviously go much deeper if you wanted to the construction side. But just wanted to note that for today, and on the call tomorrow, we can share that we had that response. >> Yeah. >> Uh and then the the status in the fan out, um Martina and Mitchell have been pulling on hard, and I think he's telling he's saying he will engage. So, that's exciting. And Mitchell's also chasing down some guest contributors who may be joining us soon. Um I'll let you have the floor for the rest if you have anything else to say on that. >> Uh nothing. I think the I've mentioned it to a couple of the ZK researchers at EF that I've contacts with. Um and they were quite interested, but this was like a a month or two ago um on the trust uh graph implementation of ZKPs. Uh so, yeah, I just need to resurface with that and um follow up. But I think a lot of our sort of guest appearances will probably happen after JDC by the sounds of it. If we're all going to be there, we'll probably gather a bit of a network and can can mention that we're doing this work here, um and then build a bit of a pipeline of um specific knowledge or external knowledge in. >> Cool. >> Yep. >> Awesome. Uh adding that note to the page. Thank you very much, everyone. Um, we'll be in touch. >> Thanks, Phil. Good call. >> Great. Thanks. >> See you.