Rethinking Identity: A Journey from Hope-based Authentication to Identity-based Authentication

Michael Engle:

The title of this here, as you can see, is a journey from what we call hope-based authentication to identity based authentication. My next slide's going to talk very specifically about this hope-based authentication or we're calling HBA. Everything in cyber security needs a good three-letter acronym or maybe four-letter. Despite us all having worked in identity, for me it's been 20, 25 years, there's not much identity in identity-based authentication. In your IAM platform, the I is missing. A lot of that comes down to because we've been stuck with as, as Vickison and Anish bought up many times, the password problem. It's not just a password problem, it's an identity problem.

What we're doing when we ask our users to use [inaudible 00:00:53] password is we're asking them to authenticate with hope. Username plus password equals hope-based authentication. And very specifically, when you give a user using a password to get into your system, you hope that first they can remember it. How many passwords have you forgotten? You hope that they've created a strong password. People share passwords. They use the same password everywhere. You hope that the password chains that you make them do every 75 days doesn't mess them up with all your complex security requirements and lock them out. And then, because passwords aren't good enough, you hope that they can figure out your 2FA or MFA system. Then, it gets better because you have to hope that the bad guys haven't stolen a central database and crack the hashes. Then, you have to hope that a man in the middle attack hasn't happened, or somebody has socially engineered the password or otherwise fished it right out of their hands.

That's where, coming back to that quote from James Cameron, very specifically, when it comes to authentication, we've been relying on hope as a strategy. Hoping that the user names and passwords don't suffer from all of these problems. So, to mitigate it, what have we done as an industry? The cyber security industry has created billions of dollars of products and services. This slide is one of those logo vomit slides that shows all the number of cyber security players in the identity space. And you guys know this well. There's so many vendors in the space that it's hard to know which way is up or down when you're talking to a vendor. The reality is over 50% of these companies exist due to the insecurity of using usernames and passwords to guess who's coming into your systems.

I like to call a lot of these companies, password mitigation companies, and they fall into a bunch of different categories that we're all familiar with. For example, you have, of course, the username and password itself. We've been dealing with that for 40 years. But since that's not good enough, we add expiration and complex password requirements, hoping that the password gets a little bit better. Then, we'll sprinkle on some 2FA which includes email, SMS messages, one-time passwords, single token generators. Then, 2FA might not be enough, so we'll add some MFA. More factors to 2FA. We'll do risk-based authentication. We'll do knowledge-based authentication. We'll add then single sign-on to make the passing of a token a little easier than the passing of a password. Then, we have password managers which have popped up, which put all of your big password around your little passwords. One big password. Password list solutions are now starting to get popular and they'll do things like exchange of pin or a key some of the time.

Everybody on this call should be familiar with FIDO. It is a great industry standard that has emerged. This allows you to replace a password with an encryption key on a specific device. Part of FIDO, you have WebAuthn, which works with browsers and USB keys. Of course, over the past 10 plus years, we've introduced certain types of biometrics on top of a workstation. For example, fingerprint scanners, face scanners from a camera, et cetera. But why? Just to help strengthen a username or password.
We all know how bad the problem is but it's good to have a little bit of affirmation and to know that this is a place where the bad guys are spending their time and effort. Rather than show you a whole bunch of headlines of about how all these different systems have been hacked, there's plenty of them. I think there's one that comes out every day. I selected two key data points from the most recent Verizon data breach investigations report. If you haven't seen this report, you need to download it and share it with your peers. It is the global standard for hacking trends in the industry. It comes out every year. It collects data from 80 countries, millions of endpoints, and they analyze thousands of hacks that have happened.

One of the most important points in the report is about malware, which gets installed in your machines. Specifically, malware's main goal these days is to collect those, and they have this very prominently in the report, they call them those sweet-sweet credentials. This goal of password dumper taking the top spot amongst breach malware varieties is now at the top of the list.

The second data point from the Verizon report observes how the hacking falls into three categories. The categories are hacks that use stolen or brute force credentials, those that exploit vulnerabilities, and those that use back doors. And the punchline here is over 80% of hacking breaches involve brute force or the use of lost or stolen credential. That's 80%. And you see people using this statistic all over the place. This is the report where that comes from, and it just validates that this is a place where CISOs and cybersecurity practitioners need to spend time to fix the problem. It's a well worth effort to shore this stuff up.

