 Okay. Good morning. Good afternoon everyone and myself Nikhil V. Chandran. I'm the organizer of the Hyperlegic Pochimita Group. Today, we are here at Tripitian K building at KBA and we are organizing the offline meetup here. So today we have with us our guest, Mr. Sunit Bendre, who's having 11 years of experience in the industry and having a strong hold on enterprise and tech stack technologies and the blockchain stack. Mr. Bendre has led projects in various domains like telecommunication, payments, wealth management, enterprise architecture and blockchain. He is currently working as technical architect in Ironworks Technologies, where he drives end-to-end blockchain products right from the early stage of ideation to production-grade product. Also, we have Ms. Anusha Garg, who is having four years experience in blockchain. She has worked from the platform level to the cryptocurrency exchanges. She has been associated with KBA before. She has keen interest in design and research and development activities with this. She also likes to experiment and play around with new challenges. So I would like to hand over the control to Mr. Sunit and Ms. Anusha to present on say no to centrally controlled identity, which they will be presenting to you all guys. Thank you everyone and welcome Mr. Sunit and Ms. Anusha. Okay, now I think it was good. Yes, it's not getting okay. So we'll get started. Thanks, Nikhil. So today we'll cover on the topic, which is say no to centralized controlled identity and we'll quickly go through what is identity, the use case and one demo as well. So I'll hand over to Anusha to take the initial content. Yeah, so hi. So discussing about identity first. So what is identity to you people? Identity for us is a combination of our biometrics, what we represent and our demographics. So biometric has enough fingerprint, iris, scans, etc. Demographics as in my name, my age, where I live at, etc. And what I represent as in maybe my bank account statements, etc. So these are what constitute my identity. So this is like something which is personal to me. So identity today has been structured into three formats. First is a centralized identity or the siloed identity. So what do we mean by centralized identity or the siloed identity? That is that my data is being controlled at the centrally located server. So for example, I get my driving license or my adhar or my bank account information from a centrally controlled server where my data is kept. And I'm just accessing that data through various devices. So that is one. Second is the third part, your federated identity system. That is when I am using a third party to log in into a system. So suppose I use Google Earth, I use sign in with Facebook, etc. So that in that case, I let the third party provider authorize for me or log in for me. So that is a second kind of identity that I'm using. So the problems with these two systems prevalent systems or most commonly available systems is that first we're oversharing our information. Like for example, if I'm signing in with Facebook, then Facebook knows that I've signed in with some other website. The website can use the data from Facebook. Facebook can use data from this website. But did I authorize it? No, I did not. Second, central storage. They have a central storage for management. And so that becomes a central point of attack. Easy to a blocker because if the service at this central storage dies, then our data is not in safe hands. Then only human readable and verification services. So if I have a hardware copy of my adharkad, what is the verification process? A person only sees my adharkad and says it's okay. Or I need to go through a rigorous verification process of getting in scan and check the adharkad number, check, etc. But that also only some people will have access to this model and they can only check, not everybody can. Then identity spoofing. This is something that we all have been facing that our identity is being used on various social medias without our consent at different places. We have our IDs that we don't even know my faces with some other name existing on some social media website, etc. So identity spoofing is very common. People are, I don't still don't know who is using my phone number for some connection that he is having. So these things are prevalent and we know it. Tramping of the document. Our documents, we can easily tamper with the documents. How many of us have not tampered with COVID documents? So many people have tampered driving licenses, etc. So this is a truth that we can easily tamper with these documents. Security is compromised. I lose a hardware document or a paper document and I lose it. Then secondly, if somebody gets access to it, they get access to the full document. So security is compromised. Forgery, anybody can forge our documents. So forgery is there. Then there is a data bridge. So how this data is getting transferred, how this data is getting shared. So this data bridge is also a very big shortcoming. Now for this, I'll also cite an example. So suppose one of the aspects of my identity is my bank statement, if I'll say. So what my bank statement does is if tomorrow I go for an admission to, I go, I take my kid and I take him to school and I go for admission. The school records asks me for my whole statement. What do they want to know? They only want to know my salary. But what am I giving them? I'm giving them full description of what transactions did I make? Where did I make these transactions? When did these transactions get processed? What was the amount? But why? Why should I share so much of information? They only need a proof that my salary is this much. So I'm over sharing the information. This information will get stored in their system. They can reshare it. Why? I am not giving them access, but they have information. They can share it. This information, they are verifying it in human readable form. They can spoof it. If they're sharing it, they can spoof it as well. So this is a security compromise that we've made with these systems and we're working with it. So we came up, then decentralized identity came up, which wanted to solve these issues, these trivial issues. So what do decentralized identity say? That there will be three actors in our system that is the issuer, the holder and verifier, wherein the control of an identity document once issued lies only with the holder. Holder is the king. Holder is the one whom the verifier needs to approach for verifications. And that also if the holder only consents too can get the verification. So explaining about self-sovereign identity or what self-sovereign identity is. So self-sovereign identity system gives you the ability to use your digital wallet and authenticate your own identity using the credentials that have been issued to you. So basically something like I get a credential of my own. So I get my Adharkar. It exists on my mobile wallet. And if tomorrow I want to share some specific information about me to some other organization, I use this Adharkar to share my information and I can also judge like what information they need. And I'll not share the entire thing. I'll request them to ask me only for the information that is required and I'll provide proof for only that. If they need my name, I'll provide a proof for only my name. If they need my age and a proof of only my age or an address, then an address. Everything is not required per se. You no longer have to give up control of your personal information to dozens of databases. So if I am providing, which essentially means if I am providing a proof that does not exist persistently on that with that verifier. Once the proof is done, the proof is done. The data exists with me. He does not get the access to my data that he can share for them. Each time you want to access goods and services, the risk of your identity being stolen by hackers. Decentralized identity and verifiable credentials plus SSI empowers us to receive digitally signed credentials, store them in our private wallets and secure securely prove our online identity. So basically my credentials lie in my wallet on my phone device, which is secured by my private keys and public keys. And I can verify myself by sharing these cryptographically signed documents to the verifiers. So coming to the very important concept of dense. So what is it? Essentially, a wallet is a composition we know of a public key, a private key and an attached storage with it, which stores your cryptocurrency, etc. For example, if today in my Metamask I have 10 ethers, then with the same public key and the same private key, I go to MEW or some other wallet, I still have 10 ethers in that account. It is available everywhere, right? So similarly did where did it come from? It's coming from the same public private key pair that we are generating. But in here we're using different algorithms, not necessarily SECP that we use. We also use ED25519, etc. for our key generation algorithms. So once we've generated a public private key pair, we convert the public key into a did. So did is a global identifier just like a public key. And this did has a corresponding did document, which in which we define who the controller of this did is, which algorithm was used to generate this did, which network was used to generate this did. Where did this did get the generational, which is the service endpoint where you can use this did. This we publish on the ledger. So in Ethereum world, if you say I have an account of public and private key, once I do a transaction, it gets recognition on the network that this account has these many points. Similarly here, we make a transaction and we make the did public. That is we write that did with a did document, it's corresponding to a document on a ledger to just state our identity or publicly reveal our identity. And what is our identity? It's just a identifier or did, which you cannot relate to my name, right? So the did is persistent. It cannot be changed. It is cryptographically verifiable, as in if I'm generating it by some algorithm, it is, you can verify it. Then it is decentralized. There is no central authority controlling it. Today, you can go to any registered registrar. You can find from W3C or the universal did register, go there, make your did publish it. Nobody is concerned. You can do it on your own. Resolvable. So if today I tell you that this is my did or this is my identifier, you can again go to a unit resolver, put that did identifier there. You'll get information or the did doc associated to it that where was this, which will tell you that who is the controller or who is the public key for the did, who, which network this did was generated and which was the endpoint. And when was this did last updated? So these things you can get. So that means that the did is persistent, available, cryptographically verifiable, decentralized and resolvable. So your identifier that is available everywhere, but you are not, but it does not relate to your personal information. Going to the concept of VCs now and then connecting them both. So what are VCs? So VCs are nothing but credentials, but they are cryptographically verified or signed documents that are stored on your digital SSI wallets. So if you'll see an example here, we have a Maharashtra straight motor driving license. So in here, what is the credential metadata? So credential metadata here is when the, the driving license number, the dates of, you know, dates of issuing and dates of your vehicle, etc. These are the credential meta records. Now, what are the claims that the driving license makes? The driving license can make a claim that this is your age, this is your name, this is your surname, and this is your address. So that is somewhat your claim. So claim as in, if tomorrow I provide a driving license to somebody telling them that I am this person, then these are my claims. My name is my claim. My surname is my claim. My birth date is my claim. What is the proof? The proof is a signature of the issuing authority here. If you can check here, there is a signing and ID of the issuing authority. So that is the proof, right? Now connecting it with a decentralized identifier. So basically this credential will be issued to me by the State Motor Driving License Association only or the RTOs. There they will sign this document using their private key, right? Corresponding to their data, right? Now, if I have to give this driving license for verification, maybe while buying a car or, you know, giving my age proof to somebody, they will send this request. They will check that if I am of a certain age and above, or do I have a driving license, they'll send me a proof request. This proof request will check if it is coming from a verified issuer or not. Using that did they can check that it is coming from the correct issuer or the RTO, Maharashtra RTO. And then they can give me a verification. Yes, I have a driving license and my age is above 18. So that's how things work in the SSI world, wherein people did not get my information. They did not get my ID card, but they got a proof that I am a valid driver. I have a valid driving license and I also have a valid date of birth or age. So that is how things are working here. So I'll hand over the mic to Sunit so that he can proceed with the, okay, sorry. There's one thing left. So there are 10 principles or core principles of SSI, which were designed to overcome the pitfalls of the existing system. So what does SSI say that whatever we see has been assured to us, should be existent everywhere. I should have existence of my driving license in Maharashtra, Kerala, Madhya Pradesh, everywhere. I should be the sole controller of it. I should have, it should exist everywhere and I should be able to access it as well, right? Wherever, on whichever device I want to go, it should be accessible. It should be transparent. That is the way it was issued should be transparent to me. The process should be transparent to me. It should be persistent. That is it should not be changing from, you know, demographic, from one geographic location to another. It should be persistent or I cannot change it. If I want to change it, it goes as a separate transaction on the ledger. Portability, I can take it from one device to another so that portability should be there. Protection, it should be protected by some mechanism. Here we are using cryptography to protect all our data. Interoperability, it should be interoperable, like it should be, you know, globally acceptable, interoperable. It can also travel from ledgers to ledgers, etc. Consent, that is a very important word that we use in SSI, consent. So, like I mentioned, if I, if my data needs to be shared with somebody, I should be the one consenting to it, not some third party. That is, if tomorrow I need to, you know, I need to, my data is required for some research, then I should consent to it, not some third party agency who had previously taken my data. For example, if I open a bank account, I provided them my phone number, I did a KYC, I gave them my address. That does not authorize the bank to share my data for research, right? If they want to share my data for research, that the research company should come to me and ask for my consent, that are you consenting for us to use your data? Then only they can get my data to share. And minimalization, that means that I should get an option to share minimal data. I am not required to share my full ID card or all the data points on my ID card. If the required authority needs minimal data, for example, the school requires my, only my salary proof, then they should get only that much, they should not get my transactions, my address, etc. They need my salary proof, they should only get that much. So that is what minimalization means. Moving on, we have the trust triangle and Sunith will take over. Thanks, Anusha. So before, before we move on to the how, we already understood the concept of SSI will dive more into detail how those are achieved. But I would like to give a thought and I think everyone should give a thought on the day-to-day basis with these core principles. So keep in mind some of these core principles, few are more from a technical point of view, but few are from a day-to-day point of view. So on daily basis, give a thought, are you, are your, are your documents following these principles? For example, bank, bank statement, which Anusha already mentioned, do you have consent to share the data? Do you have control of that data? Is it getting shared? Same goes with other use cases. For example, your, your social media data, do you have control of your social media data? Do you provide that consent whenever that data is getting shared with third party? Social media content is, is one of the area, your, your bank statement, your credit card details, and so you should keep in mind and, and try to adhere to these principles. Moving on to the how, how underline this can be achieved on the SSI side. So this is a very basic triangle from an SSI point of view and there are three stakeholders in the SSI ecosystem. One, which is on the center is the holder. So holder is nothing but individuals who owns the data. So all individuals have their own the data. So here a holder will have a mobile device, which will consist of an SSI wallet. That particular wallet will have, will hold the details. And as, as Anusha mentioned, the, the mobile device SSI wallet will also have the public, public key or public and private key details on the device, which is again a symmetric key what we're using. So all those credentials and data would be available with you, not with any other third party servers. In, in the current system, we are storing all our data to the third party servers, but with this use case, or with the SSI, you will hold all your data on your device. So you control it. And because you hold everything on your device, you are also providing consent when the data is getting shared or used by any other means. So coming to the left side, which is issuer side. So nowadays in web two or with the current day to day activities, you might be aware that there is some issuer who is issuing your documents, be it identity documents or some, some documents which represents yourself. So for example, you get a driving license from, let's say transport department, RTOs, you get passport from a passport department, you get your degree certificates from universities. So there are some trusted entities and trusted issuers who are going to issue the verifiable credentials or document. That is what the left part of other block represents. Coming to the right hand side, the verifier. Once the document is issued to you, once the VC is available with you, without reaching to that particular issuer, we should able to verify the document, what we are having it. The verification can be the information which is, which is, which comprise in your VC, that data should get verified. For example, when you go to a bank for an account opening, when the KYC is done, the name address details need to be verified, the claim or the subject need to be verified, asserted. Similarly, this verifier can look at some of the information from your VC, not all, whatever is requested, only that information will be accessed by the verifier. So the verifier will play a role out here. And as I mentioned, there is one more layer which is verifiable data registry. That's nothing but the DLT or the ledger, what we can say. Currently, if you can, if you take an example, when we open any website, which has an HTTPS, behind the scenes, it's our digital certificate. And if you look at those certificate, those are issued by some central tested CS, root CS and CS. Again, we have to rely on those certificates, which are issued by some of the central entities. Here, when the, when the blockchain ledger comes in place, the issuer is going to publish their did and did document, which was explained a few minutes ago, on this particular ledger, which means the issuer's public key would be accessible to anyone who wants to read it. And when the verifier is trying to access the data, which is available from your site, the verifier can pick up the public key from the ledger and check the verification, which is a cryptographic verification. So verifier is also getting a trust that the data which you're trying to represent to a verifier is issued by trusted entity. I'm not showing the data created by my own, but it is actually been issued by, let's say, RTO passport office or X, Y, Z trusted entities. So this is a basic, basic SSI concept and stakeholders which play a role. Now, let's move to a use case. So from an ironworks point of view, a lot of use case has been implemented across the world. But this year, this year, we were privileged to implement one of the use case for the, for the European consortium. And that, that European consortium consists of, consists of some of the government entities, states, as well as some of the private companies from the Europe. So that this particular, what I'm trying to give a use case here is available in public domain. So we can, you can go through the source code, their concept, their idea on the GitHub. So that is what we'll quickly touch upon. So the concept on the guy X or the Europe ecosystem is that they want to create an identity layer. So as if you, if you think a little bit more deeper on the internet side, internet does not have an identity layer altogether on its own. Internet is mainly meant to exchange the data across entities. So they do not identify or they do not trust that information as an architecture of an internet. That's where we, from an SSI point of view are adding an identity layer on top of the internet, which is a data exchange layer. So once the identity is there available, based on this identity layer, we can trust the entities who are exchanging the data. We know with whom we are exchanging the data and who is reading our data and so on and so forth. So that, that adds the trust layer and identity layer on top of the internet post that as soon as we have an identity and the data transfer or the data exchange layers, now the services and the data can, can be on top of this. So now the end users, individuals can leverage the services, companies can provide the services, make their services available for subscription and in trusted manner, the ecosystem plan can play a big role and it would be very easy, faster for all the, all the major stakeholders to run their businesses. And that's where the complete ecosystem will come in place. So GAIAGs, it mainly is, is again, trying to keep on the principles of decentralization. So the, the, the complete architecture is based on the principle of decentralization. And with this architecture, the users will control the data on their own devices and they can also trust the other entities depending on the, based on the identity. Let's move more on then, on very high level architect, this is, this is the hierarchy of the overall solution because this comes within federated as well as a decentralized format. I'll explain you that. So for example, at one layer, they are doing a federation. So first module, they block what you see. It's more of a government entity where they have a consortium, a group of company or a government institute who is going to issue the initial level of VCs to the companies who are getting onboarded. They also have the governance. Now, as, as the citizens or the business of any XYZ countries, we have to adhere to some of the governance which are available in place. So these governance will be, will be, will be implemented or will be all the companies will have to adhere to it. For example, let's say in India, if any company getting registered with MCA, they have to get registered, they will receive a incorporation certificate and they, then only they can start their business. Similarly in Europe, they have their governance policies. They have to have some registration with the government entities. Only this set of federation would be, would be available with the companies. So as soon as the companies are onboarded and these, each individual will act as an issue or verify what we saw in a previous slide. So once the company's onboarded, let's say somebody getting onboarded as a national ID provider, some banks will get onboarded, employers, companies will get onboarded. As soon as they get onboarded, they would receive a verifiable credentials in their own wallet and they will act as an issue or verify in that case. So VC is nothing but after the, after the, after they meet the governance policies and rules and accordingly. And with the GIAX, we have implemented this governance policy with the Rego programming language. So these programming, so these Rego policies will get executed in each of the flows as they are in place. And once they have the VC, now they, now these will act as an independent or they will act as a decentralized in decentralized behavior. So federation is done for each of the organization. Now they will act as a decentralized format, which means they will work independently with the end users. Same goes with bank employer. And each will also have their own trust registry. Trust registry is nothing but again a governance model. So for example, NASCOM will put you some or RBI will give you some governance policies at a very high level for the banks. And then each bank will have to add their own governance or own policies at their own respectively. Similarly, they can implement on their own. That's where each will act as a decentralized format. And here the third layer, which is a mobile device, those are nothing but the end users, those are the SSI wallet. They can connect to the respective organizations and exchange or subscribe to the services. The good part here is as organizations have a VC with them, and we saw the, the issuer verified and also a holder. So each holder can also do a verification of the organizations in that case. So many times we come across a situation where the fraud companies, they're in after few subscription transactions, we are not able to do the appropriate transactions later on. That can be avoided to some extent because initially at a very early stage, you can do a verification of that company or an institute. And once the verification is done, you know, they have met some of the governance policy and henceforth, and then you can trust to better extent. Moving on to the architecture of this complete system, though this is still a very abstracted architecture, what we want to represent. Otherwise, it would be a too much elaborated one. But coming to the basic architecture, trust registry, what we just had a discussion. It's a governance policy written in a regular programming language. So you can add these, you can write these policies, what policies to be met on each of the transactions. The central part is the organization credential manager. So the blue box, what we saw as an organization institute, this will be an independent entity, which will act in decentralized format. And it will consist of its own wallet, which means a cloud wallet, which means they will have their own public key, private key. They will also receive the VC from a federated system or the governance institute. The central part, which plays an important role, AFJ is nothing but a hyper ledger Aries JavaScript framework. That's the framework getting used for to act as an issuer or a verifier on the blockchain side. And then some of the microservices are available to have the scale and handle the responsibilities in the complete ecosystem. Coming to the left hand side, we have an actor, which is nothing but an end user who holds the personal credential manager. And this personal credential manager is nothing but your mobile device. And there's a portal marketplace available. So any user can log into a website, marketplace portal provided by the XYZ Institute, and they can leverage the services. For example, any wealth management service companies want to provide their service on the portal. So end user can look at the service, subscribe to the services. As soon as they subscribe to a services, they will receive a verifiable credential that you are subscribed to so and so service for XYZ duration and more details around it. And the company is also in a way trusting the individuals because now all the individuals have to prove their national ID before before those are getting subscribed. So we know these are the legitimate users. These are not the default users and XYZ detail. So the company also get to some level of trust before before they issue the subscription to any individuals. Authentication authorizations and mediator about the mobile notification. These are some of the modules which are available out here. Though we have not represented here the ledger, indie ledgers and other things, but again an abstracted way what we wanted to represent. So let's move on to the demo part. And the use case is that here we are going to deal with three verifiable credentials. One is a national ID, second is a vaccination certificate and third is a railway ticket. So by default the national ID should be there with all individuals so that they can represent themselves to any subscription issuer or a provider. So that's where the digital identity will play a role. Then we have vaccination because we have just gone through a big pandemic which is a COVID and that's where the vaccination and we knew that vaccination certificate is required or to do any reservation or a travel or a public appearance. That's where in this use case we have kept the vaccination certificate mandatory and then the railway ticket would be issued to individuals. So we'll walk through the demo right now. Okay, so on the right hand side this is the mobile screen what we are sharing here and this mobile screen what you see is a ADEA wallet which is developed by Ironworks and Blockstar. So this is nothing but an SSI wallet. So the one what you saw holder and the corresponding block in the triangle is nothing but a technical representation out here. This is an app SSI wallet. It consists of public private did certificates available inside the wallet and it also have storage which holds the verifiable credentials. On the left hand side we have a demo page where we are going to represent the railway and the second use case we are also going to represent a passwordless login. So we'll talk about that. So on the mobile side we'll quickly go and register ourselves. So creating wallet is nothing but you're creating the did and did document creating the public private key with all the cryptographic and encryption algorithms behind the scenes. Here we are again using an AFJ or Ares JavaScript framework hyper ledger from a mobile SDK point of view as well. Okay I'm just getting started. Okay so here there are a few more use cases but right now we'll go with the railway. Later on this is again on our production side so you can also try on your own. Okay so I'll just get the national ID what I mentioned the first identifier. So this scan what we did right now is basically we are connecting to the national ID provider. We are connecting to one of the institute and this connection is nothing but an peer to peer connection. So when we say peer to peer in decentralized format we do not have to create account or store the details with them but we are just making a temporary connection again exchanging the public private keys to do the operations. We can disconnect our connection if we want to discontinue the further communication but still even after this discontinuation if the vcs are available with our wallet those are still used and verifiable throughout the throughout the lab. Okay connection is made you can see a did which is again did and details available let's get the national ID. I'll say for now it's a demo we'll say right now so we have added few details out here but you can also use some of the other information. Okay so right now on the mobile we have received the details which were added as a national ID. We have right now generated a random number for a national ID and we have to accept this particular VC we are accepting it and if you see the details now the VC is available in our wallet going back and now we can see there's one VC available in our credential so one VC is available and right now we just entered few details and got the VC but at least in India with Adharkard we have an XML format so that XML format can also be used and issue the other details or issue the VC from from an Adharkard database and similarly there can be X, Y, Z or there can be a multiple sources to get these respective VCs. Now after the national ID is there let's take the vaccination certificate here again as we go ahead and want to request for vaccination certificate a primary identity very VC should be available in place to receive the vaccination. So we do not so here because of we have an identity document or VC we are making sure that we issue the vaccination certificate of same individual without getting tampered the data within the flow. So here we do not have to enter our details but the vaccination certificate would be issued to the same individual and here the proof request which is given so if you see we receive the ID, national ID with these details and now we are sharing this information to the health institute or the vaccination institute so that they can fetch this information they can verify that I hold this VC with me and then the vaccination certificate will be issued to my wallet. If I fail the verification the vaccination will not be issued to me so I cannot modify these details because these are picked from the national ID which was which proof was given from my side basically I shared the details with the institute. These are the details a few of the dummy details what we have given or randomly generated and we accept the VC on our side so this we are accepting the very vaccination certificate in our wallet. Okay now we have received we can see it and here now we can see that there are two VCs available with us digital national ID and the vaccination certificate. Now going to a railway booking though this this use case is curated with all these basic VCs but you can have your customization based on the flow you want to achieve and the VC sequence you want to make it. Now let's go ahead and take the railway ticket again we are scanning and making in connection because here now we are making a connection with an railway institute or a railway reservation center to receive a ticket. As I mentioned the prerequisite will be vaccination certificate out here so railway is asking me to prove the vaccination certificate which I have once that VC is provided so here whenever we will proof request is asked and we say send basically institute is asking me the data but the data will be shared only when the consent is provided from my side so if you look at those principles consent is handled out here so without my consent the data will not be shared to any other institute now even the railway institute I shared the details with them they are not going to store it and somebody other one to use the same data they will again have to take consent from my side from my wallet so this should receive a railway ticket on my VC so now I have three VCs now as we have a national ID card vaccination railway ticket and same railway ticket can be used and when we go to railway station and during a journey the verification of the railway ticket can be done by a verifier entity and that can be achieved or even airport or any transport mode we go verification of the vaccination can be done in this format with an SSI format so here we are not in a position to modify anything in the vaccinations certificate again cryptographically verification is done so there is no scope to modify anything and same verification can be done so no temp this cannot be tempered and they can also verify who is issued and the trust factor would be available across the ecosystem now a quick use case would be passwordless login in the web to in the web to context we are now used to enter either username and password to log into a particular system when you enter a username and password our password is stored with the third party servers organizations and you you can easily know where we are signing up and who are storing our details during the sign up we are storing our password and everything and then whenever we want to do a login we basically enter the password and that that claim verification or assertion is done on the server side that's the general username password we have we do have some of the modified versions right now which Anusha mentioned let's say IDP flow or sign in with google sign in with password on some of the social media or any other website they do not hold it but actually still it is hold by third party entity with this use case now we hold a national ID in our wallet we should able to prove ourselves with this VC to any on the website for example if I want to log into a particular website they will that website will act as a verifier from that triangle they should able to ask me the proof and if I'm able to provide the proof successfully properly they are able to verify cryptographically cryptographically then only they will allow or redirect me to the respective website within within their ecosystem so let's let's catch on that particular flow so without entering password credentials or without giving a biometric details to the third party server I'm still able to authenticate myself on the websites I'll quickly scan so scanning is nothing but scanning is nothing but so these are the information which are getting so this particular website is asking me to provide these details and here we are asking these six five details but even though I have 10 details subjects in my VC they they can ask only for one or two attributes depending on for the use case what we saw let's say account opening they can out of the complete VC they can only ask two or three attributes from from it if I'm going to let's say go for a loan account opening from my bank statement they should only able to get the name and range of the salary if you talk about the zero knowledge proof concept they will not get the details from my side the exact salary but they will just get the range whether I'm meeting the expectation or meeting the requirement or not I'm just sharing this detail with the any particular verifier which is asking me so the details are shared with me from my side and they are doing a verification behind the scenes of cryptographic and verifiable credentials have been verified again this this actual institute is checking fetching the public key from the ledger checking the issuers trust factor as well as my VC factor so if it is successful I'm now logged in with the with the dashboard and from a demo point of view we have given this particular dashboard but it can be implemented to any website they want to that's it what we wanted to touch upon the demo side and we'll quickly go back here and more or less we are done so we have our product from blockchain lab credible dot id so this is a demo what you can also try on on your own this is the android app adia app which is an ssi wallet this is an ios iphone wallet you can install it and you can try this demo there are four use cases right now you can try these use cases on your own and learn ssi and if you have any doubts queries reach out to us on LinkedIn email we are welcome we would be happy to answer your questions or queries that's it from our side thanks thanks everyone thank you any questions on on call or queries thank you sunit and anusha for that wonderful session so I have one question like like you mentioned that the self sovereign identity is working on I mean it is used for decentralizing the existing centralized way of storing the identity like alpha so how which blockchain are you guys using for the solution so here here we are once okay it is not getting equal so here we are using a hyper ledger framework we are using aries javascript framework on mobile as well as from an organization point of view that's the underlying layer we are using from a ledger point of view we are using sovereign we have support for sovereign ledger we have support for indica ledger and we also have our own credible test network available so if any wants an institute want to have their own managed ledger that indie ledger can also be available and we are also working having an integration with the polygon ledger so all this schema credential definition did documents can also be published on the polygon ledger post this indication so it's pure mainly right now in hyper ledger framework what we are using thank you for that explanation and that's all from our side so just a wonderful session by sunit and anusha so thank you for joining us here at truandrum and this is us signing off the session and stopping the recording thank you