 But this is the high school math addition. It's mostly going to focus on actually what happens with ZKPs and how they work. So we have lots of identity. Identity is contextual. You want to use different things at different times, depending on what you are trying to accomplish. If you're driving badly and you need to show it, it's a driver's license talking to a police officer. If you're going across the border, you're using a passport, all sorts of things. Lots of these are government, but a lot of them are other things, universities, degrees, bank accounts, membership in a club, all sorts of things. All of those are elements of identity. And so we've lived for 2,500 years with paper credentials. Paper credentials have a model that you should recognize, but I want to call it out so you realize what we're talking about, which is an issuer gives you a piece of paper because of some reason, some relationship you have with that. The issuer is some sort of authority, and they give you a piece of paper for some reason. You tuck it away in your wallet, perhaps. If it's useful in a mobile environment when you're running around in the world, you might put it in your filing cabinet for whatever reason. Sometime later, in an entirely separate transaction, a verifier says, show me those pieces of paper you have. And you bring out the piece of paper and you show them. Proves, when you do that, and I put quotes around the word prove, who issued the credentials. It's going to have some sort of name or icon logo on the piece of paper. Who holds the credential? It's going to have some sort of binding to you, that it's your credential and it's you that is presenting it. And that the claims are unchanged. They haven't been modified. You haven't forged the document. The trust that they're trying to figure out is mainly with you and mainly they're concerned about, are you forging these documents? Have you faked these for whatever reason? That's a lot of what you're doing, but as well, there's other sorts of trust. There's the technology around it. Does the item you're presenting look legitimate? Does it look forged? Is it look like you would forge it? Often they'll ask for three pieces of information or four because there's no way you could forge four documents. That's going to be all with the same name on them. Never. But they over collect information to try to correlate them, and then they go off on their own systems and try to figure out, OK, did you present something valid, real? And then the other side of it is the governance. What is the authority that issued the credential? Are they trustworthy? What processes do they have before they issued that credential to you? And so if it says government of British Columbia on it, that might carry some weight. If it carries, we actually had a lot of experience with when we worked with the Law Society of British Columbia to, for their issuance, because people wanted to know, well, how does the government or the law society verify that the right person is getting the right credential, that they're actually a lawyer? What's their login process? Can you get an account and fake an account and so on? So do they have trusted processes? Paper credentials are what we're using in the digital world right now. We scan them and we send them off. This is a screenshot that somebody sent me the other day of Google's identity process for some sort of program they have, where they ask you to take a selfie while you're holding your driver's license, your government ID. And good enough, it must be you, because that looks like you in the picture. There's no way you could have faked that. So what we're trying to do is introduce a world where there's verifiable credentials. So credentials that contain the same information, the same thing that paper ones are, but have some cryptography and some processes built in so that you can verify it. So you've got the same model. You've got your issuer. You've got your verifier. You've got your holder. We added an element that I'll talk about a bit later called a verifiable data registry. So that's adding one more component. And I'll talk about it. The ceremonies, the transactions that occur are the same. An issuer gives to the holder. That's one transaction. The holder presents to verifiers. That is a separate transaction. And that's really important, that there's an issuance process. You get something. You get a digital document that's cryptographically signed. And then you share it with the verifier. I've removed the quotes around proves here. Who issued the credential? Who it was issued to? That it was issued to you and that you're the one presenting it. That there's a binding to you. Claims are unchanged. We've got cryptography for that. That's helpful. And the claims have not been revoked. That can be added if the issuer wants a mechanism to be able to revoke. I put asterisks on the who holds the credential because verifiable credentials come in different flavors. The one I'm talking about today in on creds includes that binding between who the credential was issued to and is holding onto it and then presenting it. That's inherent in the credentials. Not all verifiable credential models have that built-in mechanism for binding. Still required is, does the verifier trust the issuer? The holder, they don't have to worry so much about. It's virtually impossible to force these. We'll get into the math to show why it's virtually impossible to do that. But the verifier still has to decide, oh, this was issued by some school that I've never heard of. Do I trust that school? I may have to do research to figure that out. I can figure out who issued it, but I don't. But I have to figure out if I trust them. I wanted to highlight that this is different from the OpenID Connect model that you're familiar with, the login with Facebook. This is different in that the triangle is the same. It looks the same there. We've got a holder, it's labeled user, and we've got a verifier labeled relying party. And it looks the same, but it's different in that when the user is using their phone and sharing their credentials, they're actually telling the issuer, hey, somebody wants to see my credentials, send them over. And the line, physical line at the bottom there is the actual flow of data. So in a single transaction, all three of the parties participate and the issuer knows every time you do it. So the big thing we're trying to do, and certainly from a government perspective of what government of British Columbia is trying to do, is separate out those so that when you use your credentials, the issuer doesn't know you're doing it. And this is an important privacy and tracking feature that we're trying to eliminate. We want the verifier to be able to do, operate in a digital economy without the tracking of the issuer along to figure out what they're doing and how they're doing it. That makes sense. Okay. A non-creds is, as I said, a flavor of verifiable credentials. It contains a couple of features beyond generic W3C standard that go beyond So those things are selective disclosure. So when you present a credential, you get issued it with a bunch of data. When you present it, you can only show some of it. You can selectively disclose which attributes of the credential you want to show. A thing called predicate proofs. This is what we're going to talk about even more. All of this is based on zero knowledge proofs, but this is the most obvious that it's a zero knowledge proof, which is I prove that I am older than a certain age. I'm older than 19. Based on the date of birth that's in the credential without exposing the date of birth. So again, I get the check mark. Derived presentations. So I'm not sharing the credential actually when I use the non-creds. I'm not actually getting a credential and then showing it to the verifier. I'm actually deriving a new credential that I'm generating on the fly and then sharing it with the verifier. With that, I'm getting unlinkable identifiers. A credential, a cryptographic credential with signatures has a whole bunch of uniquely unique data correlatable to your credential. With this, all of those are blinded such that you get unlinkable identifiers. You may share something that's unique about you. You may share your driver's license number, but you don't expose correlatable identifiers just by the act of presenting something. And then the last is multi-credential presentations. This is a big deal, which is. You can share, for example, our example in the Law Society that I am a lawyer and this is my government identity, my name from the government perspective and I can share those two things in a single transaction and prove that they were both delivered to me to the same wallet, to the same identity, same individual. Last thing I wanna touch on before I get into the math is verifiable data registry. So this is how the verifier doesn't call home to the issuer every time they verify and that is that before issuing a credential, the issuer publishes to some public place the key necessary or keys necessary to verify the presentation. So instead of the verifier getting the data and then calling the issuer to say, hey, can you tell me the public key so I can verify this data? It goes to some neutral place, often a blockchain. It can be a ledger, it can be a blockchain, but can be anything, can be a database, can be via an API, can be to DNS, can be to a web server. Wherever, as long as it's public such that the verifier can get to it. Make sense? All right, hyperledger non-creds, just a quick pitch is a project of the Hyperledger Foundation. There's a complete open source implementation plus the specification. It's been used for seven plus years. We've been using it and working on it for over seven years and then before that was a project called IDMix from IBM. The big change in moving it to a project and outside of where it's been is that it's ledger agnostic, meaning that part about where you store the key that can be anywhere. And that's what's expanded about this. We've removed a dependency on a particular implementation, Hyperledger Indy and made it generic. And by the way, with a single key stored on a ledger, you can issue a billion credentials. I do wanna make it clear that when a credential is shared, it's peer to peer. Nothing goes on the ledger or wherever at the time you issue it and nothing about the credential goes on the ledger. The one other thing is the issuer may revoke the credential again by publishing to a ledger, but that is not about the individual. So there's nothing that is put on a public place about individual data for a particular credential. Cool? Okay, why is it important? I put this in, hopefully, if you wanna take a look at the slides, I did wanna get these key points in. The big thing is we spend a ton, governments, I mean, spend a ton on physical identity cards and programs related to that. And sending out paper credentials, passports and driver's license and have fancy technologies to make sure you can't forge them and so on. That same idea is needed for digital credentials and so we wanna build out that capability and we think verified digital trust is extremely important and verifiable credentials is a great model to do it. We think it will be the model. Okay, now we switch. Now we're into the math. Okay, this is the fun part. High school edition though. We're not getting into college here. What is a zero-knowledge proof? I've already talked about this, a method by which a prover can prove to another party that they know a value of X, but without sharing X. So they know the value, but they don't wanna share it. So the value is in the credential and they wanna prove something about it, but without sharing the value itself. Core of a non-creds, the classic examples, but actually a non-creds uses it in a whole bunch of places. So the holder knows some piece of information, wants to prove it to the verifier, but without exposing any other information. The verifier doesn't know X, wants to know that the prover knows it, but doesn't wanna know the actual value. So let's start with Waldo. How do I prove that I know where Waldo is without telling you where Waldo is? You know how to do this? Take a big piece of paper that's at least four times the size of the Waldo picture. You move the Waldo picture around such that in a little hole, you can see Waldo and now I can prove I know where Waldo is, but you have gained no knowledge of where Waldo actually is. I then remove it, show you the picture again, you don't know anything, you haven't gained any knowledge. That's a zero-knowledge proof. We haven't even got to high school. This is the nursery school edition. Okay, so I start with this picture. Do you know who, well first, do we know who Waldo is? Are you familiar? Okay, we're familiar with who Waldo is. So somewhere in that picture Waldo exists. I wanna prove to you I know where Waldo is, but I don't want you to know because you'll just show off and show other people. So what I do is I take a big piece of paper and then I don't move the paper over Waldo, I move the picture of Waldo around so that he's in the little box. And then I've proven to you, because you can see, oh, yep, that's Waldo, but when I move it around and take it back, you still have no idea where he is. You didn't gain any knowledge. You know that I know, but you didn't gain any knowledge. Cool, nursery school edition of, so attributes, the proof is actually probabilistic. It's not deterministic. So you're actually proving it's very likely and where likely is, you'll see what I mean by likely. There's a level of randomness in it so that I'm essentially as the prover stuffing some other information, random information that is what prevents you from figuring out what the actual value is, but it used enough to prove that I know it. And there's two different forms, basically interactive and non-interactive. And so we're gonna talk about interactive and non-interactive proofs. Three requirements we're trying to get to, completeness, soundness, and zero knowledge. Completeness means if the statement is true, the prover can be confident it is true. If the statement is false, soundness, if the statement is false, nothing the prover can do can make it true. So if you have a date of birth and you're under 19 and you're trying to prove you're over 19, you will not be able to do it. So soundness and then the last is zero knowledge that no additional knowledge is shared in the zero knowledge proof, okay? So we're gonna call four things. We're gonna cover functions and inverse functions. We're gonna cover exponents, modulo operator and prime numbers. So this is your warm-up course for the part where we get to the zero knowledge proof. So a function, given a value X, I transform it in some mechanical way. And so it's basically a machine where I put an input in and I get a transformed output out. First one there, X plus two. So if I put 25 in, I get 27 out. Easy enough, functions. We remember that, right? Inverse functions. This is where you did the manipulations to reverse it. You took the X plus two, you moved it over to the Y side, you swapped it around, you had to make sure they always stayed equal. You remember that? So an inverse function is where you are reversing the function you started with so that when you take the result of the function, you got back the original value, okay? That's what we don't want. For ZKPs, we want exactly none of those. We want a function which has no useful, is impossible to invert. You can't take the output and come back to what the original value was, okay? Function, inverse function, good? Okay, exponents, remember these? Two to the third, two times two times two, easy. You remember those? X to the five, five Xs. There's a couple of laws of exponents and this is actually where you're gonna see the magic happen is in these. X to the zero equals one, right? Remember that one? X to the one equals X. You just knock it off, X to the one. X A times X B is X to the A plus B. And then the last one, X A to the B is X A times B. So we're gonna use these in a bit. So you might come back to this when you're looking at the slides after and seeing it. Modulo, do you remember modulo? That's pretty easy, right? Modulo is simply the remainder when you do a division. So if I, in this case, divide, take 321 and modulo 17, I divide 321 by 17 and I ignore what the result is and I take the leftover, which is in this case, 15. Modulo, good. For some reason that I don't quite get but it's common to use a clock for this analogy for modulo, so I don't know. I left it in the slides just cause it was okay. Exactly, and then you knock the 12 off and it's modulo. There you go, modulo 12. All right, good. I think this was the last one, prime numbers. We all know those, divisible by one and itself and nothing else. And so there's a long stream of them, a very long stream of them, infinite number of them in fact. Okay, so no math. We're gonna talk about Alibaba's Cave. How many, I don't care how many of you have heard of Alibaba's Cave, we're still gonna go into it. This is an interactive zero-knowledge proof based on probability. So, Bob, we gotta have Bob and Alice, right? Cause it's a credentials thing, you always have Bob and Alice. So Bob's a verifier, Alice is a prover, we've got Alibaba's Cave and it's got a magic door in it and the magic door has a code on it. Alice knows the code or she claims to know the code. And what the code allows her to do is go through the door. So what Bob is gonna do is gonna ask Alice to go into the cave without telling him which path A or B that Alice is gonna take. And then Bob will say, Alice goes in, she went in the A side, Bob will say, come out the A side. And Alice goes, oh thank goodness, I went in the A side so I can come out and I can prove I know it. I know the code. Well, that's not gonna convince me. You do it once, you're not gonna convince. You got a 50-50 chance, right? So now you do it again. Alice goes back in again, she picks the same one but Bob says, come out B. Now, if Alice doesn't know the code, she's sunk, done. After two iterations, she's done. But if she knows the code and she went in A, she can still come out B cause she can go through the wall and come out B. So now two iterations have been done and Bob's gone, wow, seems like she might know that. Let's do this a hundred, well, 20 times. Let's do it 20 times. And if Alice is every time able to do this where she randomly goes in and picks one side or the other and Bob tells her to come out one side or the other, Bob can be pretty sure that Alice knows the code, that she couldn't have guessed every time which is the right one. So there's the rounds. Obviously any time this talks about what Alice chooses, what Bob chooses, if you do this N times, you're gonna be pretty confident. And the first time Bob picks one and Alice went the other way, it's immediately obvious to Bob that Alice doesn't know the code. So it turns out, I thought it was on that slide, but anyway, completeness, if Alice honestly knows the secret code, Bob will eventually be convinced. They'll have done it enough times that he's convinced. If Alice doesn't know the code, it's gonna be very obvious pretty soon. She's not gonna guess every time which way Bob's gonna want her to come out so it's not gonna work. And Bob doesn't learn the secret code. He doesn't know it, Alice still knows it, but that's it. So let's do it without the math. We need a one-way function. This is where we get into how to do this with functions. So the function we're using is G to the X mod P. And that's actually a common function I think used in lots of other things, but this is the thing. G and P are public and known values. So both Bob and Alice in this case, no G and P. X is the thing that Alice knows that Bob doesn't know, okay? So that's our function that we're gonna use. Hopefully we all remember the math we just went through. It is virtually impossible to go backwards to find X with that formula, with that function. So the summary of the steps, Bob and Alice agree on G and P. They share that, eh, good enough. Alice knows X, and she tells Bob F of X. She does the math to come up with F of X. As we said, can't be a reverse, so that doesn't help Bob. Bob doesn't know X from that. Alice generates a random number R that she keeps to herself, whoops. Calculates F of R and tells that to Bob. Okay, so now Alice knows F of X and F of R. Then Bob randomly sends Alice a number C that is either a zero or a one. Now this is where we come into those exponential things that work. Alice defines a new variable, V, which is R plus X times C. So she takes the R that she knows, she takes the X that she knows, and she takes the C that Bob gave her, and then she does the, again, runs the function, runs V through that function. Shares it with Bob. Bob is able to check knows F of R, Alice told her, told him, knows F of X, knows C, because he made it up, and then also knows F of V, and so he does the math to figure out, do those all line up. And if that is, then Alice passes. Woo-hoo, Alice knows it for one iteration. So here is the math, that if we go back to our, you know, exponents piece. So that's the formula checked by Bob. So if we expand out F of R and F of X, we get our original GR mod P, GX mod P to the C, which by going back to our exponents G, which is G to the R plus X times C. We've just altered the way we've calculated it. And by doing that, we see that G to the R plus X times C is the same as what Alice calculated. And so without knowing X, without knowing R, Bob is able to determine, yep, she knew it. So this is a list of the variables involved. X is say four, nice small number. G is five, P our modulo is gonna be a prime number. G can be any constant, P has to be a prime number, so we wanna use that, so we're gonna use 17. Then we just do the F of X calculations. So G to the X, which is five to the fourth. Modulo P is 13. R is the random number that Alice collected, chose. Same thing again, we do the same calculation. And then Bob sends either a zero or a one over, random choice, there's our randomness coming into this. So we've got our randomness and our probabilistic is coming into it. And then the result of V depends on what C is. The case one, if C is zero, you'll see that Alice sends Bob V of F, which is 10 and the calculation is done. Bob's able to do the calculation and it matches. If the case two, C equals one, is done, the math also matches. So again, homework, you can take this back and verify for yourself that this all works. So that is the core of it right there. That's how you do it. Cool? It's kind of fun. Alice knows X, she can always give, oh, and by the way, oh yeah, Alex knows X, he can always give the right response. Alice doesn't know X, she has a probability one half of giving the correct value. So correct only if Bob sends a C equals zero, for example. So doing it once doesn't really get us there. That probability part isn't there. We do it 20 times and Alice has a one in a million shot. So we start again, X stays the same, but R becomes different, C becomes different. And so we do the calculation over and over. And so back and forth, Alice and Bob are going 20 times. And after 20 times, the probability is one in a million that Alice has been guessing what Bob would do every time and sending the right value. Okay? Now imagine we're trying to do a zero knowledge proof in daily life and Bob and Alice have to go back 20 times. Think of the API you would use back and forth 20 times to figure it out. So interactive, yeah, it's not gonna cut it. So this gets a little more complicated of generalizing it. So first of all, instead of choosing C between zero and one, just doing it every time, C is between zero and P minus one. Remember, P minus one is our prime number for our modulo. So in our case, we chose 17. So C is now gonna be between zero and 16 in those. And every professor, Saka is a Japanese professor who actually I stole lots of this from and enjoyed listening to while she presented it. She did a really good job. That represents each bit in C is an instance of a zero and one iteration. So this, and think back to this when I show you what P looks like of how many bits of information are in P when you see it. I'll be showing that in a bit. But it reduces the number of iterations necessary. If I've got 20 bits in there, I only need to do one iteration and I can be pretty confident that that's gonna be known. But even one interaction is too many. We wanna get it down to Bob sends a request, Alice sends a response and that's it. We wanna get down to just one back and forth. So this is what makes it non-interactive. It's a little bit tricky. Bob specifies a hash function H and a random number I. So the random number is the new thing that gets introduced that Bob asked. So instead of asking for C halfway through the process, upfront he asks for this function H of F, H and I. I is used to prevent replay attacks. So a familiar thing in doing cryptography is you put some variation into every interaction you do so that nobody can listen in, hear a response and then reply with the same one, replay what worked before. So I makes it every presentation unique. So that's how we get there. In real life, X doesn't have to be a number to start out. So one of the things is ultimately in a zero-knowledge proof, always X is a number. But X could be a string that you hash into a number and now you use that number as part of the zero-knowledge proof. It constrains what you can do with it. So for example, you can't prove your date of birth if it's in a string as a predicate, but as long as it starts out as a number, you can do predicates on it and things like that. But you can always do things like selective disclosure, not revealing some of the value, some of the attributes, while still proving the entire credential, proving all of the attributes that you have them all, but without revealing some of them. So you can use that. Then numbers GP and C are really, really big. So that's what P looks like in an Anancred's presentation. It's a very large number. And remember I said C represents the number of bits. That's a lot more than 20 bits. So you get the probability is a lot less than one in a million that you've got it, which is of course the whole point. So the proof is, even though it's probabilistic, the chance of fooling it is pretty low. That's what G looks like. So P is the random number. C is arranged from zero to one less than that. And then G. So ZKPs in Anancred's binding and identifier of the holder. So this is where you can put an identifier for the holder. The holder can share and prove that they know how that credential was bound to them. They know the secret that's in there, but they do it without sharing that binding identifier. So there's not an identifier uniquely identifying the person. Normally in non-zero knowledge proof credentials, you would put an identifier that the owner of it can prove they have control over. Some, you know, you might put a public key in there and then get the verifier to prove they know the public or the private version of that. That's a unique identifier. We don't want that, so we use blinding for doing that. We can blind all of the data values for selective disclosure in a similar way. Predicates and revocation, I didn't go into the details of how that gets done, but you can take a look at that and go into that. Bunch of references here, in case you wanna look it up. Glad to have, you know, people can read these. These tend to be more accessible than the academic papers. CL signatures, academic paper, that is the non-high school math edition. It's ugly, oh. But it's there, you've got a link there, but you've got other ones here that are more accessible. CKPs in real life, why do they matter? No shared new identifier. This is big for government. If you think about a national identity number, SSN in the United States, an SIN in Canada, that's legislation. There's big, you know, it requires rules to be established by elected bodies to put these things into place. If we have to introduce new ones to put all sorts of new identifiers in for all sorts of individuals and organizations, that's a bit of a problem. And so we don't wanna do that if we can avoid it, so it allows that. Also gets us to that non-correlation, that unlinkability. A verifier receives proof of a credential, a second verifier receives another, and they can't correlate the identity across them. Crucial. So you've got unlinkability from the issuer, but you also have to cross all the verifiers. That's really important. The techniques you've seen of selective disclosure and predicates for minimizing the amount of data you're sharing. So you can prove something with whatever is necessary. So walking into a bar, you do not need to disclose the color of your eyes to get a drink in a bar. It's just not needed. Yet we do it every time. Well, I don't, but that's what we're doing, is showing all, and more importantly, showing the address we live and all that stuff. That is totally unnecessary, and so we wanna minimize that. Often it's done not because it's needed for the transaction, but it's needed for the verification that the person has to go to offline to figure out who you are and whether you really are, who you say you are, and all sorts of other checking that you're gonna do to figure it out. By getting the data from a trusted source, from a verifiable source, we're able to collect less data. We only need to collect what's necessary for the actual transaction. And then a lot of it is fighting back against online tracking. We really would like to take a dent in that, which is, again, coming back to this unlinkability. We don't wanna have, in the case of the government, tracking every bar you go into, and every time you buy cannabis, and so on and so forth. There are all sorts of reasons for not doing it, but that's a super good one, is we don't have it when we use a paper credential. We wanna be able to operate online digitally, but we want the same privacy and protections we have when we're using a piece of paper. Talked about these things. Duplicate slide, nice. Mentioned predicates used as bullet proofs, and revocation used as accumulators, so for those who know some cryptography, that's the techniques that are being used. Wanted to highlight this one. This is one of our participants in the Hyperledger community. They are doing decentralized finance, DeFi application, where they are actually putting a verifier into a smart contract. So the verifier that I talked about would use that. Basically, when doing an on-chain transaction, the user who is trying to execute the transaction might provide KYC information via a zero-knowledge proof based on a credential they were issued. So who issued it and so on, and whatever minimum data is necessary to be collected could be collected as part of the smart contract, which could be just enough to say, oh, I'm a citizen of Canada. That might be enough. And then they can proceed with an on-chain transaction. So super interesting, got links in there to the company, their product, and then a video. And they just had a hackathon this past week that was evidently super interesting and leading to that. Everywhere paper credentials are used, this is a possibility for replacing them. And I think this is why I think it's inevitable that this will happen, this will be the way we'll be doing it in the future. It's the question of how we get there, how soon and how accessible it is to everyone and we make it work for the vast majority. But there's lots and lots of use cases. So call out, join Hyperledger and on creds. You can deploy your own agents using Aries, Hyperledger Aries. You can get a wallet like John mentioned in the keynote from the government of British Columbia. You can download from two of the app stores, but there's a bunch of other ones as well. So you can give it a try. And then see how it fits into your own project. I forgot to, and I'm bad at this social media stuff. I'm doing a workshop on May 31st. So if you wanna get into details of how actually Hyperledger can be used and actually play around with credentials and use them, I am doing a workshop with Hyperledger that's remote on the 31st of May. So coming up soon. There we go. Thank you. Thanks for attending. Any questions? I didn't leave a whole lot of time, but I got through all my slides. So yes. Thanks. So my, so I mean, I follow politics and so on. And Mike, I'm very excited about the proposition of not selecting a disclosure. It's the biggest advantage of this I find. And, but I'm also very of, like really a government institution being able to truly allow for a decentralized, you know, like I'm surprised and I'm amazed and perhaps happy that you guys are leading the charge as part of the government. But I wonder, so my concerns around this thing that I wanna, but I feel like you're already addressing but I wanna confirm it, is things that are unlinkability and tracking. So I'm very personally like, my concerns are surveillance, of course tracking all the movements. Like you can't do that with your IP ID, but you can certainly do that with digital ID, your phones, whether it's on device stuff, in the mobile app that the government designs if it's not on the ledger itself. And also the idea of like a revocation so you can just sort of immediately like, you know, like with the truckers, bank accounts gone, ID is gone. Now you're just like stranded on like the middle of the road. So I'm wondering with unlinkability, is that part of this solution as part of the government plan? So yeah, so a couple of things there. Nothing personal or anything else goes on a ledger. Nothing. So the only thing that goes on a ledger is something an issuer wants to broadcast the world so that you don't have to go to the issuer to get it. So that's one. The wallet is a concern and that's why BC is open by default. The way we can do that is have the wallet be open source code, auditable, verified by others. They can see what's in there and how it gets deployed, how it gets used, what happens within it. The correlatability of the surveillance, 100% it is that breaking up of the transaction of the issuance to the holder and the holder using it with a verifier. We want that separation. So we're really passionate about that need to separate those things out so that there isn't that ability to do that surveillance. Really reduce it. As you say, like cell phones, you know, location tracking, we're not addressing that. What we're trying to do is if you use a credential and in our case, we're worried about a government-issued one, we wanna have that separation, that non-tracability. And so we try to do it both. The issuer doesn't know where you've used it and then verifiers can't correlate you across others. With the caveat that if the information you share makes you correlatable, so we just make sure that just by presenting data, there's nothing correlatable in there, that every presentation is completely unique and useless to try to consolidate across. So I have a follow-up with that. Those are awesome pieces of information to get. On the side of the app, so for example, one way around the surveillance thing, assuming that for some reason, you can't trust the open source code of the wallet, is being able to access that information throughout, like without downloading the app, without the view, through some kind of interface that you can just, like the metaverse, that the blockchain that's out there, you will be able to access in your own personalizing. Let's say I create like my Xcode app and that's my wallet or everyone else, like it does through an app in WebAssembly or something, is that possible? And the other thing is that on the host issuer, say the issuer verifier, host verifier side, is what about the host? Like what, like I know you said like, no personally identified information is there, but like, do they track, yeah, I call us to them or whatever, it's like, you know, there's easy ways to say, hey, and this bar, these IDs are being queried, so someone could be like, just like, like, traffic monitoring traffic of a, like, wire network, gather and all that. So the answers to that is basically, open source can be done anything. So yes, you can build your own wallet, you could host it. Now the intro, or you could then use it. The interesting thing there is, as a government, do we wanna trust a wallet that is randomly showing up? So we expect that the way that will be done is for now, we're only issuing to the VC wallet, not because we track with it, but because we know what's in it. We've done the analysis of what's in the code. If you bring a random wallet in that somebody gave you, it could be tracking you. Hey, you just made a phone call from a police station. Would you like me to get a lawyer for you? You just used your, you know, we don't want that kind of use of it. So what we expect is there will be other wallets that others will be able to do it, but they will have to be compliant with and prove that they can be in the same trusted way. So that's more or less that one. The host issuer verifier, I mean, the whole point of the verifier can always monitor what they're doing, we're trying to make it so that they can't correlate across presentations. What other things they can collect, what other things they collect today? Less control over that. I don't mean the verifier, I mean the other side. Yeah, the host can't, the host can't. Sorry, the issue. What is the host? Like I'm curious actually, because I feel like I, again, I'm not a math person, I'm more of an application engineer, so I use all these things and I never understand them. Sorry, what host do you mean? So the host basically, where the information is stored for the verifier to connect to instead of the issuer, but that's the host, the device is the host. Right now in what we're doing, it's all right there. It's all offline. Yeah, it's all peer-to-peer with your device and that. This is our way of, say, allowing you to have a server that holds your own data. Okay, so the host, so when the verifier in front of you is talking to the host. They're talking to your machine. Got it, got it. Yes, yes. You've got a peer-to-peer conversation going on. Another part, you know, I mentioned Aries, another part of it is it actually uses other cryptographic techniques to establish a secure end-to-end encrypted session between you and the verifier. So there's the ability to establish a relationship between you and, say, the government, or you and your bank. One of the interesting uses of that, I'll just throw out another little tidbit that might interest you, but having that trusted peer-to-peer relationship kind of like signal between you and your bank is, you know those SMS you get and email you get from your bank that say, hey, you need to log in and do something or, you know, nobody. Trust those anymore, right? Throw them away. Email's not trusted. SMS is not trusted. You really need to know and think and you get trained not to respond. Well, if you actually could use the BC wallet to send messages, the verifier, after they've established a relationship with you could send you messages via that secure encrypted channel. You might be able to trust them again. Organizations have huge value in being able to say, hey, we can actually have a channel that we can use that our customers could trust. It's a big deal. And I'll pass this back on to the last thing, which is the authority, like establishing authority for issuers. Yes. Do you imagine that to be, imagine the government? No, so that will be sort of domain oriented. There will be all sorts of, you know, you get a degree from a university in a certain country. Their authority is the organizations of colleges and universities within that. Mining community has the London Metals Exchange, as a, so all sorts of places. Like the public key, like the public key. Oh, those are where people choose to do them. Some of the, you know, right now, Microsoft offers a service that allows you to put, route them in Bitcoin. They can be Ethereum. There's Ethereum based. We're using a ledger that is operated by a set of known parties. So it's a, what's called a permissioned ledger. Everyone can read from it, but only certain people can write to it. And so it's permissioned in that way. But a Bitcoin based one, anyone could, could write to that time. Okay, let's get out of here.