And so, as I mentioned on my prior slide, we are introducing 2FA and MFA in the industry. We've been doing it for years. However, this is just a layer. It's not the answer to fixing the identity problem and there have been some very high profile tax recently how 2FA's been compromised. Most notably Jack Dorsey, the CEO of Twitter had his credential and his 2FA stolen. Incredibly embarrassing and, of course, risky.

The FBI is also warning the popularity of four types of 2FA theft attacks that are going on the rise. And you guys know how this stuff can be man in the middle. As I stated before, these 2FA layers are just other forms of hope and they are exasperating your users and they're expensive to maintain and purchase. So it's time to get rid of the credential, which closes this vector a hundred percent of the time if you do it right. I'm not talking about going passwordless. I'm talking about going credential-less, getting rid of both the username and the password in the external MFA systems, and migrating from, wait for it, HBA to IBA. All right, you take that term, share it with your friends.

Let's get back to what is identity. Again, there is no identity in most IAM systems. And so, your real person is everything that makes you up: your appearance, your demeanor, your language, what you do for a living. But your identity is how you prove yourself to others. In the physical world, it's established as you interact with society. When you're born, you get a birth certificate. That is the first credential that you get. Then, you migrate the student IDs and then you migrate the driver's licenses, passports, and now you have some real credentials to identify yourself into the real world.

My 11-year old son has no way to identify himself other than a birth certificate. So you'll notice that there's no username or password involved in this form of authentication and there's very little need for hope. When you will walk into a bank or a customs checkpoint, you present your credential. It's trusted, it has security built into it, and you move about your business. And think about how this does not parallel the digital world and our IAM systems. If we relied on a username and a password and 2FA every time we got pulled over by a police officer or for speeding, think about how much of the disaster that would be. Instead, we have real credentials that are given to us.

So let's introduce the concept of real credentials in the digital world. There's a whole bunch of standards that exist around this that many people are just starting to get familiar with, but they've actually been around for a few years. The two areas where identity standards are getting very prominent and popular are identity proofing and identity usage. You'll find that lots of companies are just starting to use bits and pieces of this language in how they describe their products. For example, many MFA companies will say their product is NIST authentication assurance level AAL2. I'm going to talk about that standard specifically in a minute. They're authenticating strongly, but they're not dealing with the identity component.

My point in all this is that there are key pieces in an identity strategy that exist out there and are standards-based. It lets you know who is really at the other end of a digital connection. We're not the only one saying this. We didn't make this stuff up. You're seeing this language come out of government RFPs and also the big boys like Microsoft and IBM have been all over a concept called decentralized identifiers that I'll be introducing here in a minute for a few years. They're all trying to figure out how to work it into their IAM solutions, but they haven't tied it together in the way that we have.

Here's two examples from the FIDO Alliance and Gartner. FIDO has become one of the most known technologies for using keys instead of passwords. They don't introduce identity. I'll cover that right here in a minute. They basically turn your username and password into secrets that you store on a secure hardware device like a UBI key. This obviously has many benefits over a username and password. It's more secure, little less friction. But then again, this authentication scheme does not actually identify the user.

In a recent paper this April, the FIDO Alliance started introducing the topic of identity in the identity and access management process, which is kind of ironic. You can see here, the three pillars of IAM identification authentication and authorization. The FIDO covers the A here in the middle and they prominently call that out, but not the full part of the EID scheme. Other organizations like Gartner are also acknowledging this as well. This is a FIDO quote, that FIDO WebAuthN does not provide any details about how the user can be identified.
As I mentioned, Gartner is also using this language in a lot of their research and papers. They're saying the same thing. In this recent paper, they acknowledge that this whole identity thing is actually pretty important. Those aren't their exact words. I might be paraphrasing a little bit. They stated that there is a growing trend toward orchestrating identity proofing.

Let's take a look at how you take these standards and apply them to an IAM stack for both your workforce and your customers. I know we're here to talk about password list and this is where this all comes into play. When you tie identity together, your flow will look something like this. The first thing that you'll do is enroll an identity. And more specifically, you let someone enroll their own digital identity into an identity vault or safe via an app on their smartphone. Everything in an identity safe is highly encrypted and the user's private key stays in the secure enclave on their phone. This enrollment process that we do follows the NIST 800-063-3 A standard for identity proofing. In Europe, there's a similar standard called EIDAS, and almost every country follows these principles in some fashion and many of them come back and reference this NIST standard.

