 All right, welcome to the February 5th, 2024, and on Craig's working group meeting status update on where we are with W3C format update and issues going along with that. I saw PR from Timo this morning that we can touch on. Then I want to query Mike on Allisaur revocation, particularly perhaps verifiable encryption and other ZKP capabilities. Allisaur is the main one I'm really interested in talking about today. I think we're actually based on the work being done. I'm actually very close to wanting to put together a first cut of the Anarchvitev specification. So that becomes a possibility out of this. Let's see, a reminder, this is a Linux Foundation, Hyperledger Foundation meeting. So the Linux Foundation anti-trust policy is in effect as is the Hyperledger Code of Conduct. Please be good to one another. Meeting agendas, it's actually not listed on the page, but I should put that in. But if you want to add your name to the attendees list, any other topics to go over today on this call? Stephen, at the bottom of the open discussion section, I left links to two workshops that are coming out of Hyperledger in the next few months. This Thursday, we've got decentralized identity and interoperability connecting Prado with Hyperledger Bezu, Cardano, checked Hyperledger and Oncreds and OpenID Connect for VCs. And then April 24th, there's a zero knowledge proofs. Zero knowledge proofs in ZK programming and blockchain application development. And you have to actually save the Wiki page for you to be able to see it. So now it's, sorry about that. If you hit save, I'll hit save and I can see it. Do it, you got it. All right. You know, and those are the links to the registration. Sorry, everybody. There they are. Who's doing this one, Sean, the ZKP one? That would be Daniel's, I'm gonna, Daniel Zego and hang on. Andras Zaborsi. So Daniel, he's been a community contributor for a while. He and Andras have put this together and it's happening in late April. Okay, sounds good. We need to get some on the list. So I'll be thinking about that. Got some other discussions going on on that. Over to folks working on the W3C format status updates. Any updates you wanna report? Let us know or any topics you wanna go over. I was thinking maybe Martin can do a short demo of the implementation in AFJ. Yes. So Kanashayama's coming. Yes, you may. I think it should just work. I hope. Let me know if not. I also need to update my preferences. That's probably, if you're on a map, you'll probably have to leave and come back. So that'll be okay. We'll wait for you. I'll come back. Yeah. See you in a moment. This is what we're trying to do with SSI also, right? Giving user control over how your data is used. Well played. Welcome back. Thanks. So let's try again. Excellent. Can you see my screen? Mm-hmm. Yes. So in AFJ or in right now, we are mostly finished with the changes. There are a few small to-dos now, but the biggest parts are finished. We can now issue credentials with the new data integrity format and also request proofs via the presentation exchange and convey the credentials in the W3C format, right? I have a branch on my GitHub where I have created a demo. So where we have two agents, Feather and Dallas, kind of like the old demo if anyone knows it, which is how we can issue a credential from an agent called Feather to Alice and then send a proof request from Feather to Alice and get a response. So we could also use that for interrupt testing because you asked last time. Yeah, I can also quickly show you and killed how that looks. Can you see this code? Yeah. Yeah, mm-hmm. Yeah. Yeah, just very simple. Feather, which is the issuer and site imports a few static dates. I used checked now because it was simpler to do the implement. So we imported it and we registered schema credential definition, create a connection with Alice or with another agent. It's not important that it's the same or that it's credible. And this is how we can offer a credential in credo now. So we just specify the connection ID. We say that we wanna use the new data integrity format binding required. We now want binding and reusing the island credits link secret binding method. And we also pass in the credential or the W3C credential here. It's not a very final credential yet, just the W3C credential. Yeah, the claims master line with the, which what is contained in the schema, obviously, but that's it. Then for Feather, we just wait until we receive our request and then accept it. Let's just continue for the Feather site here. This is how we request a proof. Also very simple, which is the state is the agent that proofs that request proof. And we say we wanna do it using a different presentation exchange. And all we need to do is provide the presentation definition. This should be exactly the presentation definition which we used in the test vectors repo. So it should be, I think that's pretty nice. We want the data integrity protected VC in return with Nanocred's 2023 signature. I could remove this passenger dealer. Then the Feather just accept the presentation. Let's just see also quickly look at the other site where if we receive or Alice receives a credential offer, we just say that we wanna accept, we provide the link secret ID with which we want the bind the credential to. When we receive the credential, we just accept and process it. For the proof request, essentially for Alice, exactly the same. Yeah, we select the credentials for the request automatically. Then we just accept the proof request once we receive it. Yeah, I can also quickly run it here. So let's see. Can you read this or is it a small in the terminal? Yeah, perfect. Good. So for Feather, for example here, we can just create a connection invitation. Alice receives the connection invitation. And then we can offer credential here from Feather to Alice, which we've already checked from now. Nice. Which registers the schema credential definition. That always takes a little bit. Yeah, nice. So the credential offer is sent. We also see that here credential offer received. We want to accept it now. Yeah, again, the first accept it and that's it. So yeah, the messages are not so nice. So I'll refer that. Did you receive the credentials? It's processed. We can also request a proof. It's the same there. The proof request is received here when we want to accept it. Yeah, and here at the Feather site, we see that the presentation was accepted. Nice. I can also quickly show this is how the presentation submission and the presentation itself looks like. So for the submission, we just have, let me make this a bit bigger, we just have a random ID here than the presentation definition ID. The descriptor ID for the age verification, which we called it, which says that we have a data integrity verifiable presentations at this path here in the presentation, verifiable credential zero. Yeah. So here if you look at the presentation, which Faber or the Faber received there, then we can see that there is one credential. So essentially it's pointing to this here, this is, and you can see that it's like this. It's high descriptors, it's out of print strength, but you're free. It's data integrity protect. Excellent. So that was all from my side, unless there are some questions. I love that line. That's all from my side. That's a whole lot, Martin. That is awesome. Excellent. All right, any questions for anyone? Yeah, indeed. Very cool. Okay. The folks from the Acupy team are meeting after and I'll make sure they're aware of this. I might even extract out the video of this and have it as a separate part, so we can just demo that and it can be shared more broadly, just that one section. Excellent work, fantastic. Okay, that is that side of it. Any other questions, comments on that? And then we'll move on to Mike talking to you about revocation. You ready? For me to talk about it? Yeah. Yes, so I've got questions. So I'm gonna do a question and answer on this. Anyone can jump in at any time, but I'm hoping to sort of facilitate a conversation and understand it. So Alasaur, for those not aware, is a very high, a scalable revocation scheme in zero knowledge, so has the same attributes as the existing and non-crit revocation in that an issue or can issue a revocable credential a holder would receive the credential and when asked for a presentation would be able to prove without sharing a linkable identifier that their credential is not revoked such that the verifier would believe that. In this, in the current work, the way it's done is the issuer publishes the state of the revocation registry which is a combination of an accumulator value and then the status of all of the credentials as being either revoked or not revoked onto a ledger or into some public place such that the issuer or the holder can retrieve that, do a calculation based on the state, present that to the verifier and the verifier needs the accumulator to be able to verify the presentation, the non-revoked presentation proof. Allisaur changes that in that rather than publishing the issuer might publish the accumulator, but other than that uses what's called a revocation manager and I'm gonna get corrections and so on over this, but let me just give my quick overview. A revocation manager that works in based on knowledge and information from the issuer is able to receive a request from a holder to update information they hold such that they can produce the proof that corresponds with an accumulator. They, the holder constructs the proof sends it to the verifier, the verifier retrieves the accumulator and verifies the proof. The revocation manager can be a single instance of a revocation manager, in other words, that all holders contact a revocation manager or more interestingly, there can be multiple revocation managers and the holder can shard their key, split their key, the information they provide to the revocation manager send it to a bunch of different ones, collect the results and then assemble the information necessary to create their proof. So that's the overall scheme. So a similar scheme and similar interactions and from what I understand, but we'll find out more similar data to what's done with the existing revocation scheme, but in a much more scalable way in that, there's no tails file to be shared or anything like that. The revocation manager holds a bunch of information and is able to do what it needs to do in interacting with the holder so that the only data that's actually passed back and forth between the participants, between the issuer and the holder, the revocation manager and the holder, the holder and the verifier are quite small pieces of data on the order of kilobytes and there's no need to pass big massive files around at least amongst other than the issuer and revocation manager, but that's what I wanna explore as part of this is what is the data that is passed around, not necessarily from a precise cryptographic definition, but more attributes of that data, like is it a linkable identifier? How does it relate? How do the pieces of data relate to one another? And that's what I wanna ask Mike about. So that's the goal of this session. So we start with what do the issuer and rev, what's the relationship between the issuer and revocation manager and what data do they share or how does the issuer keep the revocation manager up to date? Okay, so let's define what all the data bits are and that'll help with answering that question. Okay. So the bits and pieces of Allosaur are, you've got the accumulator that is basically a fixed size digest that represents the entire set. So I don't know what you wanna call that. Yeah, that's fine. And sorry, I might say fine. I'm having, feel like I'm having more conversation with Mike and documenting, but anyone jump in at any time and raise your hand or just come off mute and ask questions. So accumulator just is a single value that takes into account all of the data from all of the credentials that have been issued. Correct. Yes, that is public, right? That has to be public. Otherwise no one could make a proof. Yeah. But the cool thing is it doesn't matter how big the size of the set is, this value never changes in size. It's like, if you had shot 256, doesn't matter what the pre-image was, whether it's a gigabyte image or if it was just like your zip code, the five digits, the output is the same size. So then there are the elements of the set. Okay? Yeah. Now, this is where I'm trying to not blur the line between the cryptographic value that's added into the accumulator and something else. So in reality, you could make these whatever you want. So if you look in the non-creds V2 Rust code, I just made these UUIDs that get hashed. So it's no different than a hashed schema element or claim element. But you don't even have to do that. You could just say it's just a random 32 byte value. Okay. If you want. And this is shared. No. And this is what the holder gets so they know which credential is theirs. Yes. So here's the thing. The issuer needs to track every one of these, right? This is like equivalent to what goes in the tails file kind of thing, right? Yeah. But only the issuer needs to know this. And whenever a credential is signed, obviously only one of those values is given to the holder. That in a non-creds V2 Rust is what I call just their revocation claim. Okay. This is what gets revoked, essentially. Yes. That is when you revoke, that is removed from the accumulator. So technically the zero knowledge proof is a membership proof that your value is in it. Yeah. Got it. So that's different from the way we have it today, which is that the holder gets the index of their credential, one through a thousand or one through 10,000. And today the index points to the item, the element similar to this thing in the tails file. In this case, they actually get the element and the issuer is tracking the, whether that element is included or not in the accumulator. Correct. Okay, good. Okay. Yeah. Third value. And again, we haven't defined what the terminology should be. Yeah. Is, well, at least in non-creds, when we call it the witness. Yeah. I'm trying to, for V2, I tried calling it the revocation handle. You could also think of it as a revocation signature. But either way, this is another piece that is known only to the holder, but it's created by the issuer and handed over. Now, without knowing the element of the set and this witness, the holder cannot create a valid zero knowledge proof. They have to have both to create the private proof that says I am part of the set. Okay. So. Hang on one sec. Oh, you're fine. Needed with the element. Yep. To produce the holder's NRP, non-revocation proof. Yeah, that's fine. Okay, good. Okay. So those are the three bits of data that are associated with Allosaur. Okay. Oh, wait, wait, wait, one more. The fourth piece is the signing or the secret key associated with managing the accumulator and then obviously a public key, an associated public key. Okay. These are known only, well, at least the private key is known only by the accumulator manager or issuer, if they're one and the same. The public key is also published with the accumulator, but obviously it's probably never going to change. But in order for anyone to verify an NRP, they have to have that public key and the accumulator. They have to have knowledge of that. Those are the two public pieces that have to be known by anyone who wants to verify. Okay. So now that we have- And one more thing. Mm-hmm. Must have the, whoops, and the public key. Sorry. Just to confirm, when a holder makes a, creates an NRP, they use a particular accumulator so the verifier must know the same accumulator. Correct. Okay. Yeah. Yeah. Yeah. So not, well, and then that's where I'm going next is, now that you know what the four pieces of data are, there's the keys, the accumulator, the witness and the elements. Now, who knows what? Now we've kind of covered that, right? Obviously the keys and- Well, now we've got this. Okay. So now we talk about this revocation manager. Yeah. You want to separate- Because that's a new, that's a new concept to those of us in the non-creds world. So talk a bit about the issuer, revocation manager relationship. They could be one in the same. Yeah. But they don't have to be. So if you had like a third party, well, and here's probably why we separated out. Alasor allows thresholdizing the secret key to do the updates. So that was one of the main innovations of the paper is to be able to manage the accumulator in an MPC threshold way. So if the accumulator manager is different than the issuer, then that means the private key or secret key could possibly be split among a distributed network, like a DLT, right? Or a blockchain or however you want to do it. And then when the issuer says, I need you to revoke this, they would have to obviously maybe go through some access control policies to make sure they could do that. And then the revocation manager would publish the updates once that, if they determined the issuer was authorized to do that. But if they're one in the same, then in either case, the only time the accumulator has to change is when elements are removed. So before with most accumulators, anytime you added or removed values, you had to update the accumulator. With Alasor, you have to update on removals. So you cut down on half of the work, which is great. So that's the relationship between the issuer and the accumulator manager. The issuer just basically says, I need you to remove the following values and proves that they are authorized to do so. Then the revocation manager removes those values from the accumulator and then returns the new updated value, the new accumulator digest, whatever you want to call it. That's it. Hold on. Elements that are removed and the new accumulator. Is that right? Or do they just calculate their own new accumulator? Well, the revocation manager would calculate the new accumulator value. Okay. If they're separate, yeah. Yeah. Whatever holds the revocation keys has to do the update. So if the issuer does not have those, the revocation manager does. If they're one in the same. Requires some part of the private key to be able to do this. Yes, you have to have the private key to do any removals. And now, do the revocation managers keep hold of all the elements or do they just hold on to the accumulator after they process them? Sorry, say that again. Do the revocation managers have to remember all the elements that are removed or do they? Someone does. Okay. So obviously the issuer does. Well, no, the issuer would. Okay, so yes, they do. Yeah, the issuer does. Now, when they want to create a new credential, for example, the issuer. Well, hold on, let's go to issuer setup. So what has to happen? So we know the relationship between these two now and what they're gonna do. So let's go to issuer setup. Well, so hang on, there's one more thing. When the issuer wants to create a new credential, they have to talk to the revocation manager and say, I need a witness for this element, right? Because whoever has the key can create witnesses. This is usually why it, I mean, if the revocation manager was like, obviously malicious, he could just create it for whoever, whatever. But, assuming he's honest, the issuer is storing the elements and the revocation manager doesn't have to remember those. Okay. But the issuer says, I need you to create a witness for this element and give it back to me. So then the revocation manager, obviously, he's authorized as the issuer says, yep, okay, here you go and gives him a witness, which is then forwarded to the holder. Okay. So now for issuer setup in terms of revocation, they just have to decide what the elements look like. Do they want to do what I was doing, which is just generate a UUID that gets hashed or maybe it's some random string gets hashed, it doesn't matter, or they just gonna take a raw value and use that. It doesn't really matter. That's really the only setup that they have. They have to determine where the accumulator gets published along with the verifying key. So maybe the revocation manager has no say in where those go, the issuer does. Obviously, if they're one and the same, it doesn't matter. But the accumulator value has to go somewhere. Maybe the issuer just holds onto it in the public key, but anybody who wants to verify has to have access to those values. Otherwise they can't verify anything similar to the credentialed public key. You gotta have that too. Yeah. And presumably they have to tell the revocation manager, hey, we've got a new revocation registry, right? Yeah, that's what, yes. So then the issuer says, hey, revocation manager, I need a new registry. And at that point, the revocation manager will create new keys. And the new rev, and the new accumulator value. And return that to the issuer. Okay. Now the interesting thing here is every time we talk about, we contact the issuer or the holder contacts the revocation manager, it could be done as in a sharded way so that you're doing this in a multi-end NPC. Is that right? Correct. Yes. So even on issuer setup, when you say, I want a new revocation, would the issuer create the key and then send it, shard it to each of the revocation managers? I think you're maybe mixing concepts here. Okay. Who controls that private key? I thought the issuer did, but you're saying actually the revocation managers do? Yes. Yes. Okay. Whoever's making the updates to the accumulator hole has to hold the keys. So if you're doing it in the threshold setting, then it's the revocation manager. If it's the issuer, then obviously that's where the key should live. Okay. And they can do that without coordinating with one another. They can do a partial key without coordinating with one another. The revocation manager? No, they'll usually use like a distributed key generation algorithm to do that. That way no one entity or computer holds the whole thing. So obviously there's like a bunch of these NPC networks that do DKGs where some of the holders have, it's like partial custody, right? Where your phone holds some of the keys, they hold the rest of the shares or there's lit to, it's distributed among the whole network or the issuer and the revocation manager could do it that way. Either in either case, you could do it in a distributed key ceremony so that the key is split among multiple parties. And none of them ever had the whole thing at one time. Yeah. And the issuer would publish the public key? Yeah. So in my mind, if you wanna have like the best architecture you can, you basically say the revocation manager sole purpose is to manage the keys and witness updates. That's all he does. Yeah. Okay. So obviously he has to remember the latest accumulator value, the public key, the, obviously the key, the private key shares are split among multiple parties and that's it, just those three things. And that's all he does. And then the issuer is the one who's remembering all the elements where the accumulator and public verifying here are published, who's revoked, who's added, et cetera. He's basically, in my mind, the issuer should be responsible for all the decision making and business logic, whereas the revocation manager is just all the cryptography for the most part. Okay. But like I said, they could be one and the same if that's the easiest. They don't have to be separated. But this, it allows this obviously to happen. Yeah. Okay. So now we're going to issue a credential. Okay. So the issuer picks an element, could be generated on the fly or maybe has a preset list, doesn't matter. And then the issuer says to the revocation manager, I need a new witness for this value, for this element. So then the revocation manager creates a new witness, like I said, it's similar to like generating a signature, sends it back to the issuer, and then the issuer can then forward that piece of information along with the signed credential to the holder. Credential element and witness. Does, I'm wondering about... They may want to give them the accumulator value as well. Just so that the holder knows, this is what it was, like the version of the accumulator that I can prove against. Okay, put question on that. What about a timestamp to know when it was created? Sure. Is that necessary? It seems to me that would be necessary, not just sure. Well, why would it be necessary? Because that associates the witness and the accumulator together, so that if the verifier has to independently go get the accumulator for the given witness, it knows which version of the accumulator to get, because the accumulator will change over time. Well, that's why I was saying you give the current, you give the accumulator value also to the holder so they know what version they had. Adding a timestamp in my mind is just optional if it makes it easy to say this is when it was done. What about version, no, sorry, version, I mean. Oh, well, the accumulator every time it changes is like a digest, right? It just changes. So yeah, that's what I'm saying. You give that to the holder and they say this is the version I have. So version of the accumulator is needed? Well, it's like a digest, right? So anytime... Sorry, and then I don't understand the term digest. So what does digest mean? Think of like a hash. That's what I thought. Just all I think of it is a hash, but I don't know whether this is the... Well, the thing is you don't need to hash the accumulator because it basically is a hash. It already is. If anything is removed at all, if it ever changes, it basically is a new hash. So that is your version. Okay, fine. I want to add a fine step to it. That's fine too, doesn't matter. But just, this is what I'm trying to understand. If as a holder, I'm going to send a proof, the element and a witness to a verifier and the verifier is going to independently go get the accumulator that's associated that is the correct accumulator of all the accumulators that have been created. It's going to use the right one. How is it going to know which is the right accumulator to ask for? Okay, so now we're talking holder to verifier. Well, we can wait, but eventually we're going to get to that. So, but let's, if you think that we can leave it for now, that this is the only data that goes to the holder are these three things, four things, I mean. Okay, so the holder is going to have, yeah, the sign credential, the element, the witness and the accumulator. Okay, correct. Yep. All right, so issuer has now decided, I'm going to revoke a credential. What does it share? What does it send to the revocation manager? Besides the authorization that, you know, it's allowed to do this, just single element or elements, let's say it's revoking like 10,000 at the time, just says remove all these. And the revocation manager will obviously check, are you authorized? Okay, you are. And then I'll return to you the new accumulator value. Okay. Okay, so now the holder wants to create a presentation. So the holder's been, yeah, holder's got it. Yeah. So the holder doesn't have to do anything just yet. So the verifier is basically going to say, I need to know that your credential is fresh enough, right? Ah, okay. So he might look wherever the issuer has published the values of the accumulator. Maybe it's only the latest, maybe he has every version for the last 30 days, you know, depending on whatever your risk tolerance is, right? Yeah. For how fresh you want these. Yeah. So yeah, then the verifier is going to go, okay, I've got like, maybe I'm going to grab the most recent five or maybe just the recent one, because I know the issuer only updates once every 24 hours and that's good enough for me. So he just grabs wherever that is and the public verifying key and says, I need you to prove that you're not revoked as of this accumulator value. That's part of the presentation request, right? Yeah. And sends that to the holder. Obviously there's- That's what I was missing, got it. So the verifier can basically pick how fresh they want it to be, right? Yeah. It could be as of a week ago, 24 hours ago, seven minutes ago, whatever, you know, it just depends on how often the issuer, you know, wants to make changes. So, okay. Now that the holder has what accumulator version, the verifier wants him to prove against. Yeah. He looks at and goes, is it the same version for which I have one? If it is great, I don't have to do anything. I can just generate a proof, which only needs my witness and my element and obviously my verifiable credential. It was the only three things he needs. And then he can generate the NRP and send and present. If it is not the latest version or he doesn't have one for that version, then the holder needs to contact either the issuer or somehow the data has to get to the revocation manager. However that needs to happen. Yeah. Now, could he have the verifier do it? Yes, we could. Yeah. Could we have the issuer do it? Yes, we could. Or maybe just go directly to the revocation manager. This part is completely up to you, whichever is easiest. But what the holder is going to do is he's going to call the Alasor Update Protocol. It says, I need a new witness. Here was the old accumulator value that I have. Or no, he doesn't even need that. He just says, I need to update to the latest version. So he basically says, I need to go to this version, whatever that version is. Maybe it's not the latest, maybe it's two of them ago, but he says, I need to get my witness to that one. Sends what? What do they send? Ah, so this is the part. So if they want to maintain privacy so that no one knows who is updating, then they will just do a Shamir secret sharing split of their element. Yeah. And send enough of those pieces to the revocation manager. The revocation manager goes, okay, these obviously came from someone who had one, but I can't tell what they are. That's part of the protocol. Yeah, yeah. And I will then, for each share that I receive, I will perform an operation and send it back. So in the distributed network, let's just say for simplicity, the holder is talking directly to the revocation manager. And the revocation manager maybe has five nodes where the key is split among them. The holder can do whatever they want. They can split into as many pieces as they want. Yeah. And send, they have to send at least a threshold of those to the revocation manager. Now, here's the cool part. This can be as creative as you want. So let's say there's five nodes from the revocation manager. And me as a holder, I'm going to say I'm going to split my element into 10 of 20. And I'm going to send four shares to this party, three to this one, five to this one, two to this one. Well, it doesn't matter where they send it. The revocation manager doesn't know if it's the same person or a different person or even for the same element under the hood. So anyway, once enough of those who've been processed, they're just immediately sent back. The revocation, those five nodes, don't even have to talk to each other to do this update. They just go, okay, I'll process your share or shares with my piece of the secret key, send you back a value. And then once the holder has enough returned responses from the revocation manager, he applies some simple math arithmetic with his witness and now he has brought current to that. So now he can prove against that accumulator value. Yeah. Notice the witness never leaves the holder. Yeah. And two, let's say someone was sniffing and watching all of this, then let's just say they just listened and got all the responses back from the revocation manager. Yeah. It doesn't matter because the information they get back since they've never had a valid witness at all, it does nothing for them. Yeah. Yeah. So from that side of things, it's secure. So even if you have a passive adversary that's snooping and watching updates, as long as he never gets the witness value itself, which you'll notice never leaves the holder, he can't do anything with the data that comes back. It's just useless. Okay. So let's go to the other scenario where, so otherwise the holder sends a witness they have. No, they never send their witness anywhere. Okay. So how else other than splitting it, can they get? No, they don't split the witness, they split the element. No, I know that. Is there any other way to get an update? Well, the other way you could get an update is if you wanted to do the deltas changes between the cumulative accumulator. You could do it that way, but it involves a lot more risk because if there's enough elements published, like let's say you put it, you have a million elements in there and you get enough deltas that are published, then an attacker could extract the private key. Hold on, hold on. So there's not a way that the holder, I thought there was a way that the holder could send their witness and the accumulator associated with that witness and get an update. You never send the witness anywhere. He could send just his element and the accumulator and say, give me a witness for this and give it up to date, but then he's also leaking who he is. Yeah, you can still do that. Yeah, you can still do that. That's still possible. If he doesn't care, if we don't care about anonymity, he just says, here's my element, here's the accumulator value it was for. Well, he doesn't even have to do that. He can just say, give me the latest, give me a latest witness for this element and then it'll come back and he'll get the witness directly as if it was done during issuance. So it's pretty much the same thing if you don't want to do the distributed update and hide who's updating. And in that sense, it's just a call home from the holder to the issuer or revocation merger. I mean, both are essentially a call home, but one reveals who it is, the other one doesn't. So a way to do it this way via the verifier is even if you have a single revocation manager, I could send a split element. Is the, with Shamir's secret is every time you split the element getting the same result or can you do it that you get a different one every time? Well, no, yeah, when you split it, it's randomized so you get different ones every time. Every time you split it, you get randomized ones. Okay, so the way to do this would be even with a single verification manager, even if you did it with a single revocation manager, if you set them five shares, they wouldn't be able to tell who you were. Nope, they don't know which element it's for. They don't know which accumulator, well, they have to know which accumulator it's for, but otherwise that's all they would know is I got some random data. I'm supposed to process to update it for this accumulator. Okay, obviously you should do some authorization checks, of course, but even if it was a malicious attacker that somehow got knowledge of the element, as long as he doesn't have the witness, his result will not mean anything. Yeah, yeah, so regardless of whether you actually, whether you have multiple revocation managers, because you can send the shares to a single, multiple shares to a single revocation manager, they just do four calculations or whatever and send you back four results and you're good. Yep, yeah, so if you had four of seven, right? Yeah, send four, you could send five and say I'm just gonna ignore the first two as a distraction and then get the rest, you know. And just to be clear that every time you split your element with using a Shamir secret algorithm, you're gonna get a different set of values. That's correct. Okay, so even if you are using a single service for doing this, they're still not gonna be able to get a correlatable identifier. That's right. Okay, okay, that's cool. Okay, that's the magic that I was missing in doing this. Okay, so hold or to verify there's an NRP and a NRP and that is generated using the elements and witness. And then the verifier and the revocation manager, the verifier has already retrieved the accumulator. And then it's possible that the verifier could also send the accumulator along. Sure. Well, he's gonna have to have knowledge of it either way. Cause right now you did it this way, which is, okay, here's the accumulator, but it could be done the other way where the verifier just confirms that there is an accumulator with the value given by the holder. Yeah, you could do that too. Yeah. Yeah, like the holder might say, here's the version I know of. Is that fresh enough for you? And the verifier, depending on the risk tolerance will say yes or no. Yeah, yeah. All right, that was awesome. We're just about out of time, but that was hugely helpful for me. Hopefully it was interesting to others and a value, but that explains the Allisaur revocation scheme, which is pretty important in what we're doing. Pretty important element of it, if you will, since we're over using the word element. If you want to, I hate saying member, so we can come up with other names for that. No, that's fine, that's fine. That works. I now totally get the data flow on how it can be done and the importance of Shemir's secret. Cause one of the things that I've been thinking about is, wow, it's really hard to organize a bunch of revocation managers that don't know about each other, but it's the use of Shemir's secret is to enable, even if you're sending it to a single party to split the element so that the element is never known, and that's the crucial part. That's the non-linkability, unlinkability. Yeah, that's the unlinkability when they call home. Yeah, yeah. So even if they call home, it's unlinkable. That's awesome. Yep, unlinkability and call home, unlinkability during presentation. So there's no way to link them, at least through revocation mechanisms. Now, one other thing to mention to folks, one of the concerns here is if you do call home with it, the holder's doing it. One of the things we've talked about, and it came out about sort of accidentally, but is a completely valid thing, which is the holder could send to the verifier, here's my split of my element, go get the witness for me. Again, the verifier can't correlate the element. The revocation manager can't correlate the element, and the call home, the revocation manager, doesn't know which holder is involved. It just knows the verifier is doing a presentation request. So it learns when a presentation request is done by a verifier, but that's about it. And it only knows the verifier by the IP address. So even that's of potentially marginal value. So again, super interesting way of doing it without any sort of call home. Yeah, I mean, essentially the revocation manager doesn't know who's calling him. He just knows end update is being requested, that's it. Yeah. It doesn't matter if it's through the verifier, the issuer, the holder, could be anyone. Heck, you could have a detour network to it. It doesn't matter. Yeah, yeah. Excellent. All right, folks. That's all we've got for today. That was really good. Appreciate your time, and we'll talk to you again soon. Thanks, everybody.