 I have to leave at the 45 minute mark, so. Yeah. Okay, welcome to the October, can you believe it October 2023. October 2nd. An on credits specification working group meeting. We're going to talk about credits today or Mike is credits being. The an on credits V2 glue around the Agora library. So. We talked about the Agora libraries last week or Mike did. And this week, we'll get into. How. The. Cryptographic primitives that are in those libraries are used in and our credits. Goal is, well, we'll talk about that in a moment. Let me continue with the, the getting started reminder. We are recording this meeting and that this is a Linux foundation, hypernetra foundation meeting. So the. Any trust policy of the Linux foundation is in effect as is the code of conduct of hypernetra. Welcome to all. Announcements are IAW next week. So part of the goal of this meeting is to. Go over a credits and in preparation for IAW next week. So that's really my goal is I really want to. A Mike is going to move the repository by next week, hopefully as he just mentioned. And then. That will allow us to. Have a session at IAW where we point to that. So we can. See if we can get some. Activity going around the use of those credentials. And around the, around the use of an on credits. Be too with the underlying signatures that people will be interested in. All right. So Mike, I guess I'll just turn it over to you. And then pass it over. All right. I'm going to take notes. Alrighty. So as it's currently laid out. This is. A credit stands for anonymous credentials exchange. I didn't want to put an on in front of it. I think everybody's kind of getting tired of hearing that. But anyway, so this was. 2.0 means. And we've talked about the data model before. So this has a lot of that as you'll see in there. In this particular library claims are basically a tuple of information that's like a label. The type and the value. The label obviously must be distinct. For a given credential. The cross credentials that this matter, but for a given credential, it must be like, you know, you know, you don't have one birthday in there, but if you maybe want to preface it and say, this is your uncle's birthday or your daughter's birthday, that's different. The point is the label just has to be unique. So, you know, which one it is. I don't require it to be random. It could be a user friendly name as well. It doesn't matter. You could just say A B C D. If you wanted for all your labels and be as cryptographic as possible in a different way. All right. For each type. So that means it, what is it mapped to, and we've mentioned this before. So there's integers. Like dates, enumerations, maybe raw cryptographic numbers, pseudonyms, or arbitrary length data. So that's kind of the three types. There's numbers. Raw cryptographic material. And then arbitrary length data. Okay. So I don't think it's necessary to be restricted to these in the future, but honestly, I can't really think of anything else that's not encapsulated in that. And what, and you might ask, well, what about floating type? Well, to be honest, no one's really tried to get me to do a zero knowledge proof up to 20 decimal places. So I think rounding for now is just fine to the nearest integer. Okay. Just a matter of interest. I don't think it matters, but I don't think it matters. I don't think it matters. I don't think it matters. I don't think it matters. I don't think it matters. I don't think images and biometrics would just be long strings. Yep, right here. Yeah. Yeah. Separation of strings to. To images and biometrics. You wouldn't do. Binary images or binary and images. It really doesn't matter what they are. Just as long as you define how it's mapped. Okay. Okay. So similar to how like signatures, that's what this type is doing. So for example, with ECDSA, the standard says you take whatever the message is, you compute the shot to 56 hash of it. You make sure it's less than the order of the curve. And if it is, then you can sign it. If it's not, then you need to reduce it first, then you can sign it. So this type. For the claim is defining what method they're using to get it into a signable form. That's all this means. So arbitrary length data and enumerations are usually hashed. Integers are usually kind of recoded or they could, maybe they don't even require any remapping, but let's say you want to zero center it to account for negative numbers. Or you want to make sure that zero actually isn't a flat zero. There's ways to do that. Trust me. That's usually what you want. Okay. So let's say it's a number of days since 1900, because we, as we've learned with the non-creds one, if there is a zero, then it can leak information. So we should remap it first. Okay. So like birthdays, you could encode as an integer. Maybe one is a string. It doesn't matter, but you could say it's the number of days since 1900, or it's a timestamp, which is the number of seconds since the epoch. So in this library. And what this means is like, there's certain values that have known, there are known set of data. So you can think of as like gender is one of those. You'd say it's male, female, non-binary, or what, you know, whatever the case is, right? It's a fixed list of stuff. Or it's the number of states in the United States or the number of countries in the world. Like there's a fixed set of these. You could encode these as numbers. And there's nothing wrong with that, but it might make sense in some cases to define it in a fixed set. So that it makes doing like membership proofs easier. So it's kind of a special case of numbers. But then there's numbers. And I define these as 64 bit integers. Positive or negative. Unlike a non-creds one, which was restricted to positive numbers. Hasht claims, this is basically anything that's arbitrary length. Scalar claim is anything that you assume is already a cryptographic value, like it's ready to go. You don't have to transform it at all to sign it. So this could be secret keys, pseudonyms, other random numbers, cryptographic material doesn't matter, right? Assume that the transformation to be signed is like a null transformation. Nothing has to happen. And then I consider revocation to be special, but in reality, scalar and revocation are treated from a signature perspective identically. There's really no difference between them because I consider revocation claim to be a cryptographic value. It does not have to be. It could also be a hash value. It could be an enumeration. It could be a number. It depends on what you want to define it as in credits itself. I believe I mapped it as a scalar or a hash. I'm trying to remember. It's been a while since I've looked at it. If it's hashed, it's probably just a GUID. So it's just a 16 byte number that's hashed. So, okay. And then there's the value that you're actually storing. And before signing, I also support the idea of validators. So the issuer code in this library checks whether the claims are valid first before signing them. And this is on the pre-signed data. So if it's an image, it might check to say, I can't sign anything that's bigger than the one gigabyte, right? Or the integer has to be between one and 255. That's what the range checker is. Or maybe it has to match a pattern. Like if you say it's a state in the United States, but we're doing it as a string. So it has to be the two letter abbreviation. For example, that could be a regex or it's a zip code. So it follows this particular pattern. That's what the validators are for. Anyone is similar to like an enumeration. It basically says it could be any one of these known set of values. So again, going back to the 50 United States, you could say it has to be one of these 50 values. That's what it is. If it's not in this fixed set of values, it's not valid. Now a claim can have any number of validators. Any number. It could have none. It could have 200. But usually I think they should have at least one, except in the case of say like revocation. Because there's really no need to check that because the issuer is usually handling what that is anyway. So basically I think a way to describe these two things, the type and the validators is this is the encoding mechanism. In a non-creds one, the encoding mechanism was in theory left to the issuer to decide. They put the data into whatever. They encoded the data into an integer. And that's still true. To me, the issuer can define what that will define what that encoding is, but this way it could also be a standard. But unlike an on credit, the encoding, basically what happened in reality was everything had to be an integer and because that was so hard to police. Because there was no validators because there was no type. And that's what we got down to. The only thing you can have is a string and an integer and that's it. Because all the rules were left open. What you're doing is defining a bunch of encodings that are possible and providing a broad way to do that. Would that be accurate? Yeah, exactly. And here's the set of things. And here's how you verify that the incoming data matches that. Yes. Yeah. Okay. Good. And so in the code, you can see exactly what I just described here. So here's the numeration. Here's hash. Here's number. Here's revocation scaler. Here's a list of validators. The type is just mostly like an enum and then just kind of some serializing and mapping to and from. Numbers and strings, that kind of stuff. When I, when I say claim data, this is basically like, see, you can see, oh, the claim data is one of the pipes. And then here's some kind of conversion methods. And how it maps to a scaler is dependent on the method defined. So like if it's hashed or, you know, if it's from bytes, here's how you kind of do some conversions. So mine, if there's one, two, four, eight, or now I might do 16 for 128 bit numbers, but it doesn't matter. The idea is there. So you can kind of see these are just kind of convenience methods that are necessary for kind of signing and also for when we generate proofs. So some serialization going on that I would like to clean up, but that's largely what this, this is for. So everything about claims is in here. In the claim folder. Now a collection of claims. So there's claims and claim data claims basically are kind of the metadata about what is being signed and the rules that accompany that and the mapping, the encoding, whatever you want to call it. The claim data is actually the, the actual bytes that will be signed when you combine the two together with a signature, that's a credential. So if you're just talking about the metadata, like a group of claims into a credential schema. That's the same as V1. So that's no different. It's just maybe a little more defined or polished with a little more information. So that, that remains the same. It's basically saying these are the claims that go in a credential that I sign. They're ordering and they're mapping their encoding and how you should interpret them. So everything about a credential is in this credential folder. And so here's an offer. Here's a schema. And then membership is mostly about like membership proofs. So I didn't, I added this kind of later. There's like a membership claim. Think of it as like a special way to handle, am I doing a membership check or not? It's no different than any other claim. I'm just doing it special. So I could have any number of these. So we'll have to clean that up. But it's just like any other claim, but it's in here. Yeah. A bundle is a way to say, here's the issue where I got it from. And here's the credential itself. So this is like the credential schema I got from the issuer. The issuer's public key, maybe the revocation registry and everything else that goes along with it. So, but otherwise everything about the credential is in here. Probably the next important part is if I go into the issuer. So there's this issuer file right here. And I know you abstracted this and be one to say, well, the idea isn't tied to them here. It's tied to wherever it's mapped. That's fine. I don't care. But not knowing where I was mapping it to like, because how I've used this, it was independent of where it was being mapped or whatnot. So the issuer has a unique identifier, whatever that is. We can, we can remove this and have some wrapper class. That's fine. The credential schema that they're going to sign. Their secret key, the revocation key. A verifiable decryption key. And the revocation registry. Now. Credits. I define issuer as in this code. As one key for one. Credential schema. So like British Columbia might have multiple issuer keys. Does that make sense? Yep. Okay. All right. So this is the, the private part. This part should always be kept secret. This needs to be abstracted. Both of these do. Assigning keys. So right now I just hard coded it at punchable sand. There's that's what PS. I was going to ask what the PS was. Okay. So right now this is hard coded to PS. Okay. Yep. But it could easily be swapped with VBS plus or any other short group signature that serves in the same way. Okay. VB 20 stands for the accumulator version that I'm using. But again, this could, this should be abstracted because maybe they're using revocation list 2021 or something else entirely. I don't really. It doesn't matter. So anyway. Okay. Let's see. Then there's the public portion, which is it's the first fields kind of all look the same, but then it's just the public keys. And the revocation registry in my case is just the accumulator value itself. That's it. And so when you want to do create a new issuer, you just say this is the credential schema it's going to use. And then this is just all initialization. Okay. One more back. Think of this as the cred death. Yeah, but why an accumulator in the cred death. In revocation. Just how I was managing it. If you want to, I know in V one, you've got it separate where the cred, there's a cred death and then the revocation registry can point to the cred death. That still works. Sorry. No, no, no. I'm trying to understand. Is that an actual accumulator or that is a pointer to the accumulator? No, this is the actual accumulator itself. I don't know. I don't know. I don't know. The value of the accumulator, but doesn't the value of the accumulator changes you revoke credentials. Yeah, but the issuer will know what that is. Right. But why would at issue time. Ah, here's why. So the reason it's given to the holder is they need to know what the current accumulator value is as well. Time it's issued. So if it's ever changed, they go, Oh, I need an update. Yeah, that's to do with how you've done, how Alastor works, which is that's when they know they need to get their witness updated. Correct. Okay, got it. Rather than assume they always need to download and look at the latest they can. I mean, they still do that. But if they say, well, it's the same as last time. I have no, I don't need to do anything else. Right. Okay. Okay. All right. So that's everything related to the issuer. Oh, maybe I should have walked through that a little bit. So here's how you create a new one, which is just give me the credential schema and then I'll set up this issuer object underneath. Here's your cred def. And then here's all the private signing keys. So it returns both when you go to sign something, this assumes, you know, all of the claims. So this is just because there's some cases where you don't need to hide anything. So I support both and then it just returns the entire credential bundle, which is the credential itself, all the signed claims and the issuer and the credit def. That's, that's what all of this is. So in here, you can kind of see it's checking to make sure that their revocation claim is valid. It's checking against all of the validators, making sure the types match. So there's a lot of checking going on here. And if everything checks out, then it creates an issues and then sends everything back. Then there's blind sign. And unlike the one. The issuer can allow any number of. Claims to be blindly signed, but it has to be defined. In the credential schema. So remember in the credential schema, there's a list of claims that are allowed to be blindly signed. Yup. This blind sign will check against that list too and say, Hey, can I actually sign these? Are these allowed to be blinded? Cause if they're not rejected immediately, right? So there's some, there's some checking going on. Hang on. So on this is where the holder would provide the blinded link secret. Yep. Can the holder could provide other things, but the issuer could have other blinded things that get signed. Is that correct? Yes. And any example, remind me of an example of what, and another one might be. Oh, I might have a private key in there. That I want or a private. Yeah. I might have a private identifier key as well. That cross things. Does that make sense? Wow. That's interesting. So I could prove I have a private identifier key. How would I know? It talks about, everybody talks about this holder binding. Yeah. You might do biometrics this way. Like let's say the biometric is local to the user's device. Yeah. You don't want that getting out. So you might want to blindly sign as well. Okay. We got to go into that one further at some point. I don't know if I want to interrupt, but basically what I'm thinking is one of the, one of the complaints, one of the things that people want to see is they want a. Key to be. Signed and held in hardware. Some sort of binding that is tied to the hardware. Well, biometric becomes a possibility if it could be blinded. How would I know that it's a blinded biometric? Do I have anybody knowing that? That's debatable. Like I would know it's biometric versus some random number. Yeah, exactly. There's a place to do that. If you have any on that. There is a zero knowledge proof to prove that this really is a biometric versus something else. It's very complicated, but I don't want to get into that right now. Okay. There is a way to do it, but it's complicated. Okay. Probably the best thing I would think of is like, think of a deterministic signature. Cause if us, if a secret key is in hardware, you can't put it in the credentials. You can't put it in the credential anyway. Right. So the, the closest thing you could do is I'm just going to sign a random number and we'll put signature in the credential, but I don't want you to know what that signature is because it's correlatable. Right. So, so you could do it that way. I mean there's, there's different ways you could do it. So that's a, that's one way to do a holder binding that I've come up with. But the point is you can have any number of these claims that are blinded. Okay. So there's this blind credential request. Coming from the holder. Yeah. And the answer is going to blindly sign it. Yeah. Oh, my appointment at nine just fell through. Okay. So I can say the whole time, sweet. So anyway, we'll go over this in a minute. What this looks like. It's not much different than the one just know it's everything that's needed for the issuer to finish signing stuff. Right. So then there's checks involved with that. And then it's signed. Here is the super simple update revocation handle. This is not the Alasor method. I have code for that somewhere else. Okay. I will move into a Gora. Yeah. And we can hook it all up in here. Here's how to revoke a credential. This does not change with Alasor or. Or anything else. This stays the same. And then that's just convenience method. Okay. And then this is just. Yeah, this is like cred def when you're doing a zero, when we go to do a proof or verify this is the stuff that gets added to it. Okay. That's enough for the issuer. Okay. So there's nothing, nothing too fancy there. The holder, everything the holder needs has to do with credential and presentation. So probably the next thing to look at is blind. So there's a blind credential. This is what is sent back from an issuer. So it actually starts with the request. So the, there's an offer that comes in from the issuer. It says, Hey, I'm willing to give you this. And the holder is going to blindly. They're going to create a blind credential request. I don't know what it, I don't remember what it's called in V1. Maybe it's just a credential request, but I wanted to distinguish between a regular credential request and a blind one. Cause a regular credential request just says, yeah, I want it. And there's nothing else other than like. Right. Signature and that's it. Right. So we can keep it very simple. But at minimum you need, we've, we've declared that like secret have to be so you, so you always have this in V1. Yes. Yeah. You may not, you may have zero blind credentials. So the only thing it is is signature with an act that saying, yeah, I acknowledge I want this. Okay. And that's it. Okay. So this is basically the same thing as it was in V1. But a list of claims that you want to hide. Or that will be blinded when they're signed. And then it just does creates what I call a blind signature context. That says for this context, these are the claims I'm blinding. And has some data to make it sure that it's fresh. And is not a replay attack. Those types of things. And that's in there. So this is everything that goes in that blind credential request. And then what comes back from the issuer, you saw that was that blind credential request is passed in the, the issuer blindly signs everything else along with everything that is known. And comes back with a blind credential. It's very, very similar to a regular credential, except that the signature is a blind signature. This is exactly the same as V1. And then there's a method that says convert this blind signature into a regular one. And that's all it does. Cause then it'll group in all. Plus some blinder plus the issuer and all of that stuff. So it just converts it. Nothing really complicated going on there. Yeah. Okay. The raw cryptography for all of this, I try to put it in what I call Knox. You know, like, so it seems like this cryptography is as good as it sounds. So anyway, I started working on an abstraction for the short group signature. That's what this is short for core that this is basically everything in this folder. I want to abstract out to a Gora. Yeah. Okay. Yeah. So I've, I've mostly grouped it all there. There shouldn't be the idea here is you've got, you take this, you abstract out. So that where you're calling PS before you're calling the abstract. This, for example, says give me a short group signature. Yeah. And then so this, that would remain and then that would be calling out to the various, whichever selected signature scheme is being used PS or BDS or whatever. Yep. Or accumulator or revocation list. So, so how do you, how much confidence do I have that this works with the, with BBS plus signatures and why? If you understand the question when I wrote this, I had them both in there, but I didn't have a good abstraction. And so I was running with compile time flags and it was a pain in the butt. But I also originally wrote this in go when I was at coin base. Okay. In a library. Whoops. Did I called cryptology? Right. So let's see if I can find it. And we had BBS there as well. So we did do it there. But we never really finished credits. Like it was like a half baked project that was abandoned. So then I took it and went with it. Okay. It should work because PS signatures and BBS plus signatures are the same in terms of how they function. You, you create a commitment, a vector of commitments to all the claims and then you sign it. And since they both work that way, they should, they both work this. And Ursa has the hot swappable versions of those just not in a very clean way. So trust me, it will work with BBS. Okay. Okay. Yeah. All right. So I think for the most part. All of the cryptography that this runs on is in Knox. The most part. That's not entirely true. Okay. So at this point, it is not calling a Gora. No, it's not. Okay. It's all self contained. And with that, but the idea is we're going to update all this to reference. Some of it, I have moved to a Gora. That's what that's what this is right here. Okay. And here. So both of these will be moved. The rest of this you can see is just mostly just kind of supporting stuff. Okay. Hold on. I've already moved to here. And stuff I've already moved to here. Okay. So there's only two, the three things left. And that's all in this folder. Okay. For the most part. Okay. Okay. Now remember present. Maybe I need to go back to the read me. Yeah, it sounds like good. Yeah. Okay. All right. So that's the issuer issuance revocation and all of that stuff. Now we move to presentations. Okay. Okay. And the presentation schema says this is what must be proved. All the statements. In this present in this schema must be met. If you want to do like an or. Then just send the holder like three presentation schemas and say pick one of these. Yeah. Yeah. So that to me is the simplest. You don't have to do any. Language parsing or any complex stuff like that. It's just easier that way. So, and, and if someone can think of a better way, I'm all ears, but trust me without getting in the language parsing, this is by far the easiest way to do that. So for a presentation schema, does it involve one source credential or does it involve can it involve multiple? It can involve multiple. So. Let me show you. Yeah. So the big thing is a presentation schema is set is a set of statements and conditions that the user has to satisfy. Okay. In the code, I call them statements. Yeah. Okay. Yeah. So like, for example, the statement might be include a unique identifier. Or. Prove that you're not revoked and things like that. Yeah. So statements, each statement is identified by some unique. Number. Or letters or whatever. Yeah. What is the statement type. And all the public data that that statement requires. So like public keys or revocation pointer or anything like that. It's got to have everything in there that for a holder to know. Okay. This is what I need to prove against. So let me like including numeric constants, like if you're doing range proofs. Okay. Got it. So when you combine all of those statements together, that makes a presentation schema. So we do all of those together into one big ZKP. And with a bunch of snore proofs, but each, each statement has specific proofs that satisfy it. And then we make sure they're all glued together to say. This is one big composite proof. And then each proof is also checked individually. You have your question. Um, Can I. A big sticking point or, or. Rough edge of an occurrence one is the use of the term name versus names where. It began life with each one having a separate name. And then names came along to say, Oh, these must be from the same. Source credential. Is that concept here? How does that. Yep. Yep. Let me get there. Okay. Good. Thank you. Yep. This is super flexible. Trust me. All right. So. Um, The main thing to know is that claims have two states. They're disclosed or they're not disclosed. Okay. So if they're disclosed, you're obviously just going to reveal it. That's it. If they're hidden, obviously they're either completely hidden. Or they're partially hidden. Yeah. So partially hidden means we're revealing something about them. By using predicates. Yeah. Otherwise. If there's no predicates applied to them, they're completely hidden. Okay. So all statements except signatures are predicates. Okay. So. Now that gets your main question. Can I ask you to prove from the same signature? The answer is yes. So there is a signature statement. And all this does is it says this is the issuer. You have to prove it from. So like British Columbia. Yeah. Sorry, my dog's barking. You basically can have like a bunch of these. But the sole point is you really only need one. And you basically say these are the claims that must be revealed. And these are the claims that don't have to be. That's pretty much all his signature statement is. Yeah. From this. This issuer. And these claims are shown. That's it. When you use the term issuer here, I think you mean. Whoever signed it. What credential definitions? Yep. Yes. Right. It includes more than just who signed it, but rather. It includes the schema. Yes. Yes. Okay. Yeah. Yeah. So if we go look at that real quick. Yeah. It's in statement. Signature. So here's the statement folder. Here's all the statements. So. A statement. Has all the disclosed claims. Yeah. Every single statement has an ID and then this is the cred death. Got it. Okay. Okay. Yeah. All right. So I believe we're on the same page. Yeah. Okay. So then you just glue a bunch of predicates onto it after that. So you say this is the signature, which basically certifies that all of the data being used in the predicates is authentic. And then use these to basically do the rest of what you need. So. I put a cumulative set membership. I want to shorten it to just set membership like strip this out. Yeah. But the set membership has to define. What kind of set membership. It is. Is it like a snark? Is it an accumulator? Is it a stark or whatever, right? It has to basically say, this is. Has to be like a specific. Set membership statement type. So anyway. I will not show though a set membership statement is basically saying, I need you to prove that you have a claim that's in the set without revealing it. Yeah. That's really all it is. Yeah. Equality is I'm going to prove that without revealing it. That a claim is equal to another claim. Maybe they're in the same credential. Maybe they're in a different one. Like the reason they might be in the same. Is like in a medical credential. You might have one big one. That says, Hey. These four kids all have the same parents. It's in the same credential, but I'm going to prove it's all the same credential. Versus I'm going to prove the link secret is the same in five different credentials. It serves that purpose for both of those. This can do both. It's the same across multiple statements. That's it. A commitment. I've kind of gone over this. It's a fairly simple proof. But you're basically saying, I'm going to prove it's all the same. It's a fairly simple proof. But you're basically saying, I'm going to give you a commitment, or I'm going to give you something and I'm going to prove that I know what I gave you. That's linked to this signature. Right. Domain proofs. This is one way to do that. Is with these. This is also used to link to bullet proofs. So sometimes you might need glue to link to some other proof. Commendments are usually the easiest way to do that, like the snarks or starks or things like that. This is very useful for that as well. Okay. Yeah. I promise to give Steve McCow and $10,000. Here's that commitment. And then I can prove to him later that I, it was actually 10,000 and not four or one. Because he's going to prove to me that, you know, he's going to hold me to my word. Something like that, right? That's what that is. But I get a copy of that proof. This is all recorded, right? So you can hold. Yeah. Thank you. I appreciate it. Unfortunately, dollars have now been converted to pesos. So you're probably getting. Okay. All right. Range statements. I think this is obvious. I'm going to prove that maybe a numeric claim is in a range. That's what this is. Because I'm using bullet proofs, it does require a commitment statement as well. But maybe there's a different form of range state statements that don't. So, but as defined in this library, they do. Now a commitment statement is actually really simple and cheap. So it's not, it doesn't add much. It only adds like 40 or 96 bytes. It's very, very small. Whereas a range statement, these get a little complicated, but bullet proofs are awesome because. You can compress them so that they only grow logarithmic. Unlike non-creds one, they were linear. It was really nasty. And it was three and a half kilobytes per proof and V1 per range proof. And this one, it's only 500 bytes for the first one. And then it's only like 600 bytes for two 700 bytes for three 750 for four. I mean, you get the idea. It's it's logarithmic. So it's kind of cool. You can throw a bunch of range proofs in there and it shouldn't grow too much. And then verifiable encryption. And right now this only does a discrete log check very similar to a commitment statement, but just with an encryption key versus random generators. There's more that I want to add to this based on the feedback I got from Anilasinskia. So I have to update this. Like she basically said, it's good, but it like it would be better if you did this. And so that's the feedback I want to incorporate. Okay. So that's all a presentation is. So here's everything that relates to a statement. Statements are the input. The verifiers are basically what the verifier is going to run. So here's how I verify each of this. Hang on. Is there an example of a presentation? I do have it in a test. Okay, good. So I just need to look through tests to buy things. Yep. So here's all the code that shows that it works. Okay. I'm doing four claims. I'm doing a bunch of statements like. I'm actually doing like six statements. There's the signature. There's a revocation. There's a commitment. There's a verifiable encryption. There's a range and an additional membership. So I mean, there's a bunch of them in there. So it's actually seven statements. So it's every single one of them being used and I just show that it works. So it's all there. Okay. So yeah, there's some examples. All right. So, these statements are, are what go in the presentation schema. So just as we talked about, like what goes in each one. So I kind of showed you this one. So maybe let me dive into this a little further. What's a simple one? Let's maybe do membership. Okay. So I said, every statement has a unique identifier. And then I, I define it as a reference ID. This is a reference ID. This is basically, this is saying what, where is the claim. That that was signed coming from. And this is it. I reference ID is probably badly named. It should be like a signature statement, but I also thought, well, maybe it doesn't have to come from a signature statement. Maybe it comes from something else. But in reality, everything comes from a signature statement. So this is basically saying what signature statement proves that this claim is valid. That's being used in the membership. And then as the credits only uses accumulators right now, here's the membership registry. Here's the verification key that belongs with that. And here's the claim. This should be a label, probably not the index, but anyway, for some reason I did index when I wrote this. It's fine. It still works. Basically saying, here's the claim state statement that came from, and here's the exact value that was signed. That we're going to use here. Okay. So that, and just to translate. The first is the reference ID is basically the source credential and. The. Refer is the claim within that source credential. Got it. Okay. Yep. And then remember I said all the public data needed to execute again. So for example, here's the membership registry, which is mostly just the cumulative value. Yeah. There's the public key, but the membership statement might have other stuff, but that's what this one defines it as. So this, this I'd like to abstract, but I can't think of a good way to do it yet. Cause I've only had one. And so that's, here's all the public data goes with it. Now, because the data comes from the verifier, right? The accumulator. He comes from the verifier. Got it. Okay. That's right. Yeah. All this is defined by the verifier, but see a presentation schema could be a standard. And so the verifier might just say, well, use this standard. Whatever it is in the future. Okay. Now, because we're doing zero knowledge proofs, we want to do. An integrity check on all public data that was used, meaning to make sure it wasn't tampered with changed altered, et cetera. Such that like, let's say the. Verifier says, Hey, Holder, I need you to prove this. And the owner goes, well, I'm just going to change the membership registry to the one I have. So I don't have to update it to the one he has. Right. Yeah. So we have to check that to make sure he can do that. That they actually use the real one. Yeah. So every statement has what's called. A challenge contribution. This is data that's added to the overall. Zero knowledge proof. So it's just state data. So it's just state data. As you can see, it's saying this is the statement type. This is the ID, the reference ID. It's just adding all of this data to it. Such that it's authenticated. It's just, it's just an integrity check. There's nothing fancy about it going on here. There's just a transcript that's keeping track of all this. Yeah. Under the hood. Okay. You're going to see the same thing. In here. Like with Verifier. So it's just static data as you can see it saying this is the statement type. This is the ID, the reference ID. In here. Like with verifiable encryption. Here's all of the data needed to do that. Same thing. Add challenge contribution. Notice there's nothing. Fancy going on here. This is just statements. So the statements don't really have anything special about them. Same thing here. Just a bunch of stuff. See if you're going to do a range proof there's. This is the commitment. Oh, that's why I left his reference ID. Here's the commitments. And then here's the signature from which that came from as well, because I have to do a double check. And then here's the lower and upper bounds. Here's the claim. We're going to check the range proof on. And this is this statements ID. And so on. So see, it's just adding it to the challenge contribution. Again, nothing fancy going on here. Where the bulk of the work happens is in here. So. Here's where it's going to walk through each of these. And do. So zero knowledge proofs follow the Sigma protocol or Sigma protocols, which is three steps. There's a commitment phase, which says, here's the data I am going to commit to using for these zero knowledge proofs. Then there's a challenge issued. And then. The rest of the proofs are generated. Now, when I say there's a challenge generated. Sigma protocols can be either interactive or non interactive. A non creds as we know it has always been non interactive. And thus the challenge. That is a hash that is generated by the holder. Being sent from a verifier. So if this was the interactive kind. The holder would send all of their commitments to the verifier. The verifier would then send back a challenge. And then the holder would then use that in the proofs. But since we're non interactive. All of the commitments are hashed, which generates a random challenge and then finishes it the same way. So that's just what we've always done. So probably the thing you're most interested in is this method right here. It's presentation create because this is quite long. I put it in its own file to kind of keep things simple. So this is creating what's called a Merlin transcript. This is a cryptographic. Object that is considered secure for this type of stuff. I didn't write it. And it has been audited by other people like Zcash uses it and a bunch of others. So it's well known and tested. So as you can see, I'm basically just adding all of the public data. To the transcript. Which locks it in and says this cannot be changed. Once I start this or locked in, you can't change anything. There's the challenge nonce to make sure that this presentation is fresh and isn't a replay. And then I commit to the schema. That's being used. The presentation schema that says this is the presentation schema we're going to use. And it's locked in. It cannot change at this point. And then this is just doing processing work. So I have to split out and say, I have to process all the signature statements first, and I can do all the predicates. And then this just walks through. And checks like, for example, if one signature statement says this, I'm going to hide this claim. And then another signature statement down the road says, I actually need to reveal it. That might be a problem. So this, this can fail in that case and go, Hey, wait a minute. I have a conflicting thing going on here. What's going on? So there's some quick checks for that. And then this just walks through and just processes all of the statements based on the input. So if you look at create, this is passing in all of the credentials. That they might have. I call it a presentation credential. But it's really just a credential. And then this is kind of like the issuer. Or who was it, who it was issued by. So it just kind of helps keep track of things. You can see that in the test code. It's not that hard. It looks more than it is. But anyway, this just walks through. Does the commitment phase. And then when it's done. Creates that challenge I talked about, then it walks through and finishes off all of the proofs. And then you're done. So it has a listing of all the. Disclosed messages, the challenge that was used. And then all of the proofs. All of the proofs have the commitments and the ZKP stuff. Okay. Let me think here. So. In this part of the code. Am I passing in a single source credential? Or am I walking through the presentation and all the source credentials. You're passing in all credentials that will be used. So at least one. And one, and one presentation schema. Yep. Yes. You have to have at least one credential. And there's only one presentation schema. Remember, but everything in the presentation schema is ended. So it has to be this. And not revoked. And the range proof. And so on. So how does it know. For any particular claim in the presentation. Which source credential to use, was that already defined? That's, that's defined in the statements. So if we go back to the statements, remember. It's going to only have a single one, but a overall one, the set of statements can be multiple. Yeah, you have any number of statements. So like for this verifiable encryption statement, it's only making a proof about one claim. But I might have 10 of these in there. Yeah. You have any number of. Statement though only uses one source credential. Yes. Well. Because it only uses one claim, right? Well, yeah, every, every statement only uses one claim except signature statements. Right. Because they go across the whole credential. Well, yeah, because they basically say I'm certified prove that all of these claims are signed. Yeah. And at the same time reveal or not reveal. Yeah. That's all the signature statement does. Now. Equality actually is similar because you could have any number of prove this one's equal to this one and this one's equal to this one and this one's equal to this one and this one's equal to this one. So like, I'm going to prove, let's say I have three credentials. I'm going to prove claim one is equal to claim two and, and credential two and equal to claim one and credential three. That's what this is. So this goes across all of them. In the presentation schema that the verifier constructs. How flexible is the. The ability for the holder to decide which credential to use to satisfy it. Well, so. The presentation schema is literally just a list and ordered list of statements. Well, it's not even ordered. It's just a list of statements. Yeah. So. If he, let's say he gets two presentation schemas, but they both ask for the same credential or the same cred def. He's got no choice. Right. Right. So for example, in the restrictions of an on creds, you can say, well, it's just got to come from this scheme. I don't care what cred def it comes from. I don't care what issue where it's from. Um, is that type of thing possible? It's possible, but you might have to define multiple presentation schemas. So that might be something we have to work out. Cause right now. We have to work out then. Okay. Yeah. Cause the presentation schema in my mind is it's this specific cred def. Like I said, you could do multiple presentation schemas. Yeah. I think the challenge is the example of, I need proof of a. University degree, but I don't care what university it's from. Yeah. There might be a better way to do that. I'm going to have to come up with something for that. That's right. And that could be a back and forth between the verifier and the. I have a, what credentials do you have that are like this. And then maybe construct the tree. I don't know. We'll have to think about that. Yeah. So right out of the gate. No, I don't do that. We'll have to figure that out. Yeah. The problem with, um, The problem that people come across with a non-credits as it is today is they. Is, is they. Don't put the restrictions on because they want that flexibility. Um, But then they don't realize that they have to decide if they want to construct the issue or after the cryptographic work is done. Yeah. They can't simply accept because then the person can just construct their own issuer. Yep. As a credential of the, of the right type and they're done. And that's no good either. So, okay. Well, we've got three minutes left. Um, is there anything else? So. And then there's the verifier section is. Yep. Yeah. Here's all the verifier stuff. So, yeah. And then here's the verify method. See, it just calls. You just call it with, um, Well, presentation is what is returned when you call create. Yeah. So that is sent across to the verifier and the verifier says call verify. Here's the scheme. I expected them to satisfy or that they told me they satisfied. Yeah. And the non-state I sent them. And then this just returns to her faults. Yeah. But it basically essentially walks through in a very similar way and checks everything. So everything related to verify. Um, is in verifier. Everything related to presentation is in here. This is like the actually constructs the proofs. Yeah. What's the, what's the statement? That's the only one we haven't seen. No, we walk through this. This is basically what is a commitment statement. Okay. So that was the statement on the presentation side. Yeah. Okay. Yeah. I just couldn't tell which statement we were talking about. Okay. Okay. Yeah. Okay. Yeah. I enjoyed this as well. Um, is the code available? It will be. That's what we're, that's what we're moving. To the non-creds repo. So yes, it will be. All right. Is that, is that no pressure? But is that. Eminent or is that kind of down the road? Yes. No, it's. I'm. I'm submitting a pull request or whatever. To Rai after, well, after my, this afternoon is when I'll finally have time. Okay. Yeah. The goal is to talk about this as real code next week. Okay. Yeah. This is really exciting. Very well done, Mike. Yeah. Awesome. Yeah. Thanks for tolerating my no pressure. But statement. I'm just interested. And like I said, you can run the test. You can just run the test code and. Awesome. Issues. Yeah. Signs issues. Presents and verifies all in less than a second, at least on this box. Awesome. The most complicated step is the proving it's like. With seven statements. I think it's like. 300 milliseconds. On this box, but that's pretty fast. Yeah. Fast. Like most snarks can't even get under one second. So. So I think we're good. Awesome. Sean. Do. Do not lose this recording. It's going up on YouTube. Thank you. Within an hour, hour and a half. All right. Good. Private account. All right. Thanks all for attending. Okay. Great day. And see you next week. Yeah. Okay. See you next week. Yeah. Okay. Great day. See you next week. Yeah. Okay. Great day. And see you next week. Yeah. Bye.