So, data storage in this model is done via W3C decentralized identifiers onto a private distributed ledger or blockchain backend. As you all know, blockchain and distributed ledgers are immutable. They're highly secure. We've designed ours in a way to support rapid transaction execution. Again, this isn't a public blockchain, but this can only be achieved with this type of technology for storage of data in a safe way. No data in what you're seeing and anything I'm showing you is enrolled in a central database. It stays with the user and under the user's control.

The second thing that an identity-based authentication system can do is allow the user to be authenticated across any number of user settings using identity tied back to their real biometrics. In any situation where it's important, you can ascertain, is this person really who they claim to be? Not, do they have a username, password, an MFA that matches something that was set up two years ago. The use cases here are endless and I'll cover them in a minute, but it could be getting into a building going through an airport, logging into a website, logging into a Windows workstation, et cetera, with your identity. And it's all contactless as well.

The third thing that we do is provide a requesting party with credentials. This standard has gotten a lot of traction recently given a COVID situation and how people can have a COVID clear credential. I'll be touching on that as we wrap up towards the end. But the idea of a verifiable credential, isn't just who this person is, but it's, do they have a certain attribute to them? For example, do they have a degree from a university? Or do they have, in Vic's example, a certificate from the elite CISO organization? And you can give this to somebody in a cryptographically secure and digitally-signed way that does not require you to go back and ask the issuing authority if it's valid or not. I'll show you an example of that, as I mentioned.

The point in all of this that is extremely important, is everything that happens inside this type of architected system requires explicit user consent. The users involved in the enrollment, the sign up, every time you authenticate or every time you verify a credential, the user must use consent because they have control of the private key. This is a very critical design and operating feature. It's also in line with all the evolving compliance requirements relating around PII. Your GDPR, your CCPAs, et cetera.

The final point in all this is the reason why we are all here. It's to solve problems. There's all kinds of corporate use cases for better access to physical and digital systems, logging into logical resources. There's also a whole bunch of consumer facing benefits in both a closed, excuse me, and a federated model to help facilitate authentication and give the user a better experience. We'll be getting into this here.

Let's take a look at how this can be introduced into an organization like yours. I'll show a few components and how they interact with each other so you can see how the moving parts come. You'll start with the digital safer wallet or a mobile authenticator, like I mentioned on the prior slide. This is the interface with the user. It handles the biometrics, the key utilization, and how the user interacts with a third party system for all the consent and credential sharing that I mentioned. The features in a modern smartphone are what are the real enabler here today. They enable the secure storage of the key into the enclave of the trusted store, as well as give you a very strong biometric that every smartphone user is already used to. Because of Apple and Google and Samsung, et cetera, users have gotten very comfortable with interfacing with their phone for a biometric capability.

Next, an identity gateway facilitates the communication between the user and the system on the other side. This is commonly called an API gateway or an orchestrator. If your passwordless identity system is designed properly, it should have no visibility into user data that's exchanged after enrollment. This is called a triple blind conversation. It's in one of the key principles of these types of systems as well when they're designed pro properly.

And with cloud being on everyone's mind, you need the option to run this as a service in your provider's cloud or in your own cloud infrastructure, even on prem. It should be containerized, Kubernetes based, et cetera, with those types of technologies. If the service does run in the cloud, they'll typically have a lightweight agent that goes on prem that's a proxy between the user and some internal systems. And of course, you should not need to put any type of box in a DMZ or open firewall ports for this type of technology to be used. Runaway, if you have somebody asking you to do those types of things.
Of course, at the end of the day, you're still sending some type of key or user data to a requesting system or person. This data should be stored in a place where nobody, not even a CIS admin or a bad guy with the most evil of intent, can get to it. That's why blockchain is the perfect storage mechanism for identity-related functions. In addition to storage, it also provides an immutable ledger of all the enrollment and the authentication activities. This helps meet a lot of the banking and other industry requirements to make sure that you have a clear audit trail of everything that's happened in your system. Then, of course, the public private key design of blockchain always keeps the user in control of their data. I'll probably mention that 10 times as we move forward, but it's very important.

