Welcome, first of all, and thanks for joining us exactly round about lunchtime. We hope we can make this an edutaining session for you.
Actually, I'm Jörg from Namirial from Germany, and from our headquarters area from Italy is Luigi Castaldo. Luigi is actually with the technical background and also our Mr.
Wallet, as we may say, because someone really needs to dive deep into this. I am more from the marketing, from the business side. You may know me as some of the observer of anything that goes on around European digital identity, about trust services, etc. I do have a certain reputation, and Luigi as well, for crammed and fully packed slides, because we typically are doing this like a workshop. You do not need to wait until the slides become available.
If you just use the QR code that is over here, because what we've done is we've packed a lot of links into it, into most recent publications, even stuff that has been published just last week. You can find the QR code also at the end of the session. Now we just dive into it without a little bit of further ado. The background on our side. We are actually working as two out of thousand for a qualified trust service provider. This is not just one. We are working within a group that also runs qualified trust services, for example, in Spain, not just only in our mother country in Italy.
When you look into the background of customer requirements that we're getting, who's actually paying our wages? It's, for example, banks, it's insurance companies, it's to some extent also the public administration in a few of those countries where we're active. In a total, it's about 18 countries where we've got some subsidiaries. As a qualified trust service provider, we are providing certificates for electronic signatures, seals, and that is automatically the closest link into the world of the European digital identity wallet framework.
Because, you know, one of the use cases is using this digital identity that sits in the wallet, for example, to use it for a qualified electronic signature. And so we are getting questions asked, tons of questions from potential relying parties, such as banks, insurance companies, et cetera, et cetera. How do they actually play in that game? So we don't run through this kind of intro slide, but we'd like to give you a perspective of where we are currently standing.
There is no official slide from the European Commission, and this is something that I'm now currently updating almost on a daily basis. Some of you in the room may know, if it was April 25, when this was finished, ARF 1.10 that was out on May the 2nd from Paolo De Rosa, CTO of European Commission, is not yet on this list. But if you scan the QR code, you got the latest update of these slides from tonight. Including in these slides, there are several things underlined. So if you are in need of searching, such as, where is the latest and greatest ARF?
Where can I find some information on the consolidated text of the EU regulation? This is your first go-to source. That's what we are using internally as well, when we look into it.
Now, for a little bit of, let's say, clarification. Some people still believe that if something sits in the architecture and reference framework, it could be referenced in these implementing acts that are currently being prepared. This is not the case. So if you want to reference something, if we want to come up with a proposal for monetarization, that stands the test of time. You will have to go into the standardization processes.
And ETSI and CELINEC are those two organizations primarily dealing with what's required to be standardized, in order to be reflected in the implementing acts that we are seeing going forward. And there are several times to be kept in mind. For banks and insurance companies, at this point in time, they do not have a strong FOMO, fear of missing out. But December 24, 2027, kicks in the requirement, if you are obliged to do strong customer authentication, that you'll have to deal with digital identity according to EITAS. Like it or not, that's part of the EITAS regulation.
And there are other things that are kicking in much, much earlier, such as the requirements for qualified trust service providers when it comes to remote identification processes. As you can guess, this slide would provide a launchpad for discussing for hours and hours. It should just be your option to go into one-on-one talks with us or one-on-two talks. We have another look into where can you currently still engage? This is now a call to action for you if you think that you are playing in the field of trust services, such as qualified electronic signatures, etc.
There is currently still a review open of 12 implementing acts for which we are at the moment also compiling our position. And within these position papers of these implementing acts, you can typically also see where there may be stumbling blocks. So reading through those statements from organizations, but also from single persons, from consultants, etc. typically reveals where we may need to work on in more detail.
Plus, in the historical way of doing European legislation, these implementing acts have been stable. Now we have something that is called agile legislation. As we don't have all the standards ready yet, they cannot all be referenced in the implementing acts when they become available by May or June this year. So there will need to be a review. And you have seen maybe that in Germany, the former German digital ministry actually had a tender out for consulting in order to judge all of these implementing acts.
Now, these implementing acts should reference to something. And reference to something of how to make money with this ecosystem, with the wallet ecosystem. And we had the internal discussion about this, of who is paying for that? If we are a privately organization, how is the possibility to come up with a sustainable ecosystem? And now the clicker is yours. Thank you. Thank you. It's very hard to take the stage after Jörg, but I will do my best. So as you can see, as we were discussing, basically our proposal is basically centered around the electronic attestation of attributes.
Because when we speak about EOD Wallet and EIDAS2, the electronic attestation of attributes are one of the new things that is coming in the scene. And it's something that claims to be a disruptive new way of sharing information about the personal information. So not only something related to my identity, so being Luigi Gastaldo, but also something related to the attributes. That is something that we could use to simplify all the different onboarding procedures, like for all the standard use cases that we usually refer to.
One of the most discussed is applying for a bank loan or opening a bank account. You will see a lot of them during the sessions that will follow this afternoon. This is one of the scenarios that is most frequently pointed out. In this case, what we are seeing is we're seeing a user that has already a EOD Wallet in his hands. And within the EOD Wallet has already stored the digital identity plus two attributes. That is the credit rating and the income statement.
This is information that nowadays, if we apply to a pre-EOD Wallet and after-EOD Wallet world, it's something that we need to show in a paper format or submitting any other evidence. With the EOD Wallet, what we could do is sharing it in the form of electronic attestation attributes. It means that we can simplify when we speak about simplifying UI, UX, the user experience of the user. For the user, the process should be easier, but also for the relying party, also for the bank.
If we think about the banks that nowadays need to do all the ML checks and all the other things that are happening in the background taking a very long process. In this case, all these steps will be simplified. But our question, and that is also very often referred to like the elephant in the room. How do we make it sustainable? Like in the sense that all the EOD Wallet should be, of course, to the citizen should be provided for free to use.
And even all these attributes from what we saw in the previous slide, we can clearly see that most part of the benefit are even on the user or on the relying party. It means that the relying party, the banks, will benefit from having a UI, a UX that will be much simpler, the onboarding will be easier, and they can also rely on trustworthy data that is coming from the issuer of the electronic attestation attributes.
So it means that all the other relying parties in this ecosystem are relying on the data that are transformed in an electronic digital attestation coming from the issuers of those attributes. But how can we keep the flywheel? The flywheel affect how this ecosystem could be sustainable. We think that the ecosystem could be sustainable if there are services, if there are users that are willing to use these services. But of course, if there are all these kind of information that will be stored in the wallet and could be later shared.
But how to do so is that we also need to guarantee a monetization process for all those authority that will be issuing these electronic attestation of attribute, especially for the qualified with a high level of trust. And what we try to do is trying together what could be the monetization, the possible business model that are referred to the electronic attestation of attributes. The easiest one, the easy-go solution are, of course, the number one and number three that are those that have been discussed until today.
So it means that the user that is paying for the issuance, so it means that to me as a user, is something that we are already quite used to. In the sense that if I have to request the renewal of the passport, if I have to renew any certificate from the government agency, I could pay for a tax, receive the passport, and it could be something in the same way also for the electronic attestation attribute. But what does it mean? It means that the user is going to pay for the issuance of these electronic attestation.
And then he or she will be spending it with the relying party that will be the one taking the benefit of having trustworthy data that has been issued and for which the user has paid. So we are putting in this way, we are putting the burden on the user. Another possible approach would be the number three. So something that could be the issuer is paying. So it means like on a government approach is the government that based on our taxes on what we pay is giving all these attributes for free.
But if we try to translate all these model, especially with private stakeholders, neither the two, no one of the two approach for us is something that will benefit for all the ecosystem. What we try to do is applying a new model that is verifier paying for this one. So there is a transaction, imagining a transaction fee. So it means that the user will receive these electronic attestation, can store it in the wallet for free.
And every time that I'm presenting this attribute to a relying party, to a bank or any other possible relying party that will benefit from these is actually the relying party that is just giving back a transaction fee to the issuer. So to those that are taking the burden of managing the entire infrastructure of having the issue, the attribute issue, the infrastructure available 24 seven and being able to comply with all the different process.
But how, and how do we, of course, what are the real world use cases in which we can apply all these scenario? In our, in our idea is that all these process has sense for all these, for all these kinds of attributes. So anything that is related to the KYC to income and finances attributes, like the declared, declared the income range, average monthly balance, the credit worthiness that we were mentioning also earlier with the opening a bank account or applying for a, for a, for a loan.
And all these could be translated in all the scenarios, of course, that can be used to be the different relying parties, but how, if it's so easy, why hasn't been done until now? Of course, of course there is, there is an issue.
Now, if we, if we remember the UD wallet has, has come to be in the, to put the digital identity in the, in the hand of the user. And one of two pillars of the digital identity UD wallet is the unlinkability of user privacy. It means that we need to guarantee with the UD wallet that the user is the one in charge, handling the identity and needs to share who are the relying party, who was, wants to share the data and which kind of data wants to share. And of course, unlinkability.
So it means that the issuer of those attributes does not need to know where I'm using the identity or the attribute that have been issued to me. And of course this thing, like because we want to guarantee a direct communication, because the only way of achieving a transaction fee is guaranteeing a direct communication between the relying party and the issuer. So they need to know that a digital credential, an electronic attestation attribute has been used to, for, to present something to the relying party.
And, but we need to guarantee this without the issuer knowing that actually that user that has presented the attribute is Luigi Castaldo. They just need to know that an attribute issued by a certain issuer has been presented to a relying party.
And this, we think that also solves some of the issues that we also have to check the validity of the attribute, because when the attribute, similarly to what happens with the certificate, with the electronic qualified certificate, we need to guarantee that the certificate is valid or not. And this happens with the same systems like OCSP or CRL.
So what we came out with the idea is that leveraging on the existing protocols, without any change to the open ID for VP issuance or the presentation, we could just simply change the, the way it works, the presentation of the, of the, of the electronic attestation attribute, making it possible. So we tried to split these in two steps. So before we mentioned that we could include the presentation with, first of all, applying a refreshing. So it means that we could, before presenting the credential to an issuer, it could be refreshed. There are a lot of possible alternatives.
We just selected two. That is one, the reassurance of the credential. That is something that is already in place or a link at credential. That is something that has been proposed by the digital transformation department in Italy. And so applying a sort of overlay that can guarantee that that credential has been recently refreshed and is still valid. And has not been revoked. So it still can be still validated. Once we issue this, that could be done before presenting it, then it comes the hard part.
I don't want to go too much into technical details, but as Jörg said, if you download the slide or feel free to reach out to guarantee this, what we did is that we would like to, based on the issuance that remains completely the same, the wallet before presenting the, the electronic attestation or attribute to the relying party will be the one in charge of encrypting the credential. So it applies to all the different formats of the electronic credential, even if he says the jot or mdoc is just putting an extra layer on top.
So encrypting the credential in this way, what happens is that the relying party will never be able to read the credential without communicating with the issuer. But this communication will only be based on a, just a single transaction ID that doesn't have any reference to the identity of the user itself or to the wallet holder.
So it means that the relying party will be able to communicate with the issuer, having a decryption key in order to access the, the verifiable, the digital credential that has been shared in order to do so, so that the issuer will be able to keep the count of the number of the presentation performed. We have a minute to wrap up.
So, and all of these of course can be. If you want to take a question. All of these can be combined even with the central rule book, because all these business model is not, is not removing all the other possible models, but it gives us all the benefit of having all the possible solution to, to guarantee a verification fee or issuance fee. And everything could be handled as I said, with the existing protocols. Thank you very much. Thank you. I think we all realize you're very passionate about the topic. I guess you will be around.
I think we can, we have time for one quick question if there's one question in the room. No.
So, okay. Quick question on the data protection elements.
So is the, the transaction ID that you generate, Is that anonymous personal data, or is it pseudonymized personal data? It's completely anonymized in the sense that is generated based on an hierarchical key, deterministic key derivation that is based on a nonce that is generated on the fly by the wallet. And that one is because he's generated on, on the primary key of the issuer of the data attributes is like just communicating the nonce to the issuer. But he will be able to generate the corresponding private key to the crypt.
The credential, the key that has been must be used to decrypt the credential that has been shared. It's a bit, it will take just a bit longer to explain it in details, but we can, I can assure that there is like guaranteeing that no information about the wallet distance or the wallet holder information can be tracked by the issuer in this case, like based on this protocol.
Well, thanks again. Thanks for having us. See you next time.
