 information on the live stream page too. Hello, everybody. Welcome to a Hyperledger Foundation webinar with Post-Italianne. I'd like to welcome you all here if you're watching this on Zoom or on YouTube or on the recording. Glad you're interested in this topic. I'd like to introduce Emiliano and Rosario who will be sharing about their experience using Hyperledger. With that, let me just go through a couple of quick housekeeping items. Hyperledger is an open community. And so that means everybody is welcome. So thank you for joining. And if you're interested in what's going on with Hyperledger or with the blockchain space, we're glad that you're here and are exploring more about what's going on with the community. Just one quick note. We operate under an anti-trust policy, which means that all of the activities are in accordance with applicable anti-trust and competition laws. If you want to learn more, there's a link here. The session is being recorded and it will be available both on the website, the Hyperledger website and on YouTube. And we'll also make the slides available. And then lastly, if you are interested in asking questions or having a discussion, feel free to use the raise hand feature in Zoom. You can also use the Q&A feature or you can use the Zoom chat. There's also a chat on the YouTube page. If you're watching the live stream there, you're welcome to ask questions there as well. So with that, why don't I hand it off to our guest speakers? Hello, hello everybody. Good afternoon, good morning, good evening, wherever you are in this moment. Before starting, let me briefly introduce myself. My name is Emiliano Bernini. At Poste, I am the head of the ICT Innovation Strategy. I've been working for Poste Italiani over the last 14 years, dealing with innovation projects. During the last four years, I've been working with blockchain technology. Together with me today, also Rosario, please Rosario. Okay, sorry Rosario, I can see you, I can hear you. So please make a... Yeah, I'm not hearing you either Rosario. Sorry, sorry, okay, sorry. I messed up. It's just my first webinar, you know. Once again, good afternoon. My name is Rosario, I'm serving as a system architect at Technology Lead on this specific project. I, Emiliano is on the strategy side. I put my hands in the guts of the systems. This is my main task. Okay, please. Yeah, so let's start. Let's start about Poste Italiani. As you can imagine from the name, Poste Italiani is a postal provider, a logistic company, but it's not just a logistic company. Poste Italiani is a multi-business company. It's also a bank, is the biggest electronic money platform in Italy, is the biggest proximity network in Italy with over 12,000 postal offices spread all over the Italy. You can read on this slide some numbers related to Poste Italiani. And so we have about 35 million customers, 1.5 million people that every day visit our postal offices. So you can imagine how big is Poste Italiani that is without doubt the biggest company, the biggest company in Italy. And we are also the main digital identity provider in Italy. We are supporting actively the digitalization of public administration in Italy. Speed that is the Italian solution recognized by the Italian government as right now about 26 million users that use this digital identity solution to gain access to online services from public administration. And Poste Italiani released about the 85% of the total digital identity in Italy. And so you can imagine that for that reason we are really interested also in the evolution of digital identity. And so we are studying, we are trying to figure out what could be the future of digital identity, the new evolution model of digital identity. And that is the reason why we started about two years ago our project related to social identity. And just to set a common ground, a common knowledge, I assume that you probably know what is the sets of identity, but again, in order to set a common knowledge I will start describing what is the evolution of digital identity over time. And so probably the first model is the centralized identity modeling which government or private sectors manage the identity of the users in order to give them access to its services. And so there are a single operator that all sorts the information about the users. And you know that probably the main problem related to this model is the fragmentation of the user identity because users need to have multiple accounts. One with every service that the user want to use. Also, there's a third party that can track all the online user interaction. The federated model partially fixes some of the issues related to centralized model and there are a bunch of identity provider that work together in order to have just one identifier for every citizen. And so the users, the citizens can have access to online services just using one username and password for a different set of online services. This model solves the problem related to the fragmentation of digital identities, but still there's a third party that can track all the interaction and can manage all the data related to the user. Sets of identity is a try to solve also this issue. And the main goal of the Sets of Identity model is to bring the users back at the center of the model and allow them to have the direct control over his data. So, the Sets of Identity model the data are in the unique control and possession of the users who is able to define and to decide to share it on a case-by-case with the service provider. So it's totally different from what from the models that we already have in the Sets of Identity model. From the models that we are experiencing right now. Imagine probably you use Facebook Connect in order to gain access to a different website. You use the Google authentication. So in this model there's a one provider that could be Google or it could be Facebook who manage your data, who share your data with third parties and can track all your online interaction. Sets of Identity try to fix this. Let me say giving the full power to the user. It's not a new topic. It's something that has been created or in some way defined almost over 10 years ago by Christopher Allen who was the first person to define the 10 principles of Sets of Identity. But now this model is gaining popularity thanks to the evolution in technology. But also thanks to the concern also about the regulators and the governments about the privacy of the users and of the citizens. So as I just said, why it is the right moment for Sets of Identity? Because I can describe you what is happening right now in Europe. In Europe there's a really a big concern about the privacy of the users. Last June the president of the European Commission introduced the possibility to develop a European identity wallet that can be in full control of the users. And is unique for all the European citizens. So a model that could go over and in some way also unify all the different experiences in the member states of the European community. And it's the right moment also because with the Green Pass in Europe, probably we have the first try to go towards a Sets of Identity model because you know that the Green Pass is in possession of the user, is the user that can share directly to gain access to physical place all over the Europe, okay? But you know that there are some problems, some issues with Green Pass. Last month have been released Green Pass for Mickey Mouse or for Napoleon. And there's no way to invalidate this pass because they were generated using valid keys. And so the unique way is to invalidate all the certificates that have been released using that keys. So it is the right moment to work on and to build a different digital identity model, a different digital identity system. Just to give you an example, this is what happens daily in our daily life, and this is something that all of you probably have experienced. If I need the certification from a public authorities, from a public agency, what I need to do is to go to the public agency, identify myself, and then the registry office will release an identification document that I can store in my wallet. And I can share directly to third parties in order to use one service so as to gain access to a place or whatever I need to do. This document have a specific format that is recognized by third parties is certified by the issuer using a special sign or something like this. But in my daily life, I have direct interaction with the issuer and with the verifier, okay? SSI try to replicate that model also in the digital space. Okay, so again, also in the online, in the digital space, so what I need to do is to identify myself to a public issuer, to a trusted issuer in order to collect what we usually call verifiable credential that is a collection of a claim about myself from a tester from the issuer. Then I can store the verifiable credential in a safe place in my wallet. And then I can use that verifiable credential wherever I need to have access and to prove my identity and to prove the claims related to my identity to a service provider. Of course, in order to prove the authenticity and the validity of the verifiable credential or the claim, we can use blockchain technology because every credential once it is released is anchored to the blockchain. Not the full credential, of course, but an hash, something related to the credential is stored on the blockchain. And so the one of the main goal of the sets of identity is trying to replicate what happens daily in physical worlds, also in the online space. In order to give full control to the user over its data and do not rely on third parties to be authenticated. So let me introduce what I call the building blocks of the sets of identity. For sure, probably the main components together with verifiable credential is the DID. DID stands for Decentralized Identifier. Decentralized Identifier is a unique and persistent identifier of the users that are the user that is anchored to the blockchain. This identifier has some characteristics for sure is decentralized. And so there's no need for central authority to generate it, it's persistent. There's no need to change it over time. It's resolvable, meaning that it is linked to metadata about the subject and the last button list is also cryptographically verifiable, meaning that the subject can prove the ownership over the identifier using public key cryptography. On the right of the slide of this chart, you can see the typical reference model for a DID. The DID is controlled by a subject by an entity and identifies, is referred to a DID subject. Every DID results to a DID document. A DID document is a digital document, usually in JSON format, that describes the subject identified by the DID. It usually contains the DID itself. Other application key that other party can use to prove the ownership over the DID contains the authentication method used by the DID controller and the DID subject of the DID and the service endpoint to, in order to contact the owner of the decentralized identifier. Usually the DID is just a string. You can see a format of the DID. EBSI is what is usually called the DID method and this is a specification of the DID. Bezu can, in this case, identify a network. And then there's a string. In this case, what we use, but Rosario, we share later with you more details. What we use is the address of the smart contract, the identity proxy that is related to the user, to the identity of the user. Another main component of the DID ecosystem of the DID model are verifiable credentials. Verifiable credentials represent statements or claims made by an issuer and referred to a subject. These claims are generated in a way that make them tamper evident and privacy-preserving. You can see verifiable credentials as the equivalent of the identity or document in the digital space. And this is a definition from the boot-resist specs about the verifiable credentials. They contain information to refer the verifiable credentials to the user, usually the DID. They contain information about the issuer who issue the verifiable credentials. Also, the type of credential. For example, if it is a passport that I'm in license, I have the assurance about them, whatever you want. Contains also specific attributes about the subject. For example, in the case of passport nationality, the validity and information related to constraints about the verifiable credentials, expiration date, the most user and other things. All information that you can find today also on a physical identity document. And last but not least, another main components of the SSI model is a wallet that is an application in full control of the user that can, whose functionality are keys and DID generation. So through the application, you can generate your cryptographic key used to manage your identity and also the decentralized identifier. The wallet is also used to collect verifiable credentials all in one place. It's under the full control of the user and it's also been used to share credential with third parties in order to have access to online, but also physical services in place. What is the main flow and the life cycle, let me say, of a verifiable credential? At the center, as I said before, there's the users who request data claims from a trusted issuer, sharing with the trusted issuer the DID in order to refer the verifiable credential to the DID. The issuer sends a tested data directly and so sends a verifiable credential directly to the user, but encores the credential to the blockchain. The user can collect the credential, the verifiable credential in his own wallet and then can share this verifiable credential to other parties, to a service provider in order to have access to these services. For example, to rent a car or to book a hotel or the application or the services in which today you need to identify yourself or to assess something about yourself. This is the main flow of the digital creation. Now let me ask you if you have some question about what we have discussed so far. If you are working on the same topic, what is your point of view about this topic? Does someone else have some question? Okay. We will have also... You have been exceptionally clear, Eliana. Okay, there's a question. Oh, great. The issuer in the previous slide. Oh, as I said before, DID stands for Decentralized Identified. So you don't need someone else to issue DID for yourself. You can generate DID by yourself. As we can see, as we will see shortly, in our case, we will regenerate the DID and release the DID to the user. But this is what happened in our scenario. And Alex, I see that you have a question too. If you want to come off mute, you're welcome to ask it. Okay, this is a quite common question. What made you choose Averlegia Basu for this project and which other protocols did you evaluate before choosing? Yeah, yeah. It's something that I'm going to share with you, but I will reply to your question. We use Averlegia Basu because it has some features that are good for our scenario, namely, on-chain permissioning is an Ethereum client. So it is ready to be fully interoperable also with the Ethereum mainnet. But we mainly choose Ethereum also because, as I said before, we are a multi-business company. And Digital Identity is just one of the things on the topic that we cover in our activity. And Averlegia Basu gives us the flexibility to have different use cases, different application, all over the same infrastructure. We evaluated also Averlegia Indi, but Averlegia Indi is very specific for Digital Identity. And we prefer to use something that we can use in different scenarios. There is another question. I'm interested in understanding the time that takes verification process. I may try to answer this one. The verification process is a process divided in two phases. There is a presentation request where somebody will ask for a specific kind set of credentials. For instance, to buy the ticket, this scenario we will show later on. To buy the ticket for a concert, you have to present two different credentials. One that certifies your identity. And the other one that will certify you have been vaccinated. This presentation request is the first step. And the second step is the actual presentation that will constitute in the fact that the wallet up in the hand of the citizen will assign a presentation that is just an object containing the two credentials that we're asking for. Both these events, both these operations are tracked down on the blockchain. So are a real writing operation on the blockchain that will last for the time, at most for the time of a closing block. So it depends on the actual blockchain you have underneath on. And now it is really configured. This is also, this answer, I hope this is the answer. So in the current version we are using, we have a closing time, a closing block time about 10 seconds, I guess. Six seconds. Six seconds, okay. There's also, so you have two operations that sum it up at most 12 seconds. There's another question that asks if it is viable to verify billions of users at time. This is the verification process is once again a presentation and request a proper presentation loop. And once again, you need to scale your infrastructure in order to accommodate such an amount of requests per seconds easily. The good thing of blockchain is that you may be able to scale up these quite easily. Of course in a system like our you just, not just everybody can install a validator node, but it is something viable in a way. And the short answer is that we are not really aiming at this goal at the moment. We are most in the phase of developing a proof of value more than a proper production-ready system. If I can add something to what Rosario just said, the sharing of credential almost happens offline of chain. Okay, so you don't need to write on the blockchain every time you share a credential with a third party. The third party just have to read on the blockchain to check the validity of the credential. And it is a really good point because we all know that right now blockchains have some limit in writing something on the blockchain. Why is it good at reading operation? So, we think that the system could scale, I don't know if to support billions of transactions or a user, but for sure what we have the chance to test that they can support over 1,000 reading operation per second right now. There is another question. Okay, I lost the chat, okay. This one says, what is the governance framework for digital identity in Italy? Is there a minister for it? Yeah, yeah, for sure. There's a minister and there is also a public agency who define the technical specs for a system to be compliant with the national identity framework. Right now SSI is not part of this technical identity, this technical framework, but we are working also with public agencies in order to develop the framework in order to include also SSI within the recognized digital identity scheme in Italy. But again, we are also working with European Commission. Okay, there is another question. What's the roadmap for the wallet? Which credentials are you planning to add? Will it include the financial services? The roadmap is something we described in the last slides, I guess. And the credentials are not predefined. I mean, the system is a kind of accommodate whatever kind of credentials you would like to use. Sorry, this is right now, this is a prototype, this is a experimentation that you are running together with other public agency in Italy. Okay, so we don't have a defined roadmap of adoption of such a system. Probably we'll need to wait for a regulation and then we can define a specific roadmap. And yeah, it could be for sure a good idea to add also support for financial services in our wallet. You know that, as I said before, that post-Italian is also a bank, is also a payment service provider. And so we can combine together identity with financial services. And for that reason, we are also interested in what's happening globally with the central bank dinghy occurrences. Okay, there is another question that I'll try to summarize is how the ecosystem can trust that the DAD is going around. I may answer to this one. DADs are just what the name says, are just identifiers. What you have to actually trust is the credentials and the presentations that will be where the real meat of the system is. And this is a performance that we'll try to discuss these in the next few slides in registries where these credential and presentation hashes are kept track of. So the DAD is not really the problem. Actually, you can create as many as DAD you want. DAD is just an anonymous identifier you use within the system. So you don't really need to trust the DAD, but you have to trust what the DAD does in the system. Okay. If there are no further questions, I will go on. Okay. Just two slides, then I will leave the stage to Rosario to go deep in technical details of our solution. As I said before, the social identity is not a new topic. There are a lot of projects running about social identity. Sovereign, U-Port, ION, Alastria. And in order to not reinvent the wheel, we decided to start from the Alastria implementation and to customize it based on our specific needs. Why Alastria? Because Alastria share quite the same vision about us. Because Alastria is a stable and mature technology. And as I just said before, because Alastria is built on top of the Alastria blockchain. We use Iverledger Bezu and Iverledger Fabric. So for that reason, we decided to start from the Alastria implementation and from the Alastria ID model. Okay. Now I leave the stage to Rosario who can share with you technical details about our solution. Thank you Emiliano. Next slide. Okay. This is something Emiliano already has described before. What we like is to develop a system that can be compared to current system already available in the round. So we took a clear decision here. We developed our system post-AID like Alastria, like Alastria did, likewise U-PortServe to did. So it is just based on those smart contracts on a generic Ethereum virtual machine. In our specific case of use, it is based, what I said. We like the solution because it allows us, please next slide, allows us to accommodate more than one use case on the same blockchain. So post-AID in our specific ecosystem will be just one of the use cases and the intent of become the standard identification layer among these use cases. Next slide. From a technological point of view, of course, you have to have this kind of diagram in a slide, a diagram with the stated blocks. On the left, you can see the current version of the system. So you have a post-AID wallet which is a mobile app that will use a post-AID wallet and together with the example issue and the example of the service provider which is just the verifier for credential. Both these three different identities will interact with the post-AID library that is a thin layer of JavaScript that we'll play together with the smart contracts that are hosted on the node. We are moving toward a more generalized version of the same architecture where post-AID, the wallet app, the issue of the verifier will just be a special flavor, a particular favor of an extremely configurable agent called the post-AID agent that will interact with the smart contracts and will allow to have an highly configurable infrastructure that can scale and accommodate the different use cases. Okay, next slide. This is actually, this is the agent-based situation that the agent-based scenario is what we are working on right in these days. So we are pretty confident that we have something running in this new way for the end of the year talking about deadlines. Okay, next slide. From a logic point of view of the smart contracts we collect on the blockchain, we have in these slides all to get a group photo of the different smart contracts. We, as Emiliano said, we have designed our solution starting from what the colleagues of Alastria already made. They took a decision and we liked it and we kept pushing on this decision. What we did is to have a solution registry-based. So in the blockchain, you will have a registry collecting all the identities that is everybody will interact with the system whether it is a citizen or an institution or a website selling concert tickets. Then we have a service provider that will collect that the particular situation of entities which will provide the services. So there we are interested in verifying credentials. Then we have the issue registry that will collect the particular entities that will provide credentials. And then we have the credential registry, the presentation registry that will collect the hash. So just the track of credentials, the issue credentials, and now they are used within our presentation. That are the two sides of the triangle Emiliano showed before. Then we have a public key registry that let us to connect an Ethereum public key with the DID in a proper way. And this also allows us to implement a recovering mechanism in the case of the most common case where a person or a person has to be able to connect the most common case where a person loses his phone or just forget his phone somewhere and they get lost. He will be able to install another app, generate a new wallet and ask a couple of friends named the guardians to associate his new phone with the new public key to his previous DID. In this way, he will be able to access once again to his previous identity. Then we have another registry, the credential schema registry that will collect the different schema or credentials. You will be able to get, to receive, to have issued and to present in a presentation. At the core of all the system, there is the identity proxy. The identity proxy is a special and extremely simple smart contracts that is deployed once for each DID. So the DID provider will just deploy a smart contract and smart contract, this such a smart contract just separated interaction with that will happen on your wallet toward the actual operation you perform on the registry. The address of the identity proxy is what will constitute the DID part, the proper ID of our system. Okay, next slide. Okay, so this is the life cycle we depicted before. So we have, as Emiliano said, we are just post-Italian and we are one of the, I don't know, Emiliano, maybe this one is something you will present or I will keep going. Okay. Okay, so we are post-Italian and so we are digital identities, the largest digital identities provider in Italy. So in our specific version of the wallet, you will be suggested to receive, ask for the issuance of the first digital, over the first credential of your digital identity that can be the speed credentials, speed is our digital identity, national digital identity system. This is not at all mandatory, actually we also have a white lab version of the app where this is just a configurable step that you can easily skip. Then you may ask for a vaccination credential and once you have collected both these credentials on your wallet, you will be able to buy a ticket on our website. In the video, in the next slide, you will be able to see how the interaction with the speed provider, the vaccination center and the website may happen in different ways, both with the blinking and by the means of a more traditional QR code. Okay, next slide. Okay, this is a course we made a video because to run away from the wicket widget of the demo. Okay, this is the welcome screen. This will ask to unlock the storage. We intend to use hardware storage to memorize the private key. This is the most common phase of generation of our wallet. So we'll just have to wait some second. Okay, this is the wallet has been generated. This is the passphrase. And like, yeah, okay. And this is the home page. Of course, in the banner in the upper part of the screen, just invites the user to receive the speed credentials from post-Italian. Let's go with the video. Okay, now, okay, this is my DID, a QR code in case you intend to share it. Well, it might be a little bit more, so let's go directly to the generation of the speed. Okay, this is the moment where you perform a legacy authentication on speed. This is not the generation of a speed identity. You already have a speed identity. With the post-Italian is from your previous life. And this moment, in this moment, you are doing a legacy authentication on speed. Then go on. Okay, this is the legacy authentication with the pin. Okay, this is the moment where you have received, you have just translated your previous speed credentials in a new SSI-based credential. And you just have received it. This is just the list of the events that happen within the app. Okay, let's go on. This is the application. Let's move a little further. Why? I'm still here, because it's too long. No. With the video. Sorry. Sorry. Sorry. No. With the video. Sorry. I just switched to Italian because my Italian is way better than my English. Okay. This is the moment where we are asking for vaccination credentials. The QR code is just... May I pause? The QR code is just the presentation request. The website of the Vaccination Center is just asking us for a digital identification credential. So they are asking for the specific creation schema that is speed. This dialogue just requires the user to authorize the sending of the credential. Fingerprint to unlock the hardware-created storage. Okay, we signed the transaction and we send the credential to Pausa. We send the credential to the Vaccination Center. It has sent us back the vaccination credential. Okay, now we have both credentials. They have speed the credential for our identity and the vaccination certificate for the vaccination. And we will be able to buy the ticket for the Deep Purple concert. Okay, next. Go faster here because it is pretty... Okay, these are just the data. Okay, now we are on the website where you can buy the ticket. This is the presentation. In this particular presentation, the website is asking us for two credentials, as said, the identification and the vaccination. In the particular case, we may have, for instance, more vaccination credentials. In general, in case you have more credentials that are there to a particular credential schema, the user will be asked to select one single credential to send back to the verifier. Okay, next. Okay, now the system will just accept the presentation. The back office of the system may check if the signature is correct, if the schema is correct, and so on. Okay, and as you can see, the web page is accepted, the credential is unlocked, the button to finalize the buying of the ticket. Okay. I don't know if it was clear among the different things we showed. There is a place where you can see the different credentials you have in your wallet, and you can also see the lifecycle of such credentials that is where such credentials have actually been presented. From such a dialog window, you will be able to control the presentation and, for instance, to revoke a presentation from a verifier. Okay. This is the roadmap. We are hammering our MWP3 hopefully for December 2021. These are the specific functionalities we are working on, the social recovery functionality that will allow us to recover the access to a lost identity. Selective discourse, this is a tough one because the idea is to allow the citizens not to release the whole credential, but just the single bit of information in a safe and secure way to access a particular service. The most classical example of the launch move is to provide in a secure way the fact that you are older than 18 years without saying that you're a birth date. And also, this is the current version we are working on is, as I said, the architectural evolution moving from the library-based version to the agent-based version. This is some quite deep architectural effects that would be nice to discuss with a beer. And that's all. Okay. I don't know if there are more questions. Okay. Yeah, yeah. I don't know if you have any question about the second part of the presentation. We are here to try to answer you. There is an old question about why we used Ethereum and not instead of more modern blockchain 3.0 platforms. Federica Trilli is telling us about Java-based platform. Actually, this is a project we started a couple of years ago and the Ethereum-based solution who looked at that as the most promising for us and also maybe it was the only available at the moment. This is something we must keep an eye on. Of course. Thank you for the idea. There is also another question from Simone, who asked what are the security mechanisms in order to avoid the subject that can generate a DID for a subject B and start to run online interaction of subject B. As Rosario said, DID are pseudonyms. Okay. So are not directly direct tied to an identity. What is tied to an identity are verifiable credentials. Verifiable credentials contains claims about a subject that is a DID and so you can and so you have information about the subject of the DID inside the verifiable credentials. So again, the subject is signed by a trusted issuer after an online identification of the subject. In the scenario of the demo, what you have seen is that I have generated my DID as the first step on the app but I have no credentials related to such a DID. What I do is to have a legacy authentication using the classical speed and then post-Italian X like a trusted issuer and release you a verifiable credential containing the same information, the same claims of the speed identity. Okay. But I need to perform before the legacy authentication with speed with two factor authentication with the same level of assurance of the actual speed identification. I don't know if it may clear this scenario. There's another one question from Matteo. How the service provider verifiable will request to post a select part of verifiable credentials. First of all, to make clear the service provider will not ask to post Italian to release a presentation and to share a credential. Always the service provider verifiable will ask directly to the user. There's always a direct interaction between the user and the issuer and between the user and the service provider. So the service provider, the verifiable will ask to the user to provide an information. For example, in order to buy a beer or to buy a drink you are over 18. And so this is a piece of information that the verifiable will ask. Show me that you are over 18. Okay. And it is contained in the presentation request. The app will be will be will reconnect the request and will ask to the user to provide such an information. So it's all managed by the agent component. Okay. There is another question for you Emiliano. What business model? That's a really, really good question. Because as you can imagine we are wondering what could be the business model and what we think is that yes, digital identity we stay free for the city. And we'll be always free in order to be more inclusive. But what we think and that we can provide what we call premium services to help the users manage their identity. Let me make you an example. Decentralize the models is what you have for example, for Bitcoin or for crypto or decentralized finance give full control to the users. Okay. But from what as I said, as I usually say from great control become great great responsibility. So probably not all the users are ready to manage their keys or to store their valuable credentials in a safe place. What we think is that we can provide premium services in order to assist them giving for example an encrypted backup or to assist them in case they lost their phone or they have compromised their keys. This is what we are what we think could be a feasible business model. I don't know if it's clear Simone. Can you hear me? Yeah. Okay. The last question is about okay it's clear to me that by means of a revival credential issued directly from Poster a legacy authentication based on speed Poster can issue a revival credential including all the same data that is already included in the speed electronic identity. But the last question is how what about the trust the trustworthy of the private key generating by the wallet itself? When I set up the wallet I'm going to generate a set of key pair for simplicity let's think one key pair. Okay. Who is the issuer that among all the ecosystem can assure the trustworthy of that key pair because in the end the key pair is generated by the personal handset running on that handset. Okay. But the key pair will go into the blockchain but who is the subject that can guarantee for that key pair for sure cannot be the end user itself. Just to be clear just to be clear the hash of the key pair doesn't go on the blockchain the key pair the private key is just stored on the on the wallet of the user. Okay. There are no ashes of private keys that go on the blockchain first of all just to make clear. No, I cut short I will refer you to some the related data. Nothing you're relating to the private key itself. I will refer you to the private key for sure and I cut short for speed up but I was referring actually to the fact that something some reference needed to be stored about the public key inside the blockchain and I think in my knowledge about the document it's not the did the document. Yes. So there is something that the document is a sunny object. Yeah, not really. There is just a public key. It can also contain it can also contain a proof a proof that is a proof of possession over the documents and could be signed by the owner of the the ID. Okay. And so it can contain a proof. So it can also contain a proof of possession from the from the organ or the printer key and of course verify key that is the public key in order to check for the authenticity of the the ID document. Okay. It's clear. Okay. Any other questions? Any, yeah, people are welcome to ask any other questions. We have the room if we need it, but if not we don't have any questions. Okay. We'll give one or two more minutes to see if anybody else has a question. I'll also share my screen. Okay. Just to encourage everybody, you know, this is just one way to get involved with the hyperledger community. If you're interested in this discussion and want to continue the discussion around decentralized identity or about blockchain in general, or about any of the hyperledger projects, you know, you can also go to our website hyperledger.org. There's a number of different resources there around how to get involved in the community, how to learn more about the different projects, all of our tools as an open source project, all of our tools are also open as well. You're welcome to get involved on our chat on our wiki and our repos on our mailing list. So we do hope to see you again after this webinar. And this is just one of many webinars we host if you're interested in watching more. Keep an eye out on our website. We also host a number of other virtual meetups, other community calls, you know, there's a lot going on in the community. If you are interested in getting involved more, we would certainly like to see you again. And again, if you do have questions, certainly feel free to reach out. And with that, thank you for joining and we appreciate your time today and we hope you learned a lot. So thank you very much. Thank you. Bye bye. Bye.