Now, as the user authentication completes its journey, it will touch the target system. Internal systems will communicate with the identity gateway or that orchestrator via typically an existing proxy infrastructure, your blue coats or whatever. And very little infrastructure change should be needed to make this happen. Now, as you can see, the user's identity safe can communicate with the target system. For example, a Windows workstation or a web-based service. I'll show you exactly how that happens with a live here.
This is my final slide before I show you how this thing actually works. I just want to relate a couple of concepts to corporate identity. By introducing standards based proofing, that NIST 800-063-3 concept, you can establish citizen or corporate identity. So, citizen identity is all your citizen based government credentials, et cetera. Your corporate identity could be your AD or other on prem services.

We all know that due to COVID 19 many new hires will never be coming into the office for the foreseeable future. They're just not going to be exposed or want to take that risk. So now, using these technologies, you can proof them remotely the same way that your HR department used to do it in person. There's no limit to the type of credential you can enroll. The same proofing concepts are also applied to your existing users. So as I mentioned before, your connections to active directory, your physical access control system, or some SSO gateway, et cetera. These credentials are all enrolled one time and then you'll use user certificates going forward to replace the username and the password with identity.

It's really common for an organization to start with the low hanging fruit, such as Windows workstations or remote access, especially in today's remote world for things like VPN and Citrix. Since these are the most touched systems, you can have very measurable ROI in the first few months of a deployment, and you can measure it in the form of time saved per user. It normally takes 22 seconds to log in and a lockout takes 10 minutes to reset. You can also measure it in terms of fewer help desk calls. We have a whole bunch of net promoter score type concepts and real ROI that can be measured in the early days of this.

Enough with the backstory. Let's get you started with a enrollment into a passwordless system and then show you how to actually use the identity to authenticate. All right, so what we're going to see here is our friend getting invited to participate in the passwordless identification system. We are emailing them into their corporate email, a QR code. This QR code is an invitation to install the app. This app could come from the standard app stores that are out there, or it could be an internally-branded and pushed through an internal like MDM type app store through a mobile iron type environment.
The user will get taken to the app, install it. And then, the instructions say, scan the QR code a second time with the app itself. What this does is links the app back to the user's corporate instance of the application. Now, they're bound. What happened behind the scenes here is a decentralized identifier has been created and given to the user and his private key is being established on his phone, stored in the enclave.

Now, we're going to start introducing a bunch of credentials. We're going to start with an active directory credential. This is the same way you would log into a VPN or Citrix. We'll type in their current AD username and password. Now, behind the scenes, what's happening is this AD user name and password is being exchanged for a user certificate. We actually are emulating a smart card with this process. That user will never need to use this AD username and password again. They will just rely on the smart card certificate.

Okay, now let's introduce some other credentials. We're going to start with what we call our live ID. This is a real biometric. That handsome young man just enrolled his live ID into his identity safe. That is not Touch ID or Face ID. Touch ID and Face ID are great device biometrics, but they don't prove somebody's a user. I'm going to show you how that handsome, smiling young man is linked back to his real citizen identity in the subsequent stages. And that face that we just enrolled can be used for any type of high security operation going forward.

All right, we are introducing a driver's license. This is where we start introducing citizen credentials. We're taking the data off the front and the back, and we're also grabbing a copy of the picture to compare it to the user's live face. I'm going to run through three credentials in a similar fashion. We're going to enroll the data from a passport into the user's identity safe, again capturing the data via OCR. Grabbing the image. On the passport, we also can scan this with a high degree of accuracy because we can scan the NFC chip that's built into the passport using the phone's NFC reader. The key here for that is that NFC certificate is digitally signed by the issuing authority so you can trust it, and it gives a very high res photo. I'll also point out that all of this data is being done in memory on the phone and scanned, and the biographic information is being written to the user's private store. None of this is ending up in a central database outside of the user's control.

All right, the third credential we're scanning here is the Aadhaar card using the similar concept. Finally, we're going to introduce the palm card as well. Now, these are all options. Depending on the corporate profile or the application that we're trying to sign up for, these are just steps in a journey that you can have to strengthen somebody's identity via these mechanisms.

All right, so we've just enrolled citizen credentials, a corporate credential. We've linked them together and we've triangulated that user's live face with the face that's on the documents, and we now have the equivalent of a physical credential that you would carry in your pocket and present it to somebody. And it's in this person's control as much as that physical credential would be. Let's use that identity, you now to perform some passwordless authentications.

