 So today, we'll talk about Irma's Edimix core. So Edimix is a set of cryptographic protocols. And the Irma is an implementation of Edimix, of our Edimix, I should say. And today, we'll explain to you how Edimix works, what its goals are, and how it achieves those goals. In particular, we'll focus on the selective and unlinkable attribute disclosure. So who are we to talk about that? Well, this is Maya Reisner. She's a software developer at SIDN. And I am Seed Syringers. I am the architect of Irma also at SIDN. And together, we work on Irma. Yeah, so Irma is now developed at SIDN. Previously, it was developed at the Privacy by Design Foundation. But since the beginning of the previous year, the development moved over to SIDN. So we do hope you'll have some familiarity with Irma itself. Perhaps you've already seen it. And some familiarity with basic cryptography would also help. But we'll see how we'll guide you through everything. All right. So Irma is an implementation of a self-suffering identity system, right? So in a self-suffering identity system such as Irma, in the center, there is the user. This is not visible, right? The pointer. Sort of. OK, right. So in the center of things, there is the user, right? And the user wants to authenticate herself as some verifier. Perhaps it's a web shop. But it could be a physical as well like here. It could be basically anything. So the user wants to authenticate herself at the verifier. Perhaps to convince the verifier that she has a diploma of sorts. It could be anything. So there is the user. There's the verifier. And then on the other hand, there is the issuer. An issuer can be basically an antitrusted institute such as a local government who knows my name and age and my social security number. Or it could be a university, say, that knows that I obtained a diploma at some sort. And then they are trusted issuers because they are generally trusted by other parties within society. And what we want a system like this to do is that an issuer, it issues to you a credential, so a piece of data that you then have in your app that you control. So you store it in your app, in your Irma app. And then at some later stage, you can disclose that you can use that credential to authenticate yourself towards such a verifier, probably a web shop or something, as I said. And within that verification transaction, the issuer is not explicitly involved. So it gives you the credential. But after that, its role is done, so to say. So you use that credential towards the verifier. And since there is a trust relationship between the verifier and the issuer, the verifier is going to trust the Dutch government to say truthful things about me or you. It works. So then the verifier decides you're authenticated and the thing can go ahead. So there's the holder in the middle and there's the disclosure part. There's also issuance. But in this talk, we're mainly going to focus on the verification part, because it's the most important part of idemics and Irma. And it's also the most interesting part. OK. So let's see a little how, just to get a feeling of things, let's first see in this introduction how authentication might work offline, in the more traditional sense. So here is a sort of representation of a diploma that I obtained back in 2016 at the University of Groningen. And for now, this represents an actual paper diploma. I have it at home. It's a huge thing. And it has this red signature stamp on it that's supposed to signify its authenticity. And suppose now that I would want to use this diploma to apply for a job someplace. Perhaps it's a job that requires that I have a PhD. So this use case, by the way, we will use in various formats and ways throughout the talk. So we'll see this coming back as we go along through the talk. So OK, if I have such a diploma, I guess the easiest thing that I could do would be I can just take it with me when I apply for that job. And I show it to my prospective employer and then he is convinced that I have a PhD and it's fine. So that works. We can go slightly further. We can do more things, such a paper diploma that might be cool. What we could do is we could make a paper copy of it, just using a copy machine, the old fashioned things, and then scratch out some of these things. Because perhaps for the job that I applied to, it's not particularly important what my exact name is. It's just important that I have a PhD. So using a paper copy of an actual diploma allows you to do what we call selective disclosure of the attributes on your diploma. So the bold stuff here, here as it is, and here we call attributes, basic small pieces of data about yourself. So on your copy, you can scratch some of them out. And then the one that I show it to knows just the important parts for the particular thing I want to do. So that's a cool feature to have in our credentials system. So I guess it works, but it also doesn't really, because if I make a paper copy of my own diploma and I scratch out some fields and I would give that to you as my prospective employer, then you have that copy and then you could use it to try to convince others that you, in fact, have a PhD. So we have a problem of replay attacks here. So we don't want that in our system. So that's an issue we'll have to try and solve. So we have a feature now that we want and a problem that we want, and there is an additional feature that's kind of cool in this offline setting. There is sort of unlinkability. That means if I, in this case, if I make a second copy of, I make a second paper copy of my diploma, and then again, I scratch out some of those fields, but just in a different way, with different scratches and a different pen or whatever. So the new copy doesn't look anymore like the old copy. It looks different because I scratched it differently. So that means it's no longer visible, that it's a copy of the same underlying actual diploma or credential. So the ones that I give these copies to, they cannot, in fact, see that those two copies both belonged to me. So this is a feature that we call unlinkability, and this too would be a very nice feature to have. Right? So these are some features that we might want to have in our credential scheme. OK. So now we want to do all of this, in a digital domain. It's easy. Right. So the goal of this talk is basically to be able to understand this piece of code. This code comes from a software repository called Gaby, which you can find on GitHub. And Gaby is our actual itemics implementation. This particular piece of code verifies a signature on an Irma credential. So actually, what it verifies is that this particular equation holds. This is the verification equation of an Irma or itemics credential. So that means that we're going to explain all of the different ingredients of this formula later on. We'll see this formula throughout the talk. But what it means is that if your credential and its signature on it satisfy that formula, then it is valid. That is what this piece of code establishes, checks. So a small table of contents for the remainder of this talk. First, we'll talk about selective disclosure that I mentioned just now. And to see how you can achieve that, we'll first look at how you can distinguish the various attributes within that formula and within the code from each other. Then we'll show you, once you have done that, how you can hide the attributes that are not relevant to a particular transaction to actually achieve the selective disclosure. Next, we'll talk about ownership of the credential, so how you can really bind it to the person about which it states things. Then we will talk about unlinkability, so how we can transfer that property that we saw earlier in the paper case to our digital setting. And finally, we'll talk about how we can combine all of that to achieve disclosure of multiple credentials out of your Irma wallet. And with that, I give the word to Maya. Please do. Can you hear me now? Nice. Thank you. I'm very happy that you're here, because this is so much nice stuff, and I'm just also amazed that so many people want to know how it works. You have a little handout. It is meant to help you eventually. Don't worry about it yet. If you don't understand it yet, that's why we have the session. So we will start very basic. We will start with just digital signatures and have a look at how they work. On the right-hand side, you will see our example that we will talk about all of the time. It's the diploma again with a little bit less information than we saw before. It's the names, it's the ringers, and a bit of a text, and a PhD with a stamp. So how would this digitally look like? Well, the complete data of the diploma would be represented by just the number M in this case. And if the designers at the university who will issue this diploma can then take this number M to the power of a secret value D, a modulus N, and it will result in the signature A. This is textbook RSA, and I will not cover this any further. You can just look it up. If you don't know it in details, it's OK. You should still be able to follow the talk to some degree. The verifier, then, later on, can take the signature, take it to the power of the public value E, and it should result, again, in this signature number M, modulus M. So Sitzel already talked about selective disclosure, and if we want to get there, we want to hide data. This is currently not possible with this system, because if we change anything in the diploma data, we will change the number M, and the signature will not hold any more the equation. So we need to find a means to differentiate first between the different things that we may or may not want to show. And we can do this as follows. Please focus on the right-hand side first. We can first split the diploma into different attributes. So it's not a blob of text anymore, but it's different attributes with attributes types, in this case, name and title, and the values, Sitzel ringers, and a PhD. Please don't panic about the formula. We will go into detail with all of the stuff here. Please now focus only on the little a's. The values on the right-hand side, Sitzel ringers and the PhD, are represented as two numbers, A1, which is Sitzel ringers, and A2, which is the PhD. The attribute types, that is the name and the title, will be represented in this equation by R1 and R2. Z will be used for forgibility reasons. S will be used by the power of this V later on for unlinkability. But don't worry about it yet. Just see that we now have a formula where we can differentiate between these values. All the capital letters are constants and public values, and now we just accept that it's there. Don't worry about it yet. And replace our M in the formula above. This will look like as follows. We get A to the power of E. This will stay the same. We replace M and we have an equation. This equation is part of the so-called Kamenys-Lizianskaya signature scheme. And this signature scheme is used in Iremix and also in EMA. So we will focus on this for almost a whole talk. We will only do the verification. And the verification is this equation. I told you already that those capital letters are constants. There's an E and a V that actually become part of the signature. You can already see that on the right-hand side here. And we will go into details. Actually, now we will now have a little detour to our diploma example. And I'll just say a couple more words on the signature scheme so you have a bit more context on it. The Kamenys-Lizianskaya signature scheme is quite a mouthful. That's why most people just abbreviate it with CL signature scheme. So you may have heard that before. If we now just have a bit of a look at issuance setup and issuance, then we have a bit more context. And we will see that it's somewhat RSA-like. Similar to RSA, we will begin by choosing the private key with two prime numbers P and Q, which, if you multiply them with each other, will result in N, a public value. Then you will also choose a couple of constants that the issuer just used at setup. So the university does this once. And they will all become part of the public key. For each attribute type, you will choose a different constant R. So it's R1, 2, 3, 4, as many attribute types as you have. Then later on, when you actually issued a diploma, so it's really each time a credential is issued, the two numbers E and V are chosen. And then the issuer calculates the number A by actually doing the same as he would do with RSA, but then replace the M again. It will result in a signature that is a triple, because each time the credential is issued, a different E and V are chosen. So that's different from RSA 2. For this whole signature scheme, the strong RSA assumption holds. OK, but we want to focus on that. We will focus on the right-hand side, just on the verification equation. And what were we doing so far? We had a look at the diploma. We want to hide data. We can't hide data yet. We only can differentiate between data in the diploma. And we will now have a look at the hiding part. Going back to our example, we now want to hide the name. If we have a look at this formula, because of the discrete logarithm problem, which states that the exponent is infeasible to find if you only know the result and the basis of an exponentiation, we can actually hide already this attribute value, A1, just by not sharing A1 with the verifier but the result of the calculation, so just sharing H. All other things will stay the same. So hiding itself is quite easy, but we're not there yet. The signature scheme does more than that. If this would be the only thing, we would actually be vulnerable to forgibility attacks. And we will have now an example first to see how this would look like. Again, lots of changes. We will focus on the left-hand side first. And the example of the diploma changed because I think it's easier to follow the example having a number and not a string in mind. So in my new example, I still have a name that I will hide, but the second attribute will be age 17. And in my forgery example, I could forge my age to 18 as follows. I could just claim that my age is 18. And then I would not share my name, but I would share a number again because I am hiding my name in a number. If I would now not calculate this number, as shown above, but just accept that I would calculate it by taking this number times R2 to the power of minus one, we would still, the claim would hold in the equation of verification that my age is 18, although the issue never issued it. So the verifier would then check if the equation holds using the wrong number, but you can't differentiate it from a usual age, which makes the equation still hold because age prime is the same age, age time R2 to the power of minus one. And if you rewrite it, you get eventually R2 to the power of A2 minus one. And our A2 was chosen as 18, minus one is 17, which holds in the equation because this was actually issued. This is not what happens because the signature scheme takes care of that. How do we do that? We actually have to prove that we know the number eight, that we know this attribute value without disclosing it. And there's now some real crew math coming where I really can't imagine how people think of that, but it works and it's beautiful. The Comedian Schlesinger Signature Scheme uses a Schnoer-Zero-Knowledge protocol. It's a protocol from the 90s and it's a three-staff protocol that we will now have a look at. For simplicity, I removed all the indices. The indices are used for indicating which attribute we're talking about, but it becomes a mess here, so I skipped them. We start by the given thing that we have, this age which we publicly can share because it doesn't say anything about the value of A already and it's defined by R to the power of A. Now, on the left-hand side, we have we, the prover, and on the right-hand side, we have the verifier. It starts by choosing a random value, T, which is really big. Then we calculate U as R to the power of T, modulus N, and send U just over to the verifier. This is called the commitment phase. Then in the next phase, the challenge phase, the verifier chooses a random value L, see, the challenge, and sends it over to us again. Now we calculate the response, which is this huge value, T, plus the challenge times the attribute value, T thereby masks the attribute value because it's so big you can't really see A anymore and sends across R. This is the response phase and eventually the verifier just checks if this equation holds and if this equation holds, it's actually a prove that we know the number without having shared the number. So this is a bit of magic, but it's actually a prove it's not that difficult. Once you see it, it's difficult just to make it up, but I didn't, so that's fine. I will go through this very quickly. It's just meant to show you that you can understand this and you can look it up and it's not rocket science. So here on the left hand side, we start just what we have on the left hand side and we want to end up on U on the right hand side. First, we can write this small letter R as what it is, T plus C A, then we can split those because it's a product of both. It's really just school math. On the right hand side, we can replace our H with R to the power of A because we defined that earlier. Exponentization by exponentiation is the same as multiplying the exponents. Then we can see that they actually cancel out to the power of C A and to the power of minus C A. They just cancel each other out, which leaves us with R to the power of T, which is by definition here above the same as U. Again, this was a bit of a side thing in your mind, but what we now have is actually that we have our diploma where we have different attributes and we can hide an attribute by using this age discrete logarithm thing plus we prove that we know the value. There's actually a second feature that is interesting in the Schnorr protocol and we'll have a look at that now. You may have already noticed that there's a challenge and a response in there, in the name, and Sita already mentioned earlier with the paper diploma that, well, we may have replay attacks. Challenge response mechanisms are used to prevent replay attacks, so let's have a look at if this already works. Again, back to the example, Sita would now share his data with me. He would do the challenge response with me. I would not see the name, but he would just prove knowledge of it and I would have the diploma. So I have all the data. Now, can I do a replay attack? Well, actually, yes I can, because if I now prove to anyone of you that I have this diploma without the name in it, I could, well, do a commitment. You sent me a challenge. He didn't send it to me, but I know Sita's name. So at that moment, I can still calculate R, the freshness proof is still valid, and I could send the response. So in order to prevent that, we cannot use any attribute type that you will ever share. It must be a secret one. So we can now add an extra attribute, which we give the index zero, and this is a secret value that Sita will never share so I can never do a replay on that. Okay, did I miss something? Oh, yeah, little remark. It's a signature scheme, and by using this secret value, we can actually use it as a credential scheme, and that's what we're doing. Okay, let's go on. We now know how high data, we know ownership of a credential, do we have unlinkability yet? Well, if we look at the right hand side, it seems so, because, well, we have hidden data, which just looks different every time, and we have this PhD, which is not really relatable to the person. However, there's still a signature. The signature consists of those three numbers, and as we see them here, they're currently still the same. This is not what happens in the signature scheme. Let's have a look how we can hide this data. Well, for E and V, it's actually not that difficult to hide the data because they're also used in the exponents in the equation. So we can use the same mechanism as we already used for hiding under data in our diploma. We can just use that for E and V too, and that would be fine. However, however, there is still A left. We can't just hide A with this discrete logarithm because it's not in the exponent, and, well, if we now want to change that, we must change something on the left hand side and on the right hand side of the verification equation, otherwise it won't verify anymore. And this is possible, and it's possible as follows. We're making A unlinkable by choosing a random number, R, and then we define something with what we will replace A. We will replace A by A tilde, which we define as A times S to the power of R, modulus N, and on the right hand side, we replace V with V tilde, which is defined as V minus ER. So why does this work? Well, that's why. If we now replace it, A tilde is the same as what we just defined it as, then we have it to the power of E, so we can put that E into both of the bases. We can replace the complete A to the power of E with the right hand side of the equation. Then we have twice this number S to the power of something, which we can put together, so we get S to the power of V minus ER in here, and V minus ER is our definition of V tilde. Again, don't worry if you don't really follow this now, because you can look it up, but it's correct. It works, it's mathematically, it works. What does this mean? Well, this actually is, it means it technically works, and just when you imagine how this really works in practice, it would be as if you had this paper diploma, you have a signature, you hide lots of data, you hide even parts of the signature, and then before showing it, each time before showing it, you just change it a bit, and then you show it, and it's still valid. So I think this is a really awesome mechanism, and it's really fun to work with it. We now have actually all those single features that we wanted to have, and Seats will now continue in putting this to a complete picture, so more math. Go ahead. Thank you. All right, so let's first have a little short summary of what we've seen so far, because it was a lot, right? So we started with just RSA, where the letter M there contains the entire diploma, just as a big blob. Then into M, we distinguished each of the attributes, resulting in the formula there at the bottom, right? Next, we obtained a way to hide irrelevant attributes using zero knowledge proofs, where we prove that we know the attributes without actually showing them. We bonded it through the user, using the secret over there, which is a zero in the formula here. And finally, we even gained unlinkability by either hiding all of the exponents in the zero knowledge proof, or modifying the big letter A each time before you use it. Right, so having seen all that, let's now look at how all of that works together in an actual disclosure in this following slide. So this slide shows you the disclosure protocol of idemics for a single credential, right? So let's suppose that we want to disclose the attribute number two, the PhD attribute, the one on the bottom there, right? So that one we want to show, and then the other ones we will hide. Okay, so the first thing we do is what Maya just explained. We modify our A into a tilde using the random number R. And similarly, we randomize our V into a V tilde using, again, the value R. And then for these ingredients, the verification equation that we've seen so far, it still holds, as Maya just convinced you. So for our A tilde and V tilde and all of the other ingredients, this holds. And next, let me take the same equation, but slightly rearranged. So it looks a bit different, but it's actually the same statement. What I'm going to do is I'm going to modify it into this. So now we have all of the exponents that we want to hide using the zero knowledge proof. We have that on the right-hand side. And all of the known stuff, that's on the left-hand side. So you can get from the upper equation to the bottom equation by multiplying both sides by SV tilde and these parts. And then you get exactly this. So it's the same statement. It just looks a little different. And now let's call this thing H again, just to have a name to refer to in what follows. Okay, so for this thing, in particular for the exponents on the right-hand side, we now want to prove knowledge, right? So what we're going to do now is we are going to execute a single proof of knowledge protocol that simultaneously proves knowledge of all four of those exponents. So what does that look like? It looks basically the same as Maya showed you earlier, just some of the steps times four. So the first thing we do is we choose four random numbers, for each of the numbers that we want to hide. So there's a TE, a TV tilde, a T0, and a T1, big random numbers. And then we perform the following protocol with the verifier, this protocol here. So just as before, we first compute our commitment, the U, which is this expression, basically the same equation as this, but with the random numbers in it. And then we send our A tilde and U over to the verifier. The verifier then responds with a random number C called the challenge, it sends it back to us. And then using that challenge, we compute our responses, the letters R, which are always of the form, the big random number, plus the challenge times the secret that we want to hide. So it's that for each of the numbers that we want to hide, and it looks like this. So these four responses, we send over to the verifier. The verifier plugs them into that verification equation that we also seen earlier, it's now just slightly bigger. And if that holds, then the verifier is convinced that we know the attributes and that all of the attributes are validly signed by the issuer. So this is an Erma or itemics disclosure in a single slide out of a single credential. This is what happens when you disclose an attribute out of Erma under the water. But we don't want just one credential, we want to have a wallet of credentials, right? Because you can have lots of different credentials containing lots of different attributes from distinct issuers, and you want to have all of them within your one wallet, and then you want the ability to combine attributes out of all of your credentials as suits the purpose. So we're going to have to do one final step to go from the right-hand side to the left-hand side here. So this is a screenshot of the Erma app showing a number of credentials. And I might want to add, by the way, this particular look is subject to change, but you'll see that in the coming time. Right, so we have to do one final step to get to where we are. Okay, so, because there is a thing that we have to solve still. If we just naively combine the multiple credentials on top of each other using the disclosure protocol that I showed you earlier, we introduce a problem that we have to solve. Because the issue is, suppose, okay, fine, suppose I have my Erma app, and it contains a credential that states that I have a PhD, right? But suppose I'm careless, and I leave my phone just lying over there, and my app picks it up, you know? If she has then control over her wallet as well as mine, so she has control over my credentials as well as hers, can she then combine the two, for example, to prove, to simultaneously disclose her own email address and my PhD attribute, right? So that would sort of imply that if she would be able to disclose those two attributes simultaneously, that would imply that she would have the PhD, well, in fact, she does not, as far as I know anyway. So we don't want our system to allow you to prove statements that are not factually true. So we'll have to solve this issue. And the way we do that is as follows. We've already seen the secret attributes that each credential has. And the thing that we do is we make the issuance protocol of these credentials such that if I get issued a new credential to my wallet, then the issuance protocol ensures that the secret of the new protocol gets the same value as the secret of my other credentials. So the issuance protocol is such that all of the credentials in my wallet, they share the same secret value. So there's one secret which is in all of my credentials. That means that Maya's wallet, which also contains credentials, which also contains secrets, that secret will have a different value. So my secret may be one, two, three, and then her secret is going to be four, five, six. Actually, it's a lot bigger, but you get the idea. Okay, and then once we have that, we modify the disclosure protocol that we've seen earlier in such a way that not only do I, when I disclose my attributes coming out of multiple credentials, not only do I prove that I know the attributes that I don't disclose, and all of the attributes are validly signed, but I also prove that the secret out of which all of those attributes are coming, that that secret has the same value across all of the credentials out of which I disclose attributes. So I can do that because all of the credentials of my wallet actually do have the same secret, and that will prevent the attack that I just mentioned because the credentials in Maya's wallet will not have the same secret value as those from my credentials, so she cannot prove that that is so because it's not. That's the idea, so the final step is to go into a little more detail about how we actually do that. So here again is the proof of knowledge protocol that we've seen earlier for a single credential, right? So let's simplify that a bit to show just the details that matter to us right now. So we first compute some U, and then we send over A till the end U, next we get a challenge, and then we compute a bunch of responses of this form, right? And then we send that back over. So that's what that looks like for a single credential. So the naive combination to expand that to multiple credentials will be basically just like this. We do the same thing, but for more credentials. Where now I use red and blue to distinguish the ingredients of the different credentials, right? So suppose in this particular example that I want to disclose my own PhD title and actually my own email address, right? It's my email address, so I should be able to do that. So how do we do it? In particular, these responses here are what we're going to use, and for the secret that we've already seen, which was labeled by zero, that's this, right? So these would be the responses for the two secrets of the credentials out of which I disclose attributes. Well, what we do is actually simple. We ensure during the issuance protocol that the two A zeros, that they have the same value, right? I just called it one to three, for example. So there's just one A zero. So let's make it black again, because there's just one. So there's one A zero for both of my credentials. There is one challenge, because there is just one within the protocol that we've shown you. And the final step that we need is that during the disclosure protocol, the holder, the prover, or the user, it uses the say one T zero, one random value for all of these secrets. So it just chooses the one secret and then the one random value is a T zero and then it uses that one T zero for all of the credentials, for all of the secrets. So that means that since all of the ingredients in this particular formula are now the same for all of my credentials, this response too is going to have the same value for every single credential out of which I disclose my attributes. So there may be more multiple credentials, but the R zero, the response for each of the secrets is going to have the same value for all of those credentials. And once we have that, we can just make the verifier enforce that this value R zero always has that one value. So the verifier henceforth, this allows the user to send distinct values of R zero. It enforces that the user always has one R zero for all of his credentials. And if the user does not, then the disclosure is rejected as invalid. Well, that solves the issue because as I explained to you, my secrets is going to have the same value for all of my credentials, but my as will not. That means that this R, if she were to combine it to try the attack that we just mentioned, combining multiple credentials out of multiple wallets, then those are zero values in her case are going to differ because the A zero values do, then the verifier will notice and abort. So in fact, this secret A zero by enforcing it to have the same value across all of my credentials, it sort of acts as a key ring that really binds all of my credentials together in one big key ring or wallet. So that is our story. That is what the disclosure protocol of itemics looks like. This is what happens when you do an Irma disclosure. So going back to our initial picture, we have now seen how the verification part of this diagram works, right? And by using all of this mechanism, itemics allows you to have a wallet containing lots of credentials which contain lots of attributes that you can disclose. And you can even do so selectively and unlinkably, which is really awesome, I think. There's lots of more stuff going on here because as I said, we've just discussed that verification arrow over here. We have not discussed Irma schemes which facilitates the upper arrow, the trust relationship. We have not discussed the issuance part, and there are still more. We have not discussed the Irma key share server or the verification of attributes once their value ceases to be true. All of that Irma implements as well. We can fit everything into a single talk. So if you want to know details about that, come look us up this evening or in the coming days. And with that, I think there's still a little more time for questions. Thank you very much. Thank you. Thank you very much. Sitze and Maya, we still have five minutes for questions. I see a lineup already. Otherwise you could have explained the rest also, but we have first question over there. Yeah. Yeah, but okay. It works. So there's a general, so is there any thought in the system given to how to prevent attributes being sort of misused? So for example, okay, going to, I'm actually getting a job, it's not much, it's not too different. It's kind of annoying that I have emailed my PhD to lots of people, but you know, everybody's done this. But so, okay, it would be kind of cool to be able to send something, you know, it was somewhat more redacted or whatever. But anyway, is there any thought to like, so one of the things that's in the old verifiable claims use cases document from the W3C is they wanted that it to be used for, like to prove you had a job to a bank. But of course, you don't open a bank account every day. It wouldn't be that much trouble to get a new letter from your thing. But what happens if, if I just have this wallet, what happens if now some other parties start asking for this prove you have a job? So for example, if HR departments want to me to prove that I have a job when I apply for a job and then they can start bending resumes. And for most of the verifiable claims use cases, there's actually this malicious use, it's very easy to find these malicious uses. Yeah, that's a very good question. Thank you. Well, the first answer I think is that if you're asked to disclose some attributes to whoever is asking for them, the Airma app also always gives you the ability to just refuse. There's a big no button, right? So there is that, but I don't think that answers your question, not entirely. I think there is definitely a risk that a system like this makes it much too easy for potential verifiers to enforce that you authenticate with them, right? Using perhaps too much attributes. So that's something that we'll have to be very careful about and we're aware of it. We have a couple of ideas that might help there. For example, I think that we might still do is implement a button in the Airma app that when it's asking you some attributes and you think that it's too much attributes or not appropriate to the situation or that you can then report it to the Dutch Autoriteit Persoonsegevens, the Authority Personal Data, or to the police, I don't know, or to us. So that then something might be done about it. Yeah, so there's not, I mean, why involve the user at all? I would like to add something first here. Very shortly, we were now only talking about the technical stuff. So it was really just why it works. So you get some insights, why we claim it is, how it is, so you can see that. There are lots of advantages and lots of disadvantages for the complete system to use. This was not what we were talking about, but it might be a nice future talk. Yeah, my main question, the implication of my question was why involve the user at all? Why not just have this certificate for the person they're identifying it for? Say what they're allowed to ask. Can we take this question offline, discuss it later with them, give the other people a different question? Thank you. Okay, cool talk. How, or do you provide your secret key to the issuer and do you have different secrets for different issuers? Otherwise, can you combine your attributes if they're from different issuers? No, there's one secret, which is we use across all of your credentials even if they are from different issuers. And that means that you do have the ability to combine different attributes from different issuers, but that's a feature. So then the issuer knows your secret? No, no, the issuer does not get to the issuance, that's a good question. The issuance protocol, which we have not discussed is such that the issuer, it does ensure that you get the same secret as your earlier credentials. There too, you have to prove knowledge of it, but it does not get to see the actual value of that secret. And that too is achieved by zero knowledge proofs. Okay, awesome. So it's actually a double blind signature scheme and we just really did not talk about this at all. The issuer themselves, they have private keys that they do not share. They only share the public keys and the secret value from the app user will never be shared anywhere, just proven that you know it. I was just wondering how the attribute values are encoded because I can imagine it results in a bunch of large numbers that you have to do maths with. So, sorry. I didn't get that. Can you repeat the question a little louder? There's no more. Oh, sorry. I was just wondering how the attribute values are encoded because I can imagine it results in a bunch of big numbers that you have to do a lot of maths with. So, is the size limited or is it arbitrary and are there any performance issues? It's basically arbitrary. Currently, you just use string encoding. So an attribute is some string, and you just take the UTF-8 encoding of that, and then you interpret that as a big number, and that's it. And there is a boundary. Attributes are by itemics. They are not allowed to exceed 256 bits. But that we solve by just hashing it using SHA-256 if it does, and then you're below it again. So that means that attributes can have basically any size or content. It's not necessarily practical if you have this giant protocol of attributes, because it would look weird in your app, right? But that's another issue. OK, we have time for one small question. Can you keep it small, or is it going to be a big question? I'll try. OK, OK. So how are key revocations handled? Can you get a bit closer? How are the revocations of the keys of the issues handled? Revocation. Actually, there are two papers on that. And you can all read it on a documentation on irma.app slash docs. Sitser wrote it down in great detail, so I could understand it. So you will understand. But there are two papers published also by Kamanish, I guess. And we have an implementation of that. I will not go into detail. Sorry. Thanks. Thank you very much. I see the same. Can you get it offline? Thank you very much. On the sides, our QR code is to the GitHub repository of Irma. I would like to. Actually, the slides. So if you want the slides. The slides. It's a GitHub repository filled with slides. No code, because it's open source. There's also code. OK, thank you very much. OK, thank you very much. Thank you very much for your enlightenment this evening, Sitser and Maya. One final big round of applause. Thank you.