 All right, welcome to the February 12th, 2024 and on credits working group meeting. This will mostly be a discussion between Mike and myself as I query him about features of an on credits B2. But we'll use the early part of the session to get an update on where we are with the non creds in W3C format the V1. I'll go over the zero to release content. I'm going to raise the question in the community about a release 1.00 of an on credits. I don't know why we haven't done that quite a long time ago, but we'll look at that. And then as I say, most of the time will be Mike and I going back and forth about V2 ZKP capabilities. We are recording so others can fight out about this reminder. This is a Linux foundation hyper ledger meeting. So the anti trust policy, the Linux foundation and the code of conduct of the hyper ledger foundation are both in effect. All right. The annual review of the non press project at the should be a capitalized to see and I am in editing mode. The technical oversight committee, the hyper ledger technical oversight committee is this Thursday, February 15. There's an upcoming ZKP workshop April 24. And I W is before them. I guess I should switch that order. Okay. We have released an on credits. Whoops, looks like I have got this in twice with both the same thought but that's okay. Let's start with a non present W3C format. I see we've got two folks one from each of the groups. Can we get an update on how it's going. Martin, you should almost be finished I think. Yeah, I opened up the area in a FJ. I got some feedback from from demo. I fixed that, or I will have that fixed by tomorrow and then I hope to get it merged pretty soon. Excellent. Good stuff. I want to ask one other thing. Sorry. There is one issue open in the on and credits arrest repo. Regarding the nonsense of the proof request, which it needs to be merged at least for inter interoperability between Acaba and JFJ, or at least we need to find a solution to that. And we didn't merge it before zero to zero shoot. We did zero to zero this morning. I hadn't looked at that one. My apologies. I saw that one and I just had didn't have time to look at it at the time and haven't gone back to it. Okay. We'll look at getting that done as quickly as possible. Sorry about that. Yes, I'm pretty sure I know which one that is. Actually, do you have the number off hand? No, I started quickly. Yeah, yeah. Actually, I've got them all. It should be I want to up by sort by updated because you updated it today, I think. No team or made some comment today. I'm not seeing it is it and it's not a pull request. Oh, sorry. Yeah, and our credits are as it should be in here if it's. Oh, do you do it in Prado? No, it should be there with search it and post it. Okay. Do you have an update on where the occupy implementation is? Martin, if you get that, let me know. And I'll chase it down today. I have written it in the chat. It's in the spec read. Oh, sorry, not in the other cuts. Okay. I knew it was somewhere. Sorry about that. Now, you know what? Maybe putting it there. Oh, right. Challenge and nonce. Okay. I will take a look at this one today and shades it down. I remember your comment and I should have of it. I think this is a bad idea. I should have. I should have. Well, I knew that was important, but I just didn't have time to look at it at the time. Okay. All right. So we have a zero to zero release. We may have a zero three zero release coming up soon. But anyway, that was completed. 58 PRs total, a bunch of them were at least 10 of them were. Releases or 11 of them were releases, but that's okay. But anyway, a significant milestone includes all obviously all of the W3C format changes. I'm going to do a summary of it and make sure we get a change log and get something released about this. So Sean, you might see something coming your way. So yeah, we've got that done. So that's the zero to zero release completed. And that just happened this morning. I. I've wondered from a realizing both from an Acapai Aries and on credits why we've never done a 1.0. And so we'll likely be raising in the community the conversation of doing a 1.0 release. I'm not really sure why we don't ever do that. All of our work we tend to keep doing minor releases of a zero product versus a one. So we'll be taking a look at that. I don't know if anyone has any comments on that. But it seems long overdue for an on credits that we have a 1.0, at least to be one release. All right. An on credits V2 ZKP so at this point I'm jumping into more of a question and answer for Mike lotter. But people are welcome to join in and participate in this would love to have others comment on this. But this session will be all about V2 capabilities. First thing I wanted to talk about Mike was adding bbs plus to the library. What do you have a, if we can get someone to do that or do you have guidance on how to do that, and what roughly what the effort is to get that included. So I've kind of started on just writing the abstraction layer. But then once that's in place which isn't very much, then adding bbs plus should just be trivial. So I have kind of started on that. If we can take any bbs plus implementation we want we can, you know, it doesn't matter. If you want it externally or if you want it in Agora, I don't care. It really doesn't matter. The key is to just write the abstraction, which I'm just about done with sorry I've been kind of slanted with other stuff and my wife had a surgery last week so I've been care taking a few days. Okay. The reason this is so important is because there's a ton of interest in bbs plus but it's all at the lower level and by including it in an on prets but basing on bbs plus I think we would get, we're more likely to get more interest and more more contribution to it. So that's why I want to look at getting that done sooner than later. So I would see this as sort of the first priority at getting others involved. So let's if we can figure out to find the task. It would be very helpful. It's mainly just the first is the abstraction layer. The second is integrated. The third is add the statement and verify layer. That's it. It's not much different than punchable sanders. Yeah, that's what I'm assuming is it's it's just going to be a parallel. Yep. Okay. Recall that we did. We created in. Hang on one sec. I'll probably call it up this way. Oh, yeah. So if you want I can add it as an issue to the repo. Yeah. I think it's there already. I think it's there already so we can include that samples. Okay. So we have a set of examples in here of the various objects and we've talked about these in the past. One thing I realized was missing was the we call a revocation a specific a revocation registry. So we do need to publish that. Correct. No. Don't we have to publish the accumulator so the verifier has it. If. Oh, okay. So that's what you mean by registry. So yeah, just the familiar and the verifying key. That's it. Okay. That's what I thought verifying key and accumulator. And those are both pretty small, right? Yeah, the accumulators 48 bytes, the verifying keys, 96 bytes. Yeah. By registry. So it, it, it makes sense to keep to publish both every time. I mean, you can once the verifying keys up, it shouldn't change. Yeah. When I look at a cred def. Where did I put that? Yeah, here. I mean, this is the revocation key right here, right? The revocation verifying key. Yep. And the revocation registry is the online 24. Yeah. So there's an identifier of some kind. There's a verifying key and then there'd be a way to resolve it. And that's all that would be in there. So way to resolve it, the revocation registry, the verifying key, and then the accumulator, which is. Well, it's the revocation registry line 24. That is the accumulator value. It's mislabeled, but that's what this is the accumulator. Okay. That's okay. So those are the two values that get published over and over every time the state changes. Every time credentials are revoked or unrevoked. That's the time the accumulator changes. Yes, changes. Definitely on a revoke, for sure. Yeah. Okay. So that makes the, you know, both the definition and the registry, but there's no difference between a definition. So in a non-creds one, we have a revocation, a revered definition and an entry. The definition is sort of always picked up and it contains the initial elements and then the entry, or sorry, the verifying key and so on. And then the entry contains the state changes. And in this case, all we do is we have a revocation registry and it contains both the verifying key and accumulator every time. Agreed? You could do that. Yeah. Yeah. Okay. If you want to save on size, you could just publish the accumulator every time. And maybe the ID of the registry is the verifying key. Okay. There's only one key. And it's unique enough. That way it's a self-serving identifier. Yeah. Which case the only thing we're publishing is the accumulator every time we're spending more. Yeah. Yeah. Okay. Yeah. If we need revocations or additions at all, you just publish the one thing and that's it. Yeah. So right now, the way you've got it is you've sort of merged that into the what I'm calling the credential definition, but it really doesn't need to be. Correct. Okay. How does verifiable encryption work? I had some image in my head that's not quite right. So issuer setup, do they need to do anything? Issuer needs, what does the issuer need to do? Okay. So verifiable encryption can be done by any party. All that requires is they create a key pair. That's it. Okay. So if an issuer wants to support it or a third-party auditor, all they need is a key pair. And it would be a PS or a BBS plus key pair? BLS only. Oh. It doesn't even need to be BBS plus. It doesn't need to be a PS or any of those could just be BLS, a BLS key pair. Okay. So issuer, auditor, etc. Okay. So issuer setup, do they have to have the public BLS key? Well, the issuer has to publish the public key somewhere. The public key is basically an encryption key. Yeah. Public key has to be published somewhere. Hold on. Oh, publish. Yeah. Can it be in the credential itself? Like signed into the credential? Yeah. Does that make any sense? No. Really? Okay. I mean, you can literally sign whatever you want in the credential, but sure. So I mean, if you want it to, you could, but there's no reason for it. Okay. So they publish it somewhere, the public key. Okay. Maybe in the same place as the credential verifying key. I mean, yeah. I don't know if that's where I put it. Oh, right. Of course. Okay. It's optional. But for now, like in my examples, I just do it every time. Okay. My purposes. Yeah. Okay. During issuance. Did they do anything with it or nothing? Nothing. Okay. Holder verifier time. Oh, is there any? It can be used on any data element, right? It's not specifically, you don't have a particular piece of data that can be. No, it can be any claim. Okay. So the way I had thought about it was, you know, like you have a credit card number and the issuer gives the holder the credit card number. And that is the thing that would be encrypted when passed to the verifier, but that's not necessary. It could be any value. Any value. I mean, I've given you that example before. Like if you want to buy something, then. You know, I encrypt the credit card number, give it to the verifier. The verifier knows that credit card number is a part of the credential. And then gives the encrypted cipher text to the issuer who then decrypts and goes, Oh, okay. Yep. I'll given this proof that's proof of consent. I'll charge the credit card number. I just decrypted with the amount that the verifier verifiers asking and etc. But the other use case is you can encrypt. Say the claim used for revocation. You can encrypt that give it to the verifier. And then if the verifier ever needs to. Deanonymize this person, they can give the cipher text back to the issuer. The issuer decrypts it and goes, Oh, I know who this credential was. So you can say it's the credential ID, the revocation ID, whatever, right. They get that unique number, they decrypt it and then they can revoke whoever it was. That's another use case. I mean, this guy's the limit. You can literally encrypt just about anything. Yeah. But the point is that when you issue it, it's not associated with any specific claim. It's just given. It's just published the public key is just published somewhere. Yep. That's right. Okay. Then the holder says, Hey, I want you to know the verifier says I need to give me a verifiable cipher text. About one of the claims. So the. So the verifier has to know it. And if we go over to. Let's go here. Kind of a nice way for the verifier to request the holder get put some skin in the game. It says, Hey, if I ever need to, I can ask a third party to decrypt this. Right. So, okay, what, so this is an example of that. I've got a presentation request. I'm saying I want one of the claim zero to be verifiably encrypted. Yep. That's the revocation. That's the revocation claim. Okay. And what's the message generator? Just think of everything in here is like a parameter. So. So there's the message generator is which generator was used for. That claim. Where, where does the verifier get the message generator? Oh, that would be part of whoever generated the key. They published that too. What key. The verifiable encryption key. So when the keys published, they would say, here's the generator I used also. Okay. So you have, oh, okay. So you have to publish a generator as well. Yep. Usually it's just the, the base point, the default one, but it doesn't have to be. With a message generator. Yeah. In our case, the message generator and key are both 48 bytes. So it's pretty small. Yeah. Yeah. So a public key and a message generator are published. Okay. And a message generator is a point on the curve or something like that. Yep. Just like the public key. Okay. Just think of it as like maybe two public keys. Maybe that's the easiest way. Yeah. Yeah. That's what I'm thinking. Okay. Then the encryption key, this, this is the public key. Yep. That's the public key. The ID, this is the same as this. What's the reference ID? That's the statement. Oh, where the claim comes from. So if you scroll up, that would be the signature one. Okay. Says, where am I verified? How do I know this claim was signed? Yeah. That's all. Okay. So that, that's part of the set of statements. And then this is what I want encrypted. This is the claim number that you are from this. From the. From the credential you're going to use. I want claim zero to be encrypted. Yep. Yes. And this could be the. This doesn't have to be an index. This could be a, the name of it, right? It could be anything. It's just a way that we know how to look it up. That's all. Okay. Okay. I just chose indexes to those are the easiest. When coding. So the two keys. So all you need is the, the public information and the. And the attribute you want to do the rest of it's just linking everything together. That's right. Okay. Certain claims. Reference. To the. To. Public. These reference to the attribute to be published. Or to be encrypted. And then. So. Holder. Just. Generates the encrypted value. Yeah. We call it a verifiable cipher text. If that's. And that's going to be unique every time. Well, how is, oh, because it's going to include the nonce. Yes, there's a nonce associated with the encryption. So it does change every time. Similar to like a yes or any other cipher text system. Okay. So now we have a unique value that we've got a nonce. We've got a generator. We've got a public key associated with it. We've got the value that the holder put in. They gave that's the issue or decryption process. So you must have to pass. At least the, the, the cipher text. Plus nonce, right? I basically count the nonce and the cipher text is one thing. So. But yes. Yes. Okay. To someone that knows the. Private key. Yep. Do they need to know the generator as well? Yes, they would. No, no, they don't. It's just part of the cipher text. Everything is in the cipher text. Okay. So the nonce is embedded in the cipher text. Yep. Okay. They don't even have to know what it is because it's part of the cipher text. So. Okay. I'm just double checking myself right now. Yeah. And to someone that knows the private key and then they can decrypt. To get. That claim. Okay. Yes. Yeah. That's all they need is the decryption key and the cipher text. That's all they need. Okay. So it's a little. From a practical viewpoint, I had envisioned it a little bit that. You sort of the issuer would say, Oh, this is the thing I would use the, the encryption on this, this field. Like a credit card number, but this is much more flexible than that, which is good and bad because it's harder to use then. If you know what I mean. Um, And there's ways to lock it down, obviously, like you could say the message generator. Is restricted. Like is the hash of the claim index that you want to encrypt or something. I mean, you can do fancy tricks like that. If you needed to. Okay. So you could tie it to a specific claim. You could if you wanted to. I mean, there's no way to in my mind. But you can. I mean, we can do whatever you want. Yeah. To me, it's just the easiest the way it is. So keep it simple. Yeah. It's this trade off between. Yeah, you can do anything with it. But how does the issuer and holder and verify or coordinate what you're going to use it for? Like. The. The party that knows the private key, the auditor, the whatever. They really need to know. Yeah. They need to know. Yeah. There needs to be a purpose for why you're doing this. And if you make it that, oh, we can do anything, then that negotiation becomes a lot harder. You know, having everyone. Familiar with it and why. So that's why where some of the. You know, having opinions or making it so that you can constrain it to a certain scenario can be useful because then it's easier for everyone to understand what they're doing. Okay. I wouldn't want the holder to just say, yeah, I'll give you whatever you want encrypted. Exactly. Exactly. If you want me to encrypt anything you want. I'll just do that. Yeah, that's okay. From that perspective, yes, it could be bad. Yeah. Okay. Okay. Okay. That was super useful. Anything more on verifiable encryption? I think we've covered that one. Equality proofs. So an equality proof is where you've got a claim in two different credentials. And you will. With the same value. Well, you know what I mean is like, let's say you have it in the same credential. Okay. Okay. So this is a health record. Oh, okay. So I want to prove that all the family members have the same last name. So you can even do it in the same credential if you wanted. It's interesting. Okay. And, and basically in the presentation schema. You basically would have one reference here. And then you would have a second reference in here. And then you would have to do another field. Or well, yeah, I basically allow a list. That says this statement, this claim, this statement, this claim, this statement, this claim. So it doesn't. Okay. And remind myself, let's see, we've got this value, which is the set of statements. This is the. No, this is the overall. Presentation ID. Presentation ID. Yeah. This is this particular statement. Yes. And then these are what? Oh, these are separate statement. Each of these is a statement. Correct. And so what you would have in here was a list of other statements. You want to prove it. Do you need any other values other than just the list of other statements? So I don't, I didn't, it doesn't look like I did an example of an equality. No, it didn't. It has the problem. Yeah. So the equality is basically, it's just a list. It like, see how it says revocation or commitment or verifiable encryption. It'll say equality. It has an ID and then it says reference IDs. And it has multiple statements and multiple claims. Cause you can do more than one. Let me find it for you. Yeah. If you could give an example of that. So. Let's see. I always forget the link. It's hyper ledger. It's got to have a top level ID, a set of a combination of top level ID plus statements. Yeah. And those statements have to be in the form of. Could must reference a specific. It's, yeah, it's basically a map. So it has statement ID with the claim ID. It has the claim index, but it could be claim ID to whatever you want to do it. So it just has a list. It's a big long list. It's an array list of pairs. Yeah. Or it could be a map of pairs. You know, I don't care. Yeah. But the point is you can have more than one. Yeah. Yeah. Not restricted to one. And it is the only statement type that does allow that. Yeah. So it has its own statement ID. Yep. And then I just have a reference and it just has a bunch of references and claiming a bunch of references. Okay. And the only thing we're doing is the. Equality across them. Yep. The cool thing is it adds zero overhead. What, what does the issuer do? The issuer doesn't have to do anything. This is all presentation based. Sorry, not issuer. Sorry. Holder. Oh. The holder just handles it like any other proof. Statement, right? There's no extra data that he has to do if that's what you're asking. There's no like setup or anything. Okay. No. But they, they have to create a proof statement. That references that, that takes his input, all of these IDs, all of these statements and claims. Yeah. Yeah. Okay. And the verifier runs some sort of verification. Yeah. Well, in every case. How this is the, and I'm. And this is a very easy way to think of it. When you're generating a proof, you have the presentation. Request. Right. Yeah. It has all your statements. And then the holder has all the private data, which is all their credentials, right? And data that was signed. Yeah. And then the verifier uses the same presentation request. But on his side, he has a proof instead of all the credentials and data, right? He just has the, the resulting proof and data that was sent. Yeah. He takes the very same. Presentation request. Did this was this proof match this presentation request? Yes. That's all he gets is a yes or no. From that. If there's reveal or disclose claims, obviously he gets that information or any predicates that were disclosed, right? All of that comes through. And this is going to be very similar to the. Aggregate proof in an on credits V one, which correct me if I'm wrong. Is the thing that proves the link secret is the same across the credentials. Yes. Well, no, the aggregate proof proves that everything belongs to one identity. That's pretty much all it does. And that, that, that happens with this. Like if you go look at your examples of. The final proof that was output. I know you have one. Yeah. Yeah. I know you Steven, you can't hide it. What's that? I know you have it so. I think that's it. No, that's the signature. Go down, go down. No, that's the range proof. Good. Keep going. Keep going. Right there. The challenge, the challenge basically is the just, I just renamed it. That's essentially what is, but that's the aggregate proof right there. Same thing. What? Yeah. Hold on. Hold on. I thought this was the knots. Well, But they have to be renaming it to challenge for. Okay. What is this? It's called the Fiat Shamir challenge and non creds v1 had it too. And what is it? It's the aggregate proof. If you want to call it that. And. Okay. And what is it? What is the aggregate proof? The aggregate proof is proving that all of these. Proofs were generated by one. Holder, one set of holders or whatever, you know, that all the proofs belong to one person. And all the proofs are like that part of the same thing. Think of it as like over all of the proofs. Okay. It's basically saying these all came from the same. Generator, whoever created it. Did all of these. But it's got nothing to do with the lake secret. It's got nothing to do with the lake secret. Nope. Never did. Never did. Oh man. Okay. And, and, and why does. What does it do that? What is it show? Think of the, the challenge. Yeah. Or the aggregate proof as a signature over all of the proofs. Cause that's basically what it is. And then create a signature over all of the information. Why could I have not gotten us the proofs from different parties, put them together and then create a signature over them? Um, well, you could still do that in v one, too. That's not good either way. Why not? It just proves that whoever generated the proof knew all of the data. Oh, they knew that the raw data. Yes. Okay. Think of it as a way it's grouping it all together. Cause, cause if all of those proofs were like, let's say one of them was generated last week and one of them was generated yesterday and another one was generated now, that wouldn't work. Yeah. So you want that aggregate proof since that's what I'm going to call it that since that's what you're used to. Yeah. Okay. Maybe it may be a good way to say is it proves how fresh everything is. Was it generated now yesterday, 10 days ago, two weeks ago, 10 months ago. So it's similar to saying use the same knots. Yeah. It would basically say is this a nonce reuse attack or not. Okay. So in all of the individual proofs that use the same knots and that's proven in this. Is that right? Yeah. Yeah. So just for my simple case, I just basically say the proof request ID is a nonce. Okay. And I just incorporated that. Basically I have, I hash everything, right? I include everything the entire proof request, all the data, all the static, all the dynamic stuff doesn't matter. I just, I just include everything. All of that is included in that signature. Okay. The fact that it's not tied to the link secret kind of blows me away. I thought that was the thing. So is there anything in V1 that shows that the same link secret was used in all of the multiple credentials produced? Yeah. That's basically it's doing an equality proof under the hood. You just didn't realize it. It does automatically. This equality proof says it can be for anything. Whereas like in your non-creds V1, the rust code just did it automatically without even telling you. Okay. So it's there. The only thing I was wondering was that the, with a, with the blinded link secret, it's, it's a layer deeper. Like if I get a credit card number, no, sorry, that's a, if I get the name, the names are in plain text in the two credentials. In an equality proof, an inequality proof just says claim one is the same as claim seven and this other credential. Because you're using, you're using the encoded value. Yeah. Yeah. It's a proof. Cause if it was plain text, you can just look at it and go, oh yeah, they are the same. Oh, I'm going to push this a little further. Um, it, it, in V1 in the, in the link secret case, each verifier, each issuer gets a different blinded link secret and, and you're proving that the underlying link secret is the same across them. So it is an extra layer deeper. Well, you can still do that with V2. I'm sure you can. I'm just saying it's not quite the same as an equality proof where you're proving the name is the same because there, the basis of the claim is literally the same. Very, you know, what the, what each issuer handed out was the same. Mike Lauder was handed out to, from each issuer and you're, you're checking that's the same here. You're getting each issuer is getting a blinded link secret, which is different. Each, each one is different. And then showing that that was based on the same link secret, like the blinded values were based on the same link secret. So the equality proofs got to be more. Another layer of complexity deeper. Nope. Right. Nope. It's the exact same proof. Really? The, the verifier does not care whether it was blinded or not during issuance blinded only affects issuance. It's the exact same proof. Okay. Okay. Abstracted it and said, Hey, this could be useful for other things than the link secret. Yeah. So in our case, we can just say, we'll always require an equality proof across current claims. For the link secret, but you could also do other things. Like I said, if you want to do a medical claim credential, you could like maybe here's all of my dependence and I can prove they all have the same last name. Yeah. In. So each of these become so the, yeah, each of these state, each statement would have a different one. Okay. Each statement would have a different proof associated with it. Correct. But if the aggregate fails, it doesn't even bother doing the individual ones. And you're saying aggregate first, the equality proof embeds both the link secret. Well, it can be used for anything. So you can, for a non-crit V1, you guys just implied that there's an equality proof for the link secret. Yeah. It implied it's there, right? Yes. Yeah. You're basically just saying we will always put one there. We will always put one there. Okay. You can do the same thing for V2 and just say we're going to, since we require the link secret, we're always going to do an equality proof if there's multiple credentials. Okay. Let's do the same thing. It's no different. The math is literally the identical. Yeah. No, I'm just trying to figure out where it's represented in V1. Oh, it's under the hood. You never knew. That's the thing. Okay. There might be more questions on that one. Okay. And finally, the domain proof. Let's talk about that one a little bit. So a domain proof is where you get a consistent identifier for a verifier, but the value is different. I assume there's no issuer setup for a domain proof. And what do you call a domain proof? You call it a commitment, right? I call it a commitment. Yes. The issuer doesn't do anything. It's whoever is collecting the domain proof has a setup. And guess what? It's identical to verifiable encryption and that you, but there's no decryption key. You just create two keys and that's it. So the verifier gives you two keys. So let's, I think we've got examples of that here, right? Yeah. That's, you see. Right there. Commitment here. So, so the verifier creates the generator. Yep. Both of them. Both of them. And, and you just tap it to call them two different things. They should have different values if they're identical. Two different values. Okay. Message and liner. Okay. Blinder is used instead of encryption key. So that's why I said it's very similar to verifiable encryption. There's just no decryption key. That's all there is. Okay. And the holder does the same thing as, as. Verifiable encryption. Yeah, pretty much. And. And as a specific claim use, okay, a specific claim is used. And so they would have to know that, well, that claim is going to be consistent every time you use it. So it really doesn't matter which claim you use. Nope. They're using claim three. And then. But they would want to use the same. Same blank, same keys. For every person and every, and. For every presentation request they send. Right. You just use the same keys. Same keys, but remember they're randomized every time. The proof is randomized every time. Yeah, yeah, exactly. This is a voluntary thing. By the holder, right? Yeah. So if the holder left it off, the verifier would say, fine, go away. Yeah. So they would have to pick the same claim every time as well to get the same value from the same holder. Right. Yes. Yep. Question. Yes, I. I've been enjoying this. So I didn't want to interrupt, but I just noticed we're getting on. On to the end of time. And I wanted to. Ask a question. I was in another. Presentation of this a little while ago. And one of the slides mentioned a call home functionality. That's kind of a hot button. So I was wondering. If I understood that correctly. First of all. And then Mike, if you, if you could kind of talk about. What, what's going on there a little bit so I can know if I need to be happy or worried. So this will be happy. Always be happy. This is for revocation. Mike, I think this was for revocation. Correct. So the idea there is that instead of having a public place where the revocations information is retrieved, like a, a ledger or something like that. You call back to a component. That, that does it. And so we've got a couple of places where. Where we can mitigate the call home, but Mike, do you want to. Yeah, yeah. So Steven, probably what you're worried about is. Does the verifier. Call home to the issuer. The issuer learns who presented. And now you're toast, right? Information. You're in trouble. Yeah. That's not what's happening here. Okay. So let me explain how it works. So. One of the problems with revocation is. You either have to download a massive list. And the, it, and the holder has still has to disclose something that says, I'm in this list. Right. That's a vacation list 2021 works. So yeah, the issuer doesn't know who presented, but the verifier sure does. And it's a correlating identifier. Can be. Yeah. So. To mitigate that. You can either download a bunch of changes from a public place. Like say a ledger, and then the holder applies a bunch of mathematical operations based on that to become current to say, Hey, I'm still not revoked. Or he's going to have to call home. So the downside to downloading information from a public place is it penalizes the holder the longer they're offline. So. That's a problem, right? If I go offline for a year, I have to now download everything from the last year to now, which that does leak information about me because it says, Hey, I've been offline for a year. Right. So that's bad too. So the only alternative was to phone home to the issuer and say, All right, I need you to just make me current. So what I've done in the paper is published. It's called Alasor Alasor says, All right, let's add an additional layer of privacy that says when you phone home, you're not going to disclose who you are either. All the issuer is going to do is receive a proof that says I'm, I hold a valid credential. You don't know which one. And I need you to just give me an up to date. Result for this version of the accumulator. That's it. So the issuer does not know who's asking to be updated. They just know they're a valid holder of a credential. Now, if this holder is revoked. When he gets the value back from the issuer, it's just going to be invalid. If he never held a valid credential at all, let's say this is an attacker that somehow was able to forge that he had a valid credential. The value he gets back is absolutely worthless unless he knows all of the original values. So only a non revoked holder that knows his values gets back something he can actually use. The privacy is preserved in that he, the issuer does not know who's asking to be updated and he doesn't know how long they've been offline. And so you're not penalized for being offline either. So that's what the phone home option is, is the holders basically saying, Oh, there's been some revocations that have happened since I was last issued or brought current. I need to talk to the issuer about becoming up to date. But it doesn't disclose who who's asking. Okay, so then the holder is the one making the request. Yep. The issuer, nor any verifier know who's making the request. That's right. So the holder just gets something that brings him current. Now the verifier all the verifier knows this is the verifier saying, are you revoked as of some time, right? As of now, as of a week ago, as of 10 minutes ago, you know, whatever that is, right? It's the holder's responsibility to make sure that he's current as of whatever the verifier is asking. So all that information of the holder becoming up to date, the verifier does not even have to know any of that. All the verifier gets in the end is a revenue, non revocation proof that says I'm not revoked. That's like in the one. Okay, that makes a lot of sense and I'm going to go. Well, hold on the paper. Well, make sure you don't fall asleep during it because it is quite long. Hold on holder to issuer. What, what information does the holder pass to the issuer in order to get to request the update? Well, we've talked about that in the past. I know I'm just want to go over it again. Okay, so in a nutshell, he's basically passing he could be he's basically passing a signature proof that says I hold a valid credential because you don't probably want anyone to just ask for this. Sure. And then why not. What? Why wouldn't you. Mostly for throttling because I could do a denial of service on the issue where it says give me a bunch of these right. Let's call that optional. Yeah, it's optional. Yeah, not required, but that's just a way of throttling people from asking so you basically say well I'm going to make sure only valid users can ask. But in a nutshell, the holder does a Shamir secret sharing split on their say index or elements that is in the accumulator. They do any threshold and any maximum number of shares they want, and they can send that to the issuer. So the issuer has no idea if this is the first if this is the 10th if this is the 200th it doesn't matter. And the issuer could also be thresholdizing his side of things that's the other thing that Alasor does is the loud threshold management of the accumulator. But in any case, the issuer just says oh I've got an update request. I'm just going to do something and send it back. That's it. There's no MPC involved nothing. The issuer just does a minor computation sends it back to the holder. And then when the holder has say let's say they did 10 of 20. Let's say he's gotten back 12 requests can go all right I'm just going to burn these two at and then work on these 10 it doesn't matter. And then I'm now current. That's. So, Steve, did you catch that so basically, instead of calling. So essentially the holder has to send the accumulator plus their element their contribution to the accumulator to the to the issuer but that would but that would be a unique identifier for the holder so in order to mitigate that they send and shares. They shard their element into shares and send any of them off to the whole the issuer the issuer can't reassemble those shares. And so they are that keeps the keeps the element secret. That's what that's what mitigates the call home. Does that make sense. It does. I'll have to read through it and ponder it but in conceptually it makes sense. I do have one quick suggestion. So the phrase call home or phone home those are becoming politically charged words. I don't I don't mean like, you know, you know, red state blue state kind of stuff what I what I mean is, there are lawmakers that are actually chasing privacy solutions that are fixated when they hear words like that. And so now that you've explained it I understand it differently whereas that was the nature of my question. So, maybe if we could call this anonymous update the, you know, update the accumulator something along those lines that doesn't have the word bone or home in it. Privacy respecting revocation update or something I don't know. Yeah, I could be it could be a lot of things. That's what it is the holder just needs to make sure he's current. Right, right. No, I, I think this sounds good to me other than that's what got my attention because I've been, I've been hearing that a lot from like lawmakers and stuff. And so I want to make sure we don't get sideways with that inadvertently. And Steve, the reason I wanted to actually use that was because that would be a disaster if this is if that was specifically how it worked and, and, and the problem is, you are going back to the issue or to get updated information you're just doing it in a privacy preserving way. And so that's the difference. Yeah, no, and that's fine. I mean, the, if, if, if a verifier is asking to prove that you're current within 30 days or something. And you have a regular setting in your app that updates that accumulator weekly or, you know, whatever time to live you set for it. Then all of a sudden that's a regular predictable occurrence and is not really giving any new information. So there's, there's ways that you can mitigate that so that it isn't a, you know, I'm verifying this right now. So, you know, then you can start to put data points together. And so I like the description and, and that's my only comment on that is, yeah, if we could just kind of change the name and then when somebody says well what is update the accumulator is that a phone home because that's a logical question. Then everything you guys just described right here would would be a really nice description. Let's say private private update, revocation update versus. Yeah, no, I like, I like actually this. I like this on this update. Yeah, okay. Yeah. I might have to add what what you're updating but yeah you're revocation handle or witness whatever we want to call it. Yeah, that's like that. Yeah. I would recommend we don't say hey we will just update on a periodic table say once a week, because yeah, or what we do you can't hide time right yeah. So anybody observing would be able to say hey I've noticed this from this IP address they're asking for revocation update on Sunday at 10am right you can't hide that. I don't know if he's going to hide that other than encryption but suppose suppose it was all done in the clear, because the, because the attacker somehow did a man in the middle right. That that's the scenario I try to plan for in worst cases, suppose an attacker can see everything can he still learn who I am. Yeah. Mike one more question if I send and shares in a single message so I send one message, but I send an array of shares. There's still no way for the issuer to put that together to to get the unique identifier correct. Because, well, because the thing is the issuer doesn't know what index those shares belong to each of those shares unique index so he doesn't know the end. And also if you wanted I could throw garbage shares in there so you can't call the difference between garbage shares and valid shares. Okay good. That's what I wanted to make sure you told me that before I just thought this was a good time to check it again. And that and the reason I say that is because then you can do it in a single request response transaction versus the holder sending 20 messages and then getting 2020 replies. Well, because when we designed the protocol we were, you know, you have a reputation manager with a decentralized network. So the folder could talk to 30 nodes and those notes and have to talk to each other so that was the goal in mind. Yeah, yeah, you could do what you're suggesting not that I would, but you could do it that way. Exactly. Okay. All right, we're over time. This was a great conversation Mike. Thanks. Probably this is my plan for next week is to go. I do want to get some of these into write ups and start to build out the be the V2 SPAC with details that's what the goal of these sessions are next one I probably want to talk about is claim schema format. Thanks all post the recording as soon as it's done. Have a delightful day. Thanks. Thanks everyone.