This is a Windows workstation and the user experience is typically brokered by the scanning of a QR code to initiate the handshake. This is that triple blind conversation that I mentioned before. Instead of the username and password, the user now has the option to do passwordless login. They will scan the QR code with their mobile phone, provide their real biometrics on first login, a hundred percent undeniable proof that this is the user and they're in without touching the keyboard. Now, on subsequent logins, let's say this user locks the workstation, they can receive a push message and use touch ID. It's completely customizable on what level of friction that you want to have. You don't need to use live ID every time after the initial login.

Now that the user has logged in, we are going to go to Okta and present their Okta credential. We don't need to use an Okta username and password. While Okta is a phenomenal single sign-on gateway, it still requires a username and a password to get in, mostly when you're accessing it remotely. When it's not coming from within the corporate network. Here, the user will enjoy the same experience. Using our IDP, they will scan the QR code. Their token is given to Okta and they're logged in without a user name or password. Touch ID is presented in this example. Now, they can go launch Slack or whatever other application is behind the Okta SSO portal.

All right. I'm sure you're seeing the benefits already and the wheels are turning in your mind, but let me focus on a handful of real benefits behind the scenes as you move from hope-based identity to identity-based authentication. A couple of the immediate benefits are first, obviously you're getting rid of the username and password, all the problems that we had around them.

There's too many benefits to state here, but the second benefit is continuous identity verification. Every time the user allows their identity data to be revealed, you have the option to check that real biometric. We're not just talking about Touch ID and Face ID. That brings me to the third benefit. You can always use their real biometrics to strongly reestablish their identity. We all know that people lose phones, they break, et cetera, and there is a identity recovery mechanism based on another industry standard called BIB39 that allows you to reestablish this identity and relink it.

You also need to keep in mind that Touch ID and Face ID are very reliable, and of course, Android has all of its flavors that are very similar. But again, they're not identity. And what can happen is something that you need to check with your authentication providers is what is the protocol when a spouse or a child adds a fingerprint or an alternate appearance to their phone? You can no longer trust whose thumb or face is coming into the phone. So, you need to go by act to identity and reestablish using real biometrics. If you have this type of standard-based system, you can do that.

I'll give you a real world example. I'm a Bank of America customer. My Bank of America app uses Face ID to let me log in automatically. If somebody else comes to my phone and puts their face on it, Bank of America app detects that. It does zero knowledge checks of the app and says, "You know what?Your Face ID has changed. I don't trust it anymore." They make me put my username and password back in, taking me back to where I was six months ago. Instead of doing that, using a biometrics-based blockchain system, I can just say, "You know what? I need to see your real face again and then I'm going to let that Face ID get reestablished and linked back to your Bank of America identity."

Lastly, using the decentralized identifier, you don't have to rely on a central credential database and you have a safe place to store all the private keys and biometric and biographic information in a place where only the user can access it. So, those are a couple enterprise use cases and I'll give a few more examples of those in a minute, but let me give you an example of how your customers can go passwordless without friction.

All right. This is an example of Chase Manhattan Bank, one of the largest banks here in the U.S. Let me back this up a little bit. This user, we call her Kate, and you'll see her all over our website, she has already established her identity with the bank. Every banking customer has already gone through KYC and get checked for anti-money laundering and all that. They have a very strong identity already so you don't have to repro them. You just need to link their existing identity into their block ID identity safe. Of course, this could be private labeled for Chase, or they could use our STK and use any of the components.

What Kate's going to do here is type in her username and password. With just four lines of JavaScript code, we can introduce the linkage of her identity to her safe. She's being asked now, "Would you like to go passwordless?" Of course, she's going to say yes. The instruction is then take her to say, "In your phone, in your Chase app, simply scan the QR code." This will now establish that basically FIDO 2 Authenticator to allow Kate to go passwordless in the future.

We'll ask her for biometrics and now she's giving a little message saying you've been upgraded to passwordless going forward. The second time she logs in, all she has to do is scan that QR code, or she can get a push message if she's already been in there once before. She'll provide biometrics again, and she's in without touching the keyboard.

Now, Kate wants to go obtain a mortgage. She's shopping for a new house. This is demonstrating a principle called open banking, which I have a feeling you are all much more familiar with than I am. This has gotten a lot of traction overseas. For me, overseas is obviously out of the United States. Open banking is an electronic way for banks to share information with the user's permission. If you think about the alternative, if you have data in one bank, you have to go to the second bank, download statements, email them, fax them, or whatever. Open banking is designed to get rid of that manual and very insecure mechanism.

