 Hi, Hossain. Thanks for joining the meeting. We'll get started at the top of the hour. How are you? I'm good. How about you? Glad to hear it. I see the ideas. Yeah. Yeah, we're a little early, but we'll have more people joining. So. Thanks for joining. Have you joined the call before? Great. I've been on some hyper leisure meeting before, but a few months. Great. Nice. Well, thanks everyone for joining. Well, we'll wait a few minutes to get started. Excuse me. Can I ask a question? Hello. Sure. Sorry, sorry. But somehow zoom says that I need a code is, is that correct? And is there a code available? Like strangely, I can join through my desktop, which I'm doing now. Oh, interesting. Are you, could it be some sort of issue with the sign in? Because there, you shouldn't need a code to enter. Okay. I'll check it out. Maybe some things wrong with the way I installed zoom or something. I'll check. Thanks. Okay. Thanks. Yeah. I hope that works out. Everybody. Hi, John. Thanks for joining. Give me one minute char and I will get, I'm going to stop the recording and then I'm going to start the stream and then restart the recording. Sounds great. I wonder. As a backup or resume recording, and I'm going to set char and Tim here. Yes. So that both of you to co-host, just in case they co-host just in case. Something happens to my. Why isn't char co-host. Something happens and I get knocked out of limousine. All right, char. Take it away. It's all yours. Sounds great. Looks like we have. Stephen current our great speaker for the day here. So I'll, I'll pass it off to Tim to walk us through the working group status updates. Yes. Good morning, everybody. Just give me one second here to share my screen so we can kind of all walk through it together. So yeah, good morning. It is June 15 today. And on our call today, we'll be reviewing some working group status updates. And then we also have a presentation from Stephen current. So thank you for joining us today, Stephen. Appreciate it. Quick reminder, we are under the hyperledger anti trust policy. So please just be aware of that. We have a few announcements. We have a few upcoming speakers. We have Nick Steele on the 29th. Stephen movie on the 13th of July and then Dimitri. Zagan doulin on the 27th. So if any of these speakers look interesting to you, please be sure to come on back in a couple weeks. We also have a hyperledger in depth with the red data technology. So that's on June 21, and anyone can register at this link right here. So jumping right in it looks like the hyperledger indie contributors working group met on the sixth. Was anyone able to attend this call. That was I can give a brief update, but I wondered if it also might be useful to see if we have any introductions that anybody wants to make on the call I think we've got, we've got a fantastic group here and probably a lot of new faces to this call. So if people want to take the mic and, and introduce yourself and say, talk about your interest in in decentralized identity. It's going to be a great time. Hi, James camp. I'm the CTO, why are green, which is a virtual power plant company and I think we might use this for by OT device identification or potentially also users. Thanks. Thanks for joining. That's great. My Novak looks like you have your hand up. Thank you. Good morning everyone. My name is Michael Novak, and with the open voice network and been a longtime fan and student for digital identity. I'm very excited I come out of the IOT world. So I see this as being a key technology enabler for this, but also recently may have heard of generative AI in the news at least once or twice in the last 15 minutes. So again, verifiable credentials and digital identity are perfect fit for conversational voice, as well as taking inanimate objects. I'm really excited to check Steven's math today. And I'll run through generative AI don't worry Steven I'll make sure you're doing it correctly okay. Awesome. We're glad you're here. Any other introductions that anybody would like to make. Good morning. Steve Michael is Martin from Boeing, Boeing Vancouver. We also are working on a project to integrate the verifiable credentials and part of our authorization access and identity and access management authentication mechanism. There's a variety of applications to it that we're researching at the moment so this is a fantastic application interested in how this moves forward. So, thank you. Absolutely. Thanks for joining Steve. I'll drop the meeting page link in the chat here. Let's see. Oops. I dropped the wrong link in the chat but I will correct that right now. Let's see, so that anybody can put their name on the attendees list if they would like. So great unless anybody else has any announcements or introductions that they would like to make we could continue on with the working group updates. Sounds like that's about it. I think we left off at the Indie contributors call. Yeah, absolutely. Give us a quick summary of that. Yeah, so we talked about Indie community contribution so discussion about how they're really successful Indie networks, just few fewer code contributors and so perhaps this is because Indie just works well and deployments are pretty specific. But at the same time we have a roadmap of things we would love to add to it and and see implemented so just a discussion about that that I think was really useful and then we also spent time on the call going over open issues in Indie plenum. Steven I don't know if you have anything you wanted to add about that discussion or what we did on that call. That sounds about right. Looking forward to more discussions on, you know where he's going in and you know how we can configure on how to expand contributions. Yeah, absolutely. Awesome. Well sounds good thank you for sharing. Looks like the areas working group met just yesterday it wasn't even able to attend the most recent areas working group calls. Okay, well it looks like they're discussing some wf resolution and did peer steps and unqualified migration stuff if you want more info. These links are will take you right to their notes. The areas bifold group met on the sixth was anyone able to attend the areas bifold call. Yeah, it looks like they're working on an update and discussing some key issues. The areas cloud agent python users group man on the 13th was anyone able to attend this session. Yeah, I was there. Talked about an update on the BC gov code with us. We're working on an update at in DC or working on to update acropi to use the hyper ledger version of a non creds and so talking about the refactors got the MVP of revocation completed. Which was a big step and and the things we're looking at next are the automated registry setup, generic sizing the revocation registry registry recovery test updates cleanup as well. And the the 072 final release and and merging PR is in acropi. Stephen, I don't know if you again have have anything you'd want to add to that summary. We figure out how to unmute. Yeah, 082 is ready. We've got some final things going into that. And then we went into acropi plugins and updates and progress for applying on making stuff and we added a new maintainer project which is pretty cool. All of those are covered there. Welcome, folks to join us at the next meeting in two weeks, two weeks from this one. Sounds good. Thanks for sharing. I believe we've met. I'm not sure if this was the same day as our last meeting. But was anyone at the latest areas framework. Job script call. It looks like they're kind of discussing what the future of areas will look like and how to get started for more details and click that link. Life hyperledger and on crits looks like they met on the fifth. Did anyone attend the non crits call. We've had a couple of meetings. Yeah. Basically, we're moving forward on the stack we now have a mentor. We're also in the mentorship program working on the spec so we're moving that forward and also some super interesting discussions on the 2.0 plans and some of the substitutions of new ZKP stuff which we're going to be talking about soon on this call into an So it's the topics going on in that working group. All right. Awesome. Thanks Stephen. Looks like to IP hasn't been doing too much. Looks like the diff did come spec working group met on the fifth. Was anyone able to attend the, the did come spec working group. Looks like they're working on on compatibility for did come 2.1, and then they're working on some new marketing initiatives for did come. All right, unless I mistaken I believe that is all of our working group updates. Does anyone have any general updates or groups that we've missed. I'm just a quick call out the areas from our JavaScript recently released 0.4 point zero. The team who's worked on that including Ariel, Baron and Kareem are going to give a demo slash workshop on Wednesday June 28. The link is in the chat. It's not really going to be a hands on workshop but they want to really go in depth and all the changes and the new stuff that's in the new release so that's coming up in a little less than two weeks. All right, very cool. Thanks Sean. Yeah, I'll give another brief pause to see if there are any other updates or announcements before we hand it off to Stephen. All right Stephen the floor is yours. Great. Welcome. Let me share my screen. And I'll jump into the presentation. Close that got chat open off to the side so if anyone has comments, let me know. Let me leave that there. Well not quite there because I can't see. There we go. All right, can you see my screen. Yes, it looks great. Thank you. Okay. This is a presentation that I did at the open source summit in North America or a similar one so I'll, I'll, I'm using that I tweaked slides a bit to adjust into it but we'll share them up in the top corner. If you want to there's this bitly di dash the KPS that's the link to the slides themselves so if you want to grab those now or follow along. You should probably put that in chat but maybe someone can. So online identity with verifiable credentials and then we'll get into the meat of it which is the KP using high school math just to explain what the KP zero knowledge groups are so I'll jump in that's the agenda. So brief brief since this is the identity sake there's not a lot you need to know about online identities and then focus mostly on the zero knowledge proof section and what they are. So credentials paper credentials are what we use in the world that's what we've used for 2500 plus years. Many of them are for identity there's ones down here are things like professional attestations professional credentials like you know I'm an engineer, I'm an architect, I'm a doctor or I'm a lawyer those types of things there's supply chain there's certifications that can be for well I guess those are definitely not paper. But there's, there's lots of paper credentials in the world and the paper credential model is is one that, as they say we use a an issuer some sort of authority gives a credential to a holder that holder puts it into their wallet or puts it into their filing wallet or puts it somewhere, and sometime later in a separate transaction a verifier wants to see that piece of paper for some, some business purpose and so the holder pulls it out of their wallet or takes it down to the office of the verifier and shows them some sort of paper and the piece of paper in theory. And I put quotes around proves who issued the credential so there's some sort of marker on credential that shows who issued it who holds the credential there's some sort of binding on the credential between the person presenting it and the credential itself. And some sort of verification that the claims are unchanged and proves is done because the big thing here is is concerned with forgeries and things like that that the holder somehow manipulated the document either created it themselves or altered it in some way. Trust is largely this between the holder and the verifier but there's also the trust between the verifier and the issuer the verifier chooses what issuers, the credentials of what issuers they're willing to correct to accept. So, in when I talked about that there's both the technology and a governance aspect to it does the technology does it look like it's on the right paper does it look like what that that organization that issuer organization produces. Does it look like there's, you know, ink marks on it where I changed my date of birth on my driver's license so that I could use it for other purposes. And then the governance is things about what's the source of the of the authority of the issuer. Is it a trustworthy organization what where the where does their authority come from when they issue a piece of paper. What are the processes they use for that so those are all the things we talked about in identity paper identity paper credentials online are basically done these days by taking a picture of men scanning them and that's, and that's the where we are today generally with with the use of credentials digitally. What we want is a verifiable credential model. Again, very, I think everyone here should be familiar with this. The issuer provides an issuance of a credential and is got some cryptographic backing to it they hand it to the holder. The holder at some later time that the holder puts it in their wallet holds on to it their digital wallet holds on to it. Some later time they present it to the verifier. And there's a verifiable data registry is is a place where cryptographic material goes such that when the verifier gets the credential from the holder. They are able to verify it, not by contacting issuer and finding out whether it's about it's it's accurate whether it's it can be verified but rather by going to some independent place to get information such as public keys and so on to verify the cryptography. We use this list 1234 in fact verifiable credentials with capital V capital C as in defined by the W through C only talks about the first two which is who issued the credential and the claims are unchanged so there is a path to find out who issued the credential via the information in the presentation provided from the holder to the verifier and there is a signature on it cryptographic signature to verify the claims are unchanged. In the non creds world and places we work. There is a formal way of defining who holds the credential of binding between the person presenting the credential and the credential itself how they are associated. In fact, in, in a non creds is formally defined as part of the cryptography in other in W3C data data model standard that's outside of the stack and has to be determined in some other way so something like there's a picture of the person in it and that's the binding, or there's a did, and the person proves control over that did some sort of mechanism to find it. And then as well there's a fourth item which is available in some types of based on the issuers use case and and how the issuer handles it which is the claims have not been revoked. Those are the proofs that come about. Way less concerned about whether the holder forced it is almost it's pretty much impossible to force those types of things much more on, do you trust the issuer. And so that's a big piece. There's also concerns about the software that goes along so do you trust the issuer software the trust the holder software and so on. This is different from open ID connect and log in by Facebook so I did want to underline that when I talked about this for for those new to the topic. Again I think everyone knows that here and the and the big issue is that the issuer is involved in every interaction when you're using open ID connect that the, there is only a single process and in that process the user sort of consents to both the issuer and the private party and the issuer delivers the data directly and of course in a verifiable credential model on presentation the issuer is kept out of the picture and the interaction is only between the issuer and the relying party. Okay, that's the background on verifiable credentials and what we're using them for hyper ledger and non credits is a an instance of a way to use verifiable credentials or verifiable credential type. In the project in the hyper hyper ledger foundation. There's a complete open source implementation of it in rust. That is based on the non credit specification that is also being built and created in the hyper ledger foundation. This this implementation has a long history. For Indy came out about seven years ago in the self service self sovereign identity stack and non credits has been pulled out and revamped from that Indy implementation that Indy implementation itself derived from a from an IBM implementation so there's a long history of this. The big change that was implemented in pulling an on credits out of Indy is verifiable data registry and agnosticism ledger agnostic which means you do not have to use an indie ledger to store the objects. It's not necessary to have the non credits interactions they can be published in a variety of places, and people have already published such objects in a number of places outside of Indy Indy still the most, you know, common place you'll see them but it's no longer a requirement and so that's a big push that we're trying to do in the, in the non credits community. So that's what we've added to the picture which is privacy and that privacy comes in privacy preserving elements and that comes in for or flavors one is selective disclosure so that when you have a potential that you've been issued, and you present it. You can present the entire document so unlike a paper document where you hand over the paper document to be looked at. You can actually redact if you will some of the fields and just present the things necessary for the business transaction you're conducting. And so the verifier can still see who issued it can still verify that it's the various aspects of it but they don't see all of the raw data of the attributes within it. So predicate proofs are where a. This is the most obvious zero knowledge proof where you prove that you are, for example, older than a certain age, based on a date of birth in the credential without sharing the date of birth itself so you're you're proving something in in the credential but you're not actually sharing the data for it, and, and by prove you're not claiming or suggesting self attesting you're actually proving it cryptographically. And the big one that of why non creds is is really important is unlinkable identifiers so in in pretty much every other verifiable credential model and approach when you share a presentation you're sharing unique identifiers either for yourself or for the credential itself if you are given a verifiable credential and the way of presenting it is simply to show the other party the credential itself that the signature on it is a unique identifier it's very much unique and and so you're actually sharing a unique identifiers for it and so what an on credits does is goes highly very far out of its way to make sure that there is no linkable identifiers simply by presenting a verifiable credential. That is a key place where where zkps are used their knowledge proofs which can both to get into we're getting there, which is that you can prove that the signature, for example, is valid on a verifiable credential without sharing the signature itself. And again, prove being not really there. And finally, multi multi credential presentation so inherent in an on credits is a that you can present multiple credentials at the same time, and prove that they're tied together and do that all with selective disclosure and again that allows for a data and minimization if you need to prove that you're a lawyer and you know who you are as a as a as a resident of say British Columbia and prove that you're a lawyer you can present those two credentials, minimize the data share, and, and still prove those things and prove that they were both an issue to you, or to your wallet. So that's the key features that are added. I should throw that I do throw in that I do a lot of my work with the digital identity team in the government of British Columbia. This slide sort of highlights why government of British Columbia is so engaged in this. BC and every other jurisdiction puts a ton of focus on physical identity cards and, and the importance they provided in underpinning the economy and, and life in in a jurisdiction. The world is moving online. BC therefore is investing in figuring out the best ways to provide those same services to make it safe for citizens to operate online for residents to operate online and I highlighted duty to protect data privacy and security and that's in particular why BC is so interested in non credits. And that the organization wants to, to keep trying to make it that the approach use for verifiable credentials is as private and secure as possible. With that we move on to the fun part. The high school math edition, zero knowledge proof so we're going to talk about we're going to jump back to your, your high school math and talk about how graphic graphic proofs work with zero knowledge. I'm going to go back to Professor Kazusako, who did the preliminary, you did early versions of this the first time I saw this type of thing, Mike lotter from sovereign and now it in other organizations but very involved in the and on credit community did a bunch of these and actually it was my daughter that did a lot of the slides and presentation and math parts of these that you're going to see so high kudos to those so what is a zero knowledge proof. Here's the quote, you know, a method, one party can prove to another party that they know a value x and we're going to talk about x a lot in this without conveying any information apart from the fact that they know that value. This, as mentioned it's the proof it's the core of an on credits, and that example that I give, you know, I'm older than 19, based on my date of birth. And, but without sharing my date of birth so one of the approaches used to do, for instance, age verification and this is proposed in the ISO MDL model and, and some of the things I've seen in other places is, oh well let's put in, you know, a field that says older than 19 older than 21 older than 25 and so that's another way to get around that particular use case and it is a super important use case. With an on credits you actually put the date of birth in but the holder does not share the date of birth they just share a proof that they are older than a given age requested by the verifier. So that's what we're after. This is the interaction that happens we've got a holder prover that knows some piece of information and wants to prove it, without revealing the value. Likewise, the verifier does not know x wants to know, wants to verify that the prover knows x, without learning about x itself so both parties have a want to participate in this. So let's start with a nursery school edition so this is an example of, you know, really getting simple with it so you recall those who grew up in the age of where's Waldo, or had kids that did relished in the school that they knew where Waldo was on any particular page in the book, but they never wanted to let their friends know where they were because then their friends could claim they found it themselves so. So what is so how can you do that prove that you know where Waldo is but not share where Waldo actually is so the way you can do that is make a sheet of paper that's four times the size of the page in the Waldo book, put a little piece of paper behind it, and then move the page, the Waldo page around behind it, such that Waldo appears inside that little hole. The person looking at it can see Waldo, they know that you know where Waldo is but they can't see where on the page the person where Waldo is. The simplest the nursery school edition. Three requirements of ZKP completeness if the statement is true the honest verifier will be convinced that it's in fact, it is known by the honest prover. If the statement is false no cheating prover can convince the honest verifier that this is true, except with some small probability and we're going to get to that in a bit probability involved in in ZKPs. And finally the zero knowledge component if the statement is true the verifier learns nothing other than the fact that the statement is true they don't actually learn about the date of birth the value underlying. Keep those in mind complete completeness soundness and zero knowledge. Attributes mentioned this little earlier. ZKPs are actually probabilistic not deterministic. You are not going to get 100% knowledge there you are going to get a probabilistic, but we're getting pretty darn close and you'll see that. There's an element of randomness always in it which plays into how the zero knowledge proof is is provided. And then we're going to talk about the different forms of ZKPs notably interactive ZKPs and not interactive ZKPs foreshadowing a bit non interactive is better. We'll see why that is. Okay, high school math. Here's where we get to the refresher for high school math. We need to cover functions and inverse functions so we'll talk about functions we'll talk about exponents, and some of the rules of exponents because they come into play. Very clearly in this the module operator and prime numbers. And basically these components. Literally you covered probably in what what we in North America have is great 10 math very 11 math are are all you need to know RSA the Diffie-Helman. Diffie-Helman algorithm shot 256 cash all of these cryptographic things are all based on these core components of the matter. A function is equation for which any x can be plugged in and exactly one y comes out of the crazy one one result comes out of the equation so simple one there. f of x equals x plus two. So if I put 25 in f of x is 27. If I put two in its for and so on. All of these are examples of functions. And basically you have in these case one variable that you insert you do the calculation and you get your result out so easy stuff you know that stuff. The inverse of function is where you reverse it so you, given the output how do you figure out what the input is. So you do the manipulations you probably remember doing those oh I can take the two over the other side by by converting the plus sign into a minus sign so we remember that so x equals y minus two. And we get the inverse function so we've got our example of our original function we can calculate the inverse function. So these ones in these examples and all of these ones, what you'll figure out is it's pretty easy to go from the original function to the inverse and back. Those are all easy. What we want for ZKPs is a function that is essentially impossible to invert. So what we want is something that we cannot do the inverse for. And that is a core feature a core requirement. And in fact what a lot of the working cryptography is defined. We'll see, not just the, not just the functions, but the attribute or the, the, the numbers the types of numbers that contribute to making it impossible to enter, invert those functions, inverse functions, exponents. So exponent refers to the number of times is a number is multiplied by itself so two times two times two is two to the exponent three. So again, we remember that x to the fifth. We got that so exponents pretty easy. You've seen those in regular life, laws of exponents non exhaustive but we've got a few that play are really important here x to the zero is one. x to the one is x itself you just drop the exponent off. x times a gives you x to the a plus B. This is we're going to use a bunch actually we're going to use all of these but so again the example expands out why that is true so you can see that two to the third times two to the second is actually two to the fifth so adding the two together. And finally, x to the a to the B is x a times B. So again, you can do the same sort of expansion out and see that that's true. So, good, we got exponents covered. This is faster than you did it in high school I suspect. This is a modular operator. This is modular operator gives the remainder after division so it's done the same way as division but the answer rather than being you know how many times this this five go into 17. Rather, we care about the remainder. And so that's what you see here, 17 mod five is two. Those of you with a calculator handy or quick with math 321 mod 17 equals 15. A lot of people like to think of this as the clock ticks. I, I'm not so good on this one but I put it up there because many people relate to it but basically you count the ticks around, and what you stop at is the modulo 12 of a number so then you go around twice to 12 you come back all the way to the three that that's the modulo of it so there you go. That's a way to think of the modulo prime numbers. Last one, pretty easy, a number divisible only by itself and one. So, infinite number of these. The prime numbers are pretty important in cryptography and again that that's comes back to the need for these things to, to make that inversion of the function. So, we're going to come back to it but we're going to start again with another example that's commonly used and quite a good one. This is Alibaba's cave, and we're going to show that how a ZKP is interactive and probabilistic. So that's where these two concepts coming to play with with this. So, Alibaba's cave, Bob's the verifier Alice is the prover because of course we can't have anything in this community without Alice and Bob being involved in the cave. There are paths through the cave, a and B and there's a magic door between them. So, Alice is claiming to Bob that she knows the code to open the magic door, and she's going to prove to Bob that she knows that but she doesn't want Bob to know that code she just wants to have it her as her own secret. She's not allowed to tell Bob that. Okay, Bob and Alice figure out to determine whether she knows it is Bob stands outside the cave Alice goes in and then as she goes in she picks either a or B to go down. So in this case she picked a and then Bob, Bob does not know which path Alice took Bob stands there and says hey Alice come out one of the sides hey come out a. Alice goes out a and that was easy because she didn't even have to use her code she just came out a because she picked the same one Bob picked. So, Bob now has some evidence that Alice knows the code because if she went in B, she would have had to use the code but you know she could have gone in a so Bob really doesn't believe Alice yet. So, let's do it again. Alice goes in again Bob goes in again. This time, Bob says, Oh, come out B thinking Alice is going to pick the same way in. Alice can, of course go in a since Alice knows the code. She uses the code goes through the magic door comes outside B and Bob goes twice that worked. Now, the way you get it is the interactive part. We've got probabilistic. We've got randomness going in Alice randomly picks a or B we've got randomness from Bob, Bob's randomly picking a or B to come out. We've got interaction. We're having it repeated over and over. And every time Alice is coming out the wrong side, the right side. And Bob now thinks well there's no way Alice can be reading my mind and know which way I'm going to guess. So, I'm getting pretty convinced as I do this, you know, 1020 30 times that probably Alice knows it. This is the probabilistic nature. Bob doesn't know absolutely deterministically for sure Alice knows the code. It's just extremely unlikely that she would have guessed the same thing that he that he suggested every time. So, I like Bob is a completeness if Alice honestly knows the secret code Bob will eventually be convinced she knows the code. And that's done through repetition interaction. If Alice did not know the secret code is highly unlikely through repetition that she would be able to convince Bob she knows it. If ever the chance came that she went the wrong one for what Bob convinced she can't come out the the correct side of the cave, you know, and of course zero knowledge Bob didn't learn the secret code. So now we switch to math. Now we go over to to using those four elements of high school math and and we figure out Ali Baba's cave. So the first thing we do is we need a one way function, one where the inverse is essentially impossible so coming back to that you know x it's easy to find f of x if you know f of x, it's pretty much impossible to go backwards and find x. And this function right here is the one that's commonly that is used for zero knowledge groups. So, G, G is some public and known value G is known by Alison Bob. X of course is the number we're trying to figure out and then we do modulo P on it where again P is public and known value and it's a prime. So, Alison Bob share G and P only Alice knows X, and we're going to use this for Bob to know that Alice knows that that Bob can determine that Alice really knows X. So summary of steps Bob and Alice agree on G and P. Alice knows X. And so Alice tells Bob f of x and again confident that knowing f of x does not allow Bob to determine X. Alice generates a random number are so Alice picks one this is the equivalent to Alice entering the cave and randomly choosing a or B out Alice generates a random number and calculates f of our and shares it with Bob. So, Bob randomly sends Alice at a, a constant C, which is either zero or one in this first case. And again, this is the equivalent of Ali Bob is paid that's Bob saying come out a or come out me. Bob finds a new variable are plus X times C so Alice knows all of these items. So Alice knows be because she knows all of these things. And then she shares the of F. V, sorry, F of V with Bob. Again, Bob can't determine V. Bob verifies the results by checking that F of R, given by Alice F of X, given by Alice to the C, which Bob chose himself equals the F of V that Alice share. And if the two sides match Alice passes. So, this is the key slide that says how it's done and this is the, the manipulation that goes on with the exponents basically, F of R times F of X times C equals F of F of V that's what we said we needed to check so let's go down this F of R expands to this F of X to the C expands to this. Then we use our rules of an X exponentiation G of X to the C is G to the X times C, and then multiplying that by G to the R is adding to it. And then we get R plus X times C mod P. And that's our results on this side. F of V is G to the V mod P. And recall that V was calculated by Alice is R plus X times C. And here, here we get these matching the mod P is is a factor that just moves out it's a common factor therefore we can move it out and and have it separated from the rest of the calculations of G. And as a result of that, we get this way that Alice only Alice knows X out only Alice knows are. And yet, Bob can be confident that Alice knows is accurately representing those values. So here's some numbers on it we're going to use really small numbers. X is for in this case, don't tell anyone only Alice knows that G we're going to use this five this is public 17 is the prime number so G is our constant P is our prime number. And F of X therefore is 13 you can do the math on that are this random number that Alice picks is seven against only Alice knows that not Bob F of R is 10. Bob then declares either a zero or a one randomly he chooses it tells that to Alice. And then V is calculated. Only Alice knows it again because it's V is dependent on X and R and only she knows it. She does that calculation and then sends does that calculation and so she can then do F of V. We get the actual math for it, we get case one of C equals zero, and we get V equals seven, and we get G to the V mod P is 10. Bob verifies that Bob knows whoops, F of R, F of X to the C, well if C is a zero, we know that anything to the zero is one. So we wind up this being 10 to the mod 17 which is of course 10. And we get verification that these two Alice past few case one case two here's here's where we use one, the only difference here being 13 to the one is 13 so this is 10 times 13 mod 17. So if you do the math you'll find that's 11 Alice passes in either case. Now we have to repeat this process where we use a different are a different C over and over and over again interactively. On the first pass, there's a probability of a half of giving the correct value because she knows Bob's going to send either a C zero or a C one. So she can figure out what it is. If they do this 20 times, it's a one in a million chance that Alice does not know X. Alice kept guessing the right thing that Bob was going to send a C, a zero or one and then, and so there's a one in a million chance that that was sent up that was determined. That's pretty close to being accurate and only 20 times going through this. Generalizing this, instead of C being zero or one, we can see to choose a C in the range of zero to P minus one remember P, P is our prime number that we're using. So this is the equivalent of adding many paths to Alibaba's cave. Alice has to choose which one of many Alice or Bob says come back. One of many, and this reduces the number of iterations necessary to prove it so basically if you have from Professor Sako's presentation, she basically explained it as basically each bit in C is an instance of a zero or one iteration. In other words, if we can get C to be 20 bits of information, we've got it down to a one in a million chance that Alice guessed correctly and produce the right zero knowledge proof, or the right value to send to to Bob. But even if we get it down to one back and forth it's still an interactive process Alice and Bob are still going back and forth. We want to get down to a simple request response process. Bob makes a request Alice sends a proof Bob verifies it so how do we eliminate that extra step where Alice, Bob has to send that extra value C. And that's one more piece of it, which is figuring out how to do non non interactive ZKP so we've got interactive. We don't want to use repetition to reduce probability we want to get down to a single back and forth. What's done is a hash function H again a hash function in a non invertible one with a random number I Alice's use that to define C as f of R, comma I, and using that function that Bob, Bob shared so Bob and Alice both know H the function works. Bob provides as part of his request I, and Alice knows makes up our Alice just creates it because R is a random number that Alice chooses. Bob still know see Bob can calculate see once, once f of R is known. And so it's a shared secret between them a shared value between them Bob and Alice both know it, and it is sufficiently random. R is used as to prevent replay attacks so those familiar with was cryptography and zero knowledge proofs and verify the credentials know about replay attacks with basically Alice and Bob Alice requests a proof from a bug request approved from Alice. Alice prepares and sends that proof along the way some outsider Mallory we often talk about Mallory malicious Mallory Mallory listens in and records the proof that Alice sent to Bob. Later, Bob asked Mallory for a proof and Mallory replays the recorded proof from Alice and claims it to be their own, and Bob can verify the proof so doesn't know. By using a different eye on every time a request is sent out. The proof that is received is different every time. And as a result, even if Mallory hears Alice's proof Mallory can't play it back and pretend it's their own because the eyes, the eye the random factor that what's called the nonce is different. And that prevents a replay attack. So almost at the end. Oops, there we go in real life. This is what number P looks like in a an on friends situation. He is a little larger than the 17 that we chose in our example. It's quite a large number and that is a decimal number. C is between one and P minus one so given P from the previous slide C is between one and this number remember that when we talked about C. C is a each bit of C represents a piece of entropy. So we said that, you know, 20 bits of of it would allow a one in a million chance that Alice luckily selected well there's a whole lot more than 20 bits of information in this large decimal number. So a whole lot more likelihood that C is is going to give enough that that probable probability is extraordinarily low that Alice could pick it. And then in real life this is what G looks like again another big and big, big huge number. So that's that completes the coverage of the high school math part. And I'm just at the end of time so that works of this session so works out well. ZKPs, as I mentioned there's, there's basically four commonly used. I go over a couple of them here. Blinding and identifier of the holder. This is the holder binding that ability that I talked about that is sort of outside of the W3C spec of how that gets done, but in an on creds it's very formally defined and it's always the same. Basically, the holder has a link secret. A big number of blinded version is put into the verifiable credential the holder proves the verifier they know the link secret, but they don't actually reveal it. And then secondly they prove that the same link secret is used with all the presented credentials. So the value of values for selective disclosure is the same sort of thing in this case the issuer signs encoded versions of the data and I don't know where I mentioned this but notice that everything I did x is a number x is always a number in zero knowledge So as a result if you want to do something with data involved in zero knowledge proofs you have to encode that data as a number. And so an on credits has a encoding scheme that converts all of the attributes all of the data elements into numbers. So it's actually in an on credit actually it is the encoded value that gets signed, not the actual data. So issuer signs the encoded versions of the data the numbers representing the data, the holder blinds the signatures in present in presenting those. So it removes to the verifier it knows the signature without revealing the signatures, and then the holder reveals the raw data values of the attributes and the verifier verifies they could inform, they correspond to the signed values. So that's how selective disclosure works, and a little bit on how these signatures are blinded in an on credits. There's similar capabilities and predicates similar in revocation but I just didn't think it was worth going through all the details of those. A pile of references for you. This was based on, you know, I went to this IW 26 presentation by Professor Sacco and it was outstanding. This is a little more formal than she did there's notes on the on on her presentation so you actually got asked to do a second instance of it so there's notes but not kind of the presentation and the math so that's this is helpful. So, like lotter did a presentation, when he's with the sovereign foundation. That's linked here which is about 160 odd slides that includes detailed math of this a little yet okay a lot more advanced than the high school math. But if you're interested in seeing all of the steps involved in this. That's a good presentation for that. And then some other posts about CL signatures, which is the the academic paper upon which all of this is involved. And I did that. And then some other interesting papers, oh, David Chum 1998 paper on blinded signatures just to show you that this is not brand new stuff. This was the sort of basis upon which CK Z cash came about and a bunch of the papers on blinded signatures so lots of lots of things to look at there absolutely I'll be sharing the presentation. Why do they matter CK P's no shared new identifier to present for governments this is huge, not sharing, creating the SSN or the social insurance number the social. Those identifiers are subject to legislation and so on creating new ones is difficult. Unlink ability, minimize sharing, and again unlink ability fighting back against online tracking at my time so I better stop some other things in here, but, and a call to action get involved in this. Feel free to reach out to me if you're interested and want to get involved, want to learn more. Welcome to do so. And with that I'll stop sharing and turn it over because we're at time. So that was a fantastic presentation super interesting. We covered a lot. So thank you. I think one of the questions is, if, if the if people can access the slides. After. Yeah. Great. Sounds good I can post those as well on the meeting page. So, if you go to this page. In a moment, I will upload the slides there. So, great. Yeah. Thank you so much Steven and thanks everyone for joining in with your working group updates and we'll see you all in two weeks. Thanks. Thank you.