 Okay. Here we go. Welcome everyone. Thank you for joining us today. We'll get started in a couple of minutes. Welcome everyone. Thank you for joining us today. We'll get started in a couple of minutes. Thank you for joining us today. We're going to let a few more people filter in and then we'll get started in a minute or two. Okay. Let's go ahead and get started. Hi, my name is Karen O'Toni. I am a director of ecosystem at Hyperledger. And I am hosting our Hyperledger in depth webinar today. An hour with Pavicci on verifiable credentials and how they are bringing students and employees back to school while respecting privacy in this era of COVID that we are all in. Welcome Ashish, Mahesh, Jason, and Kevin, who will all be taking turns sharing more about this topic with you. Before we get started, I have a little bit of housekeeping to go over. So as with all meetings at Hyperledger, we follow an antitrust policy. You can find information about this on the Hyperledger.org website and I'll start our wiki. This session is being recorded currently. We are also live on YouTube so you can find this session to watch again on the events page of our website or also on our YouTube page as well. The slides will be available on that are presented today to download on our on the events page on our website. Now for how we do these sessions. Of course, I think at this point we're all quite experienced with the webinar format but we like to make it a little bit different we'd love to get your engagement and involvement throughout the session so you don't have to keep your questions until the very end. So please feel free to raise your hand. I'll be monitoring the chat and the q amp a box to see if you have any questions to raise your hand post something to chat for something q amp a box, wherever it is that you want to bring up a topic or ask for clarification on on what the privilege team is presenting. Please feel free to do so and I will be bringing you in during the session and if not we will definitely leave time at the end for questions as well. So without further ado, I will invite a sheesh to share his slides and the privilege team to get us started. Okay, thank you so much Karen. I will go ahead and share my screen, and we will start the presentation. Hope everyone can see. Yes, we got it. Thank you. Right. Go ahead Maesh. Yeah. Thanks, everyone for attending today and thanks Karen and hyper ledger for giving us the opportunity to present what we have been working on for more than a year. So I just wanted to kind of bring us kind of educate the audience here as to our involvement in this area, as well as the larger hyper ledger ecosystem. Just as an introduction to what for which he is was founded about eight years ago. Primarily, we are all a number of facts oracle folks who have been working on loyalty and CRM for a number of years. So out of our experience working in this area, especially in the loyalty space, we found that maybe there is a good application for using blockchain technologies in a loyalty context in order to create what we call a consortium loyalty where a set of cooperating companies would like to offer a loyalty program, and a great way to share the promotions the data and so on and so forth would be by using ledger started working on this project with a small prototype using Ethereum, and ultimately switched to fabric acid matured out and so we joined the hyper ledger fabric, the hyper ledger group as a general member in 2018, and I've been closely working with, you know, the whole hyper ledger ecosystem. So that was our first brush and we have continued to invest and build out that product. A year and a half ago, almost close to two years again, we met with ever name another active participant in the hyper ledger community, and we wanted to apply to new technologies to our solution space, which is using hyper ledger Indian networks to hold a credential data so when I mean credential data, the think about any loyalty application. So one of the big problems that we face today in this world is, you know, companies are collecting data about their customer and invariably it's stored in some database and it gets you know, so we thought maybe there is a smarter way to do this for the next generation of loyalty which is, why don't we hold the PII and credentials of a customer in, you know, in a verifiable credential and they can hold it in their phone in their phone wallet so to speak in a mobile app for example. And then we ask permission for from the customer. Hey, can I look at your month of birth so that I can give you a right offer. Can I look at your zip code for example, to give you the best offer this way we do not keep customers PII in any of CRM or loyalty system so that's where we started with our journey with hyper ledger Indian companies, talking to emmer ever name and using their stack to build out this particular concept. Of course, as everybody is familiar. Last year we, you know, year before we started to see the effects of COVID, and then we thought maybe this is again a good technology for us to use to solve this problem of holding a credential whether it be a test result, or it is COVID-19 vaccine, you know, credential. And so that's, that's what got us to build this product called Pravici pocket credit. So now we are also just to kind of lay out into the future. We are looking at what do we do with this in the larger context of health data. And we are kind of starting to work towards this idea that every person who is, you know, all of us have health insurance. Most of us have access to what they call as a health portal, would it be nice. When you log into your health portal that you can pick all the data that's most important to you your procedures your medications, of course your vaccinations, whatever else that you need and if you could potentially store that as a verifiable credential in a secure wallet. You be the transporter of information so as you go from doctor to doctor provider to provider, this might be the right way in which you control what is it that you store and what is it that you are willing to share, right. So that's kind of where we are going with our, with our product and working with some major, you know, there's some prospects who are interested in this idea and then we are exploring that with them. So just a set of tools and partners that we have worked with, like I said, we come from a history of working with Oracle and worked with Salesforce and so on and so forth. You'll see Salesforce later in the demonstration where we have built an add on to the Salesforce health cloud, you know, they have a product called vaccines. And so for the administration of vaccines and the distribution of vaccines. So basically straight out of that system, we have added pocket thread so that you can issue a credential straight out of there. And like I said, we have been a hyper ledger member for all these reasons, as we continue to consume more and more technologies from the hyper ledger staff. Next, Ashish. So what is pocket thread, right? It is issuing as I mean to this crowd who are quite familiar with, you know, possibly the verifiable credentials and we will go over all those details also, you know, because they may be others who are new to this area. But the idea is using the verifiable credential standard is to issue a privacy preserving credential that somebody can securely hold. This credential is signed by the authority that issued the credential, maybe the doctor's office which issued the vaccination or the health insurance or whosoever is the authority that issued the procedure or vaccination to you. They sign it, you store it and you present it only when you see it is appropriate to present it and through software you can verify that what you presented has not been tampered with. And they can make some, you know, judgments based on what is it that you have presented. So that's, in essence, the, you know, the three party concept in verifiable credentials and issuer, a holder and a verifier, we'll kind of expand on that later in the presentation. Next. So again, we are seeing, like Karen told in her introduction, a number of things are happening, right, people are, you know, asked to produce a test result, because they have to travel. Lots and lots of colleges, and even employers, even the federal government employees now have to get themselves vaccinated. And I want to just state on said that we are the technology providers. If you have to check the status of the COVID-19 vaccination of an employee for the welfare and that's what a company has determined is the right thing to do. I'm sure they are following all the other laws, which allow for people to opt out and make accommodations for them, right. So, so we are not here advocating one thing or the other. But if you do have to do, what is the best way to do it. And we believe that using verifiable credentials is probably the most, the least intrusive and the most privacy preserving for any employer or student or the public to be able to get access to this information and present it only with their own, you know, personal choice and not have somebody else share it with third parties without you being in the middle. So we want to squarely put the person in the middle of this equation. And that's what motivated us with this. So let's start with a quick introduction of how our product works. Rishish, go ahead. We can't hear Rishish. Yeah, sorry. I'm really sorry. Yeah. University admin. Yeah, let me hear it again. Yeah. Now that things are turning around, we want to make sure that everyone's health remains protected. We're all looking forward to being together again. So how can University administrators verify proof of vaccination, or at minimum a negative test result, while keeping the whole process easy, safe and confidential pocket cred bridges these needs by leveraging blockchain technology. People are first enabled to store information securely in a digital wallet. And when they need to confirm their health status within institution pocket cred performs the go between verification. Only the results of the check are stored. Everything else stays confidential in the personal wallet. It's easy to use, secure and gives people power over their information. For example, Angela here already got her COVID-19 vaccine along with her CDC card, but losing it is a real worry. Using pocket cred, she simply takes a photo of it and uploads it to the app. She's then issued a credential without information to a digital wallet. And Alex here, on the other hand, isn't vaccinated yet, but he did get a negative on a PCR test from the campus clinic. In just a few simple steps, the doctor fills out the digital certificate. All Alex has to do is scan the QR code and voila, you can carry his credential with him wherever he goes. Pocket credit is also easily integrated with any other health system, such as an electronic health record or immunization system. So with the health status of students and employees verified through pocket credit, the university health coordinators are confident the campus is as safe from the virus as they can make it. And whether it's entering class or going to the homecoming game, all it takes is a quick QR scan at the door to check to get on with the joy of being around other people again. Learn more at pocket cred.com. Thank you, Ashisha. So you heard a number of terms in there. What is the role of blockchain? Do you really need the blockchain? We'll answer all those questions as we go along because this is an evolving area. Hyperledger and associated organizations are actively involved in this and we are fortunate to be able to participate in those and be abreast of the latest developments and standards. So there are various stages to this. So what we have found in our work in this area is we kind of have to take the baby steps and then look towards a future where more sophisticated techniques can be applied. So today what we have is in our product two options, right? One is using FHIR, you know, I think it's called fast healthcare interoperability standard is the concept of smart health cards. And for example, the state of California, if you take a shot in the state, you can go in and request such a smart health card. What it is is it is a digitally signed credential which has the minimum amount of information. Your last name, your first name, your date of birth, that's it. And then of course the vaccine details is a dose one, dose two, lot number. When did you take it? And so optionally some information on where you took the shot, right? And the date you took the shot. So that's kind of what a smart health card is. It is a digitally signed document. We'll go into some details in there, which is essentially compressed and stored as a QR code. So you take this QR code, which tells who you are in at least the most minimal information with the date of birth and so on. And then on the, it also has the information about the actual vaccination record or records. And that's pretty much it. That's all there is to it so that a verifier can check who you are and they probably use a second type of verification if they need to verify that if it says Mahesh Balan, that you are Mahesh Balan. They could look at a driver's license or something at most. So that was the standard of the smart health card, which is also supported by the vaccine credentials initiative. So we'll talk about that and how we constructed our system to support that. And then I call option two as the full Monty, right, which is, this is where we use to ever name as our back end agent, and are able to completely use all the features and functions of the verifiable credential standard, whether it is, you know, communication securely from holder to issuer and holder to verifier through did calm, which is decentralized ID communication. The concept of verifiable presentations wherein you can even do a composite if you have multiple credentials you can take a few attributes from each of the credentials and presented selective disclosure again you can just minimize the amount of data that you present even though the credential might have all this information, you can only present part of the credential, zero knowledge proves wherein and this is, you know, I'm famous examples like your date of birth you don't have to disclose it you can just prove that you are about 21. All these options are available in the second concept of verifiable credentials for which we have built so we have built our product to support both kind of credentials. So let's go to the next key. So Jason, do you want to kind of talk about the first one which is the smart health cards. Sure. Yeah, I can do that. A smart health card, similar to other types of verifiable credentials has this model of an issuing organization needs the ability to digitally issue a credential and have it be signed so that it can be later tied back to them, and it needs to be able to be in a way where the patient or our customer can have a copy of it and they're ultimately the owner of the credential, and it needs to be done in such a way that the holder can then present the credential to a third party that can verify that the credential is valid that it hasn't tampered with and that it was indeed issued by the issue by the issuer. So a smart health card solves aims to solve this problem specifically when it comes to health care records, and more recently, specifically to try to provide a better way to receive and present a credential relating to COVID-19 vaccines or tests. So a smart health card is pretty similar to like a JWT uses a JWS versus a JSON web signature. So similar to a JWT, it has three parts, a header, a body and a signature. And in the body, we'll take a look at the next slide. You can see some of the claims that the issuer is signing. So you want to go to the next slide. So this is the body of the JWS. So it has the ISS claim, which says who issued it. So it's a URL to the issuer's website, and that is used to later resolve their public key, which is used during the verification process. There's the MBF, which is not before. So this says, since when is this credential valid? And the main claim VC is for a verifiable credential. So it has a sub property type, which lists the different types of credentials that are included in this. So you can see this is a smart health card and additional types would be COVID-19 vaccine or test. And then in the credential subject is where you find the actual FHIR records. So there's a bundle which has multiple entries. Typically the first entry is a FHIR patient record, which has minimal data about the patient, usually their name and birth date. And then subsequent entries would be like the FHIR immunization record, which has minimal details about the immunization. So this is the payload that is signed by the issuer and then transferred to the folder. Do you want to go to the next slide? So, like I said, there's JWS is three parts, the header payload and the signature. So the header needs to include the algorithm ES 256. And because ultimately these are going to be displayed as QR codes, they're compressed using the zip deflate method. So that is included in the header. And issuer may have many keys that they use to sign credentials. So there's also a header, KID, which includes basically the ID of the issuers to specify which key was used to sign the record. And then in the payload we see a compressed version of the data from the previous slide. And that's where all of the FHIR records are stored. So that's pretty much the format of smart health cards. And the goal is to provide an open standard that uses a bunch of existing specifications to enable the most interoperability between healthcare data. So a lot of these specifications have been around for a long time with JSON web signatures and encryption keys and stuff. So turn it over to Kevin. Yeah, Kevin, please go ahead. So, we're going to do an example here of a use case. In this case, you have somebody who goes and they can go get their information from their insurance provider. And the insurance provider is going to present this now as a verifiable credential. And then the user is going to be able to send this to another provider. So this is a much better use case as opposed to kind of what you see today. Imagine every time you go to the doctor, especially a new doctor, and you know all the paperwork you have to fill out where you're saying, I had this operation on this date and I have these, you know, all of these different health records and I at least I can never remember exactly what dates or what the exact medication name was or anything like that. So this can be one beneficial way to make it to where your records are held by you. And it's a lot more secure and easier to transfer this information here so she should want to go ahead and play this video. So, and thank you for your interest in pocket cred. With the establishment of the interoperability and patient access final rule health systems are now required to provide patients access to their health information. The goal of this law is to liberate patient data with patient access API, while simultaneously encouraging seamless data exchange from pair to pair. And this way it offers a solution with a power of blockchain technology pocket could gives users the ability to securely store digital credentials from electronic health records systems in a mobile wallet. In this way, the patient gains full ownership of their health information, so that it is organized and accessible in seconds. Additionally, QR code technology simplifies the data sharing and verification process into one simple step. In this video, I will provide a brief overview of pocket cred features. Let's log in as a member Bell on the homepage we can see the members details. This includes information like their primary physician and health contacts for easy reference, selecting procedures from the bottom and you displays past procedures that Bell underwent with just a tap of a button. She can easily store the data as a digitally signed credential locally on her mobile device. This provides a unique QR code for quick and discrete sharing. So I'm both visiting a new doctor, all she needs to do is present the QR code with the relevant data for the doctor to scan. With this, the digital credential is successfully shared with the doctor and verified to ensure it has not been tampered with. This concludes the demo. Thank you. Alright, thank you for that. And one slide too far. There we go. And we've made more progress on this app. We've we've done more integrations now we have. We can do the immunization records. And so we're making more progress on that she she want to go to the next slide. There we go. Okay. And so the technology used in this. I mean, if there's anybody that's well versed in tech right now with cryptography you're probably recognizing that this is fairly simple stuff. The issuer can sign a health card verifiable credential with a signing key so use your private key and you just sign the data the data comes in a regular JSON format as we showed in that smart health card. So if you're a public key at this dot slash dot well known slash jwks dot JSON, that's becoming a pretty big standardized way of displaying your, your key stores publicly. Essentially use, you know, inside this credential you say, here's who the issuer is, you can go to this issuer's website slash this, and it'll bring up all of their keys so you can look at the public key and you can validate that this credential was indeed signed with one of those keys. And that's important to see that, you know, if it says example.com slash this, and you find that key and the signatures match that you know that example.com is responsible for signing it. Also verifiers use the public key to verify issuer signatures on health cards. So, this is the first step this is the basic structure for issuing credentials and then verifying that indeed you know exactly who issued this. And that the information hasn't been tampered with. Of course, the cryptography has been able to do this for a while this isn't a huge leap or anything like that, which is why we push forward, and we're actually introducing new tech beyond that. You want to go to the next slide. Okay, and then I don't remember if Mahesh or a she's just wanting to take over here but please go ahead. And just kind of to summarize, you know what you saw so far is the use of the smart health card technology right fairly straightforward. There's also, you know, Kevin pointed out at the very end you know, how do you discover the public key there's a way to discover the public key, but how do you trust the person that issued the public key right. You need a trust network on top of that. Again, baby steps are being taken. The vaccine credential initiative, for example, publishes a set of well known public keys you can go and look for it it's just a JSON file that they have vetted all the public keys in there to say hey this is, you know, this is Boston Medical and this is so on and so forth. So that's step number one, step number two is to use something like the sovereign network, right hyperledger indie. And what we ultimately need is a network of networks, right, because there's not just one network sovereign is a very popular one very familiar to this audience. But there are others IBM has one actually they're built on top of fabric, not on top of it. So there are many emerging networks, which are both what we call trust networks right, how do we make sure that the public key that somebody says that they gave is from a reputable company and they are doing what they are doing right or anybody can just publish a public key and then sign any kind of document and it will be acceptable. So, so I know Claudine had a question, you know, in the video we showed how do we you know for example somebody providing, you know, the copy of the CVC card which can easily be, you know, duplicated and so on we'll address that you know that's that is a huge issue today. And there are some mitigations for that, but we'll address that a little bit later but the first one is the one of the trust network right so anyway. The, the, this is the full Monty that I keep that I talked about which is with thanks to the technology built by Evernem agents. So we have built on top of that. We are able to offer us an alternative solution, wherein a verifiable credential is digitally signed not with the elliptic key cryptography 256 that you just showed where you just have a digital signature for the whole document, but there's more sophisticated cryptography, such as the Kamanish Lysian-Skaya signature or CL signature or the more evolving which is the BDS plus signatures, by which it is possible for us to only present one attribute at a time and even do composite so suppose you have on your wallet multiple credentials you can do a composite attribute pulling something from your driver's digital driver's license and something from your COVID-19, you know, vaccine credential and you can combine all these things right, and you can even do zero knowledge proves wherein you say hey my age is about 21 that's all you need to know. So all those complete set of features are made available in what we call the second version of our product and she should go ahead to the next slide. So here I kind of skipped over the details of the previous slide so that I can cover it here. So it is the same three-party interaction that is an issuer who digitally signs a digital document but the digital signature here can be much more sophisticated using a slightly higher level of cryptography. The holder holds the credential, the communication between the issuer and holder users did come so that there is a secure channel established by an initial exchange of keys, you know, public private key cryptography again, and you can transmit the information securely to the holder. Same thing holder first establishes did come with a verifier secure communication channel verifier can ask whatever questions that they want to ask the holder optionally can say yes I'm ready to answer this but the holder like I said can set up a verifiable presentation that can be a composite of multiple things it can hold zero knowledge proofs and it can even dictate the terms in which the verifier can use this data. For example, it can specify the terms of use and say no archival please which means the verifier need to respect this. So, so this is in my mind this is what the, you know, the recently published good health pass initiative recommends, you know, again stages, but recommends this level of technologies where we all want to be, which will allow us to do this presentation. Again, remember in the previous smart health thought example, we could only do, you know, like a QR code with some minimum amount of data because the QR code itself is limited, but in this kind of technology, you could have multiple credentials, because again the verifiable presentation can be made in such a way that it is happening over did come it's just not reading a QR code, you know, the QR code in this concept is just used to establish the did come communications. So it's, we can have a sophisticated exchange of credentials using this technology. So again, what is the role of the verifiable data registry so there are the three, you know parties involved. The fourth party is the verifiable data registry and the data registry in our case is sovereign. And so that way, a public key can be registered with sovereign, you'll also see quickly in the in our final technical presentation as to how we can create schemas. And the schemas themselves are also stored in the registry so that you can have a much richer interaction by which of course not only can the public key be verified by looking at indie or sovereign which is the implementation of indie. But also the schema definitions can be retrieved from there I mean there are multiple intermediate standards to I don't want to go into every one of them, like, you know, link the data signatures and so on and so forth. But in essence, the verifiable data registry, which is the blockchain can be used for these two purposes remember no actual PII data no credential data is ever stored in the data registry it's very important when we talk about using blockchain technology for this, we need to understand that next machine. So how does this, you know, I'll just go over the verification concept right. So you have a credential or a set of credentials stored in your wallet, and we'll show you this here shortly, and you first read a QR code from the verifier that is nearly to establish did come from the verifier says hey talk to me this did exchange secure channel is, you know, established, and then the verifier says hey show me your covert 19 credential information right. So, on the holder side you make a verifiable presentation, the presentation is verified, the public key is checked against the blockchain, the schema is checked against the blockchain, and now, you know, you're able to verify to do and then the verifier needs to follow the protocol specified by the presenter, which say, based on their terms of use. And if he says no archival all you can just say is a presenter checkmark which says yes, this looks good or no or whatever the case may be. And that's all they can do. So, to us, this is the most, you know, secure way of conveying this type of information. Next. Let me kind of show you this end to end flow in pocket right as to what I talked about is built based on ever in the media. Go ahead. Hello, today I will be giving an overview of the pocket credit application and two easy steps. I will demonstrate the credential issuance process, as well as how the information can be verified by a third party. In this scenario, a patient John Doe has just received a COVID-19 test, and is requesting a digital certificate from his doctor or nurse. The left hand view displays the doctor or nurses screen, while the right hand side shows John's mobile device. To begin the process, the doctor or nurse navigates to the issue credential page, which generates a form for the doctor or nurse to complete. I will fill in the credential details here. However, pocket credit can be integrated with any external health system, allowing data to flow in from an EHR or IIS, such as the Salesforce vaccine cloud. Selecting issue credential generates a unique QR code for the patient to scan using their mobile wallet. Now that the connection has been established, the patient may review and accept the credential. The mobile wallet utilizes the user's preferred authorization method, for example, password or fingerprint scanning for an added layer of security. Now John may take his mobile device to a third party, for example, airport or sporting event that may require proof of a negative COVID-19 test. For users, the third party's view is now displayed on the left hand side. To verify John's credentials, the third party simply navigates to the URL that holds the proof request QR code. In this example, the base URL is app.pocketcred.com slash verifier and COVID test specifies the proof request type. This process does not require any login, so the general public may access this page. This empowers individuals to request COVID test verification for their own peace of mind. When John scans a QR code, he receives a notification of the proof request where he can review the information that will be sent to the third party. John approves the proof request by selecting share attributes. The information is stored on the verifier. It simply checks the information, which returns a success or fail message. Now that John has completed the verification process, he is ready to enjoy the event, and the verifier can test the next person by selecting start over. This concludes the demo. Thank you. Go ahead, Ashish. Yes, so as Chieko explained that, you know, we can integrate this application, PocketCred application to any of the EHR systems, and we have done it for Salesforce Health and Vaccine Cloud, where, you know, we are directly issuing digital credentials for a vaccine from a vaccination application. And we are doing this using the Avername Agents in the background to issue the verifiable credentials. So I can quickly show you a demo, which will explain this in more details. So I'm going to show you how the PocketCred application integrates with Salesforce Work.com. Salesforce Work.com is an electronic health record system released by Salesforce to specifically address the management of vaccines, tests, and contact tracing for COVID. In this scenario, a patient has just received an immunization and are requesting a digital certificate from their doctor or nurse. The patient's mobile device is displayed on the right hand side of the screen, while the medical professional's view is displayed on the left. In the Salesforce Work.com application, the doctor or nurse finds the immunization that the patient would like a copy of and selects issue credentials. This generates a QR code for the patient to scan using their mobile wallet app. We are using Evernames Connect.me app. The patient will receive a notification of the connection request. Once the patient has accepted the connection request, the immunization record becomes available to the patient as a verifiable credential. The credentials issued directly from Salesforce, allowing for a seamless integration with PocketCred. Now the patient may present the credential on their mobile device to a third party, for example, airline or sporting events that may require proof of immunization. PocketCred is a product built by Proveechi and will be available in the Salesforce App Exchange. Thank you. Yeah, so just to add that this product is already available in Salesforce App Exchange and can be used as a managed package along with the Salesforce Health and Vaccine Cloud to issue the digital credentials for the vaccine. All right. So this next one, I was, you know, I was going to have Jason just walk through some of the details of schemas and proofs, but I don't want to miss out on some important things, especially some questions that typically come up. So let's do this. We have 15 minutes left. If let me cover the next few slides quickly. If there are not too many questions, we'll come back and play this video. Of course, all these videos are available publicly in our website. It will be available. Links will be available from this PowerPoint presentation, which, you know, Hyperledger folks will upload. So there is no issue. We can always come back to this. So quickly let's go over the next one, just to in the interest of time, Ashish. Thank you. Yeah. So let's talk about challenges, right? So one of the first challenges that we, you know, working in this area with the number of prospects is, you know, while it's great to talk about issuing a credential when you get the shot, you know that that is just not the focus right now. People are trying to get as many shots as possible. Maybe in the next few rounds when this is the new normal wherein just like the flu shot, we are going to get this COVID chart every year or a booster or something like that. They already talked about a booster now. Then it may be possible. So what do we do right now, right? So there is a, you know, a whole bunch of things that are getting done. You know, employers are, you know, and the schools, for example, you know, I know ASU right here. If you want to disclose your vaccine information, they ask you to upload some proof of vaccination. Yes, those things can be fake, but I guess they make a determination, you know, based on you and employers are doing the same. Some other employers are saying, hey, we'll give you some, you know, some kind of a deal, you know, we'll give you $100 or gift card or whatever. If you take the vaccination, either they themselves conduct the vaccination and they therefore have some proof of vaccination with them, or people submit some record and they are able to claim their reward. All these things happen, right? And so basically, in these systems, it comes to the person, the holder providing some information based on which somebody like an employer or somebody else makes a data or a college makes a determination. Yes, this looks genuine enough. Yes, it's possible that they faked it. I guess they have consequences to that if they later find out and so on. But the bottom line is that's the reality today. Issuing it directly seems to be a very, very difficult problem because this technology has to be seamless and built at the point of consumption, maybe for the next round. So we find that that use case, even though it's nice to show, doesn't really work, right? So Ashish, sorry, go to the previous slide again, I just wanted to. So the next one is retrieving vaccine data. There is a rule and I won't go into the details, but the bottom line is at least as far as your COVID-19 vaccine goes, it has to be reported to the state immunization system. At least that is the rule. It's not true for all the other vaccines, but for COVID-19, since the federal government paid for it, they made that into a rule. So every provider ultimately supplies this, but the state immunization information systems are not all up to speed. They are not designed for this onslaught of information. So they are at various stages of development to allow third parties like us to allow us to interact with them via API so that you can identify yourself, the records can be matched, which is a whole separate set of issues that come with that. And then hopefully you will be able to do this. Some states like California have done this. We showed you URL upfront where you can get a smart health card if you are in the state of California provided that your demographics match. That is a separate problem in itself, which will require some more efforts. For example, the state might have to run a call center to do this and so on and so forth, right? So that's a little bit of a more complex issue that also needs to be resolved. I think if this is here to stay with us over the years, these problems will be resolved. The other last thing is your health records are actually, you know, even your immunization record, if you have an insurance will ultimately land up in the EHR systems of the insurance provider because they are actually not paying for the vaccine, but they are paying for the administration. So someday it will be there and then the use case that we showed you initially wherein most people have a patient portal where they use some kind of, you know, multiple authentication techniques, you know, by which you are, you know, ATP and so on and so forth, so that you can authenticate yourself as the real person to that website, your member portal, and hopefully from there you can pull vaccinations, you can pull your procedures just like what Kevin talked about, right? So that might be the actual real workable solution as we go into the future. So it's just a matter of you getting in there, pulling that record, saving it and then from then on you will be able to present it. Then the question is, what about the vaccine record itself? And this is where the Good Health Pass initiative, you know, for example, came up with a list of recommendations. The smart health card is kind of a simpler working version that we showed. There are others, the IATA travel pass is actually built on the Evernum stack. So there is a host of them and hopefully we'll all converge to one or two or three of these standards. And like I said, even within that there is, you know, what is the cryptography that is used, you know, do you use selective disclosure? All these things will kind of mature. We are still in early stages. And then I talked about the whole issue of public key discovery, trust frameworks need to exist. And then we need to have the concept of a universal verifier, so that by using the DIT method, sovereign, we'll be able to go to the sovereign network and some other network, you'll be able to go to that and the IATA network. And if it's VCI, it is just a flat file or a flat database. So hopefully we'll have a universal verifier that is being built. And I know, for example, the CCI chief architect John, who is very much part of the whole TOIP and the Hyperledger environment is, and his team are trying to get some standardization going in here. And lastly, the very last thing is what is the revenue model, right? How do we charge? Of course, we want to make the credentials free for public and the patients and so on and so forth. So that part I think is the way it's going to work. But what about, you know, maybe the verifiers, if you have an interest in verifying this, an employer or a university, maybe we can charge for building a verifier. Because what really, if you have to get a thousand students in, how do we make sure that it moves really fast, right? So that's something that we have to think about. So the verifier is just not verifying something, but probably kicking off a workflow like opening a door, notifying somebody doing something, right? So that's where companies like us come into play. We can work closely with an employer or a university or whosoever and build a verifier that kind of integrates it to their workflow. So I'll stop there and I think there is another question. Yeah. I think she has a couple of questions and I wanted to invite Claudine to maybe come off of mute. If she's interested to discuss maybe her questions. If not, I'm happy to read them out for her. Claudine, would you like to come off mute? Okay, she can't. Okay. So her first question related to whether or not when the health immunization card is scanned, if it converts to W3C credential, she asks, is the holder in effect acting as the trusted issuer and in that case converting from tangible source to digital and how can one assure the authenticity under that circumstance? And then I'll go to the second question since it's related. So she says that she understands the credential insurance and holding part, but what's not clear are the various and limitless scenarios where the holder slash verifier pair is associated with verifications. One holder and many verifiers such as a bank and airline, a sports facility with different data requirements. So are there specific schemas needed to be developed for each verifier holder pair? Would there be a standard verification template where the verifier can select data attributes from a library, generate a QR code, connect with the holder, and then hope the holder has the information requested to respond with? All superb questions, right? The first one I kind of addressed before for Claudine, which is, yes, in a perfect world, we should be having the person should be able to authenticate themselves against a state immunization system via and then that is the guarantee, you know, you typically the authentication now is you put in your first name, last name, your date of birth and your phone number and if it matches your COVID-19 record in the state immunization system, then, you know, you get a user ID and password, then you can log in, you know, there is two factor authentication, and then ultimately you are able to retrieve your record and store it. That's the ideal situation Claudine that there is or better yet, if it is fast enough and efficient enough when you take the shot in your doctor's office or wherever or take a test, we will issue you. Okay, so that's, those are the true answers but the real world answers is people are submitting some kind of proof, others are kind of looking it over and using your trust network, right, to say, yes, your proof seems to be somewhat okay. I know CDC cards can be faked, but you know, you have consequences for lying, right, whether you're an employer or a student, right, so that's where the world is today, you know, and we'll hopefully evolve to further verification as we go down the tube. The second question that you had is a very good one about the standardization of these formats because if you have just like a verifier, how in the world do you know, you know, what questions to ask and what that person holds, right. So again, that's where the BCI, smart health card, the whole, you know, the schema itself is laid out with the options, you know, certain optional fields, certain required fields, along with principles of data minimization saying hey, you cannot put random things about the person into this. For example, the smart health card specification clearly says you cannot use this as an identity. You can only use it to cross reference this last name, first name, date of birth and phone number or something like that with some other identification system. So, so there are in short, in every area, the good health pass initiative again, as spent quite a bit of time documenting what a schema should look like so it is case by case for COVID-19 vaccine for COVID-19 test proof of antibodies so these are the three areas that they're trying to standardize the schema and in a perfect world. Those schemas should be well published and any verifier should take into account that particular thing so that's where we are today technologically and terms of standards, but we are all evolving towards hopefully a better world. Awesome. Thank you. And I actually have a question for you myself. So I live in New York City. New York State has this Excelsior pass and it's actually, we are actually being required to show proof of vaccination in order to be able to go indoors in many locations. I just actually saw a notification earlier today that you know we have the Governor's Island, it's a popular place to go and visit and anywhere you go in there you're going to have to show proof whether with your card or using the Excelsior pass which is on the phone. And I was curious if you wanted to comment on that how similar or different the Excelsior pass is from what it is that you've developed. Right, so they're all approximately the same technology it's just different levels of maturity right in a, so I believe the Excelsior pass does conform to the smart healthcare standards, I'm not 100% sure which is very similar to what we showed in the very first piece of our presentation, which is it's kind of a more simplistic approach, which is a generator QR code so that you can present either a paper credential, or you can present it as a digital today I mean like on a phone right. The more the second one which is the one that good health pass and others are ultimately driving towards a more sophisticated one where you are not exchanging the, you know, you can just print it out and take it right that QR code is in that context is very different. It is actually a verifiable credential which is stored in digital form and signed, and therefore that is the more, you know, robust one, we will get there someday. So, each of the these technologies that is this that's the full spectrum, you know it's either a very simple QR code or it's the most sophisticated did come kind of thing. I know IBM's technology, which is the one that is behind Excelsior pass, they have the capability to do everything, but here's that would be a great example to point out where everybody needs to come together right IBM for example uses a hyperledger fabric based blockchain for the resolution of public keys, which is a little different than what sovereign does right so. So we are all at using the same underlying verifiable credential technology at the bottom line, when it comes to the credential itself it conforms to the VC model but the VC model does not say what attributes you need to use and so on it just gives the framework. So we are all on the framework we are all trying to agree what is the you know so that each of us become interoperable that will take a little time. So, yeah, that's kind of a long winded answer to say yes, and a little bit of no. Well, thank you so much to the privy team, this has been a really fascinating presentation, and so incredibly relevant to what we are all going through and living through and needing to use, you know some sort of verification of our vaccination status. So thank you so much, everybody for joining us today. Again, you'll find the slides on our events page. You can also find this session on our YouTube channel as well. And we do have more of these sessions coming up so on September 8 we have Oracle and on September 15 tallest, and I wanted to also get the slide to change. Draw anyone to look at the sessions from our global forum back in June. We have such great information. So many great use cases and examples like what we heard today from Previci. In addition to our regular member webinar series again you can find all of these on our YouTube page as well. And as always the hyperledger community is open and welcome for anyone to get involved. There's many ways in which you can contribute to the community, leverage our technologies join our various work groups and find what you're interested in learning about. Thank you so much again and everyone have a wonderful day. Thank you, Kevin. Thank you.