So, Kate is coming to a new mortgage lender where she does not have an account. She's going to use all of the data from her identity safe that was introduced via those citizen credentials and apply with the press of a button. Then, she's going to go get the checking data out of her Chase checking account with the press of a button as well using open banking. What this form says, it's a little hard to see on the Zoom, but "Click here to fill out the form manually, or just use your passwordless authentication to fill out this form." Kate will obviously scan the QR code. She's going to present her live ID and gives consent for this mortgage lender to receive all of her biographic information that's needed to fill out the form automatically.

Now, the final step in this process is income verification, as I mentioned. Cosmos bank needs to where her checking account data is. She will come to this dropdown, pick the partner bank where her checking account is, and now we're doing a federated login to Chase Bank. Now, what it says here next to the chase logo is that, "Hey, cosmos bank is asking for three months of deposit information to verify. Would you like to exchange this information with the requester?" Kate will scan the QR code for authentication. Chase wants a biometric to make sure it really is her. She gives consent, can see exactly what data is being requested, three months of deposits. And the income has been verified and an application has taken minutes instead of potentially days. There's a real-world customer example of how the technology can be leveraged.

Just thinking about the user journey in a corporate setting, these are typical places where passwordless is getting a lot of traction. We already talked about the first point here, employee enrollment. I didn't touch on physical access, but once you have a credential in your phone, you can simply touch your phone to, like an HID reader and exchange a credential instead of having to use a piece of plastic. Then, I already demonstrated a Windows log on and some internal web resources like Okta. I'll just show two more short examples, a Unix login and a password reset.

The reason I want to show these to you is once you have identity, you can start to add different types of what we call user profiles into that identity. A second type of profile could be an administrative account. It's very common for you to have an administrative account to get into a privileged systems. Here, Kate's introducing her admin account. Again, we're exchanging this for a certificate. She'll never need to use it again. Then, as she comes into a Unix prompt, she'll see a QR code generated. This is via a palm plug-in on the workstation. She selects her admin profile, authenticates, and she just logged into an SSH session without having to touch the keyboard or a username password or SSH key being exchanged.

Now, the final example that I'll show in the corporate setting is legacy self-service password reset. It's still, we're not going to say that every password's going away day one. You can see Kate banging on the keyboard to her legacy HR portal. She will come into her app, click on a password reset button, pick the profile and question that needs to have its legacy password reset, introduce her new password, introduce the live biometrics, and she just reset her password without having to call the help desk or use some type of cumbersome self-service portal.

Just a time check, Anugen and Vicos, I have one more example just to run through how a verifiable credential can be used in a COVID 19 scenario.
Go ahead, Mike. Go ahead, Mike. Go ahead.

I got about 60 more seconds and then we'll wrap it up. That third pillar in an identity-based system is verifying somebody's credentials. This involves credential issuers, such as the elite CISO group, the user that's going to hold the credential, and somebody who's verifying it downstream that can click on a credential and verify it instead of it having to be a manual document.

We've been working with an organization called the COVID Credentials Group, COVIDcreds.com. They have taken all of these standards that are out there and apply them to how you have a COVID-verifiable credential in the form of an immunity test, either PCR, IGA, IGG, or a vaccination when that comes out. Rather than, again, carrying around a piece of paper, you'll be able to use this technology to digitally enroll, receive the credential, and present it to an employer, a travel agency, et cetera. Let's let this roll here. This is the interaction between Kate and a doctor who's issuing the credential. They're going to test the citizen. The doctor creates a QR code, and now the user is authenticating with the doctor. With user consent, they're saying, "I would like to exchange a certificate with you."

So, we have the results, the doctor is authenticating as well so we know the doctor did it. Now, we're touching positive or negative here on the result, and the user's certificate on the ledger is enrolled, stored on chain. And so now downstream, when somebody needs to consume that certificate, they can do it in that cryptographically way with zero knowledge proof. In other words, we don't have to go back and ask the doctor or the lab. We have a signed copy of that certificate that can be trusted by a third party. We'll come in here to Marriot, click the COVID clear button, authenticate. The certificate is presented, decrypted and presented off chain now, and given to the requesting authority after Kate has given consent. You could also do this without consent. Things like a university degree can also be done and have a permanent credential that's put out there, same way as you would put your university degree on LinkedIn.

That is the end of my presentation. Thank you for your time in listening to the story. I hope it was helpful.