Breaking Silos: How to Identify and Authenticate an Employee or Customer, and Verify Credentials using a Single Solution?

Mike Engle:
All right, I think we're ready to go. Thanks everybody for joining our webinar today with Forrester. My name is Mike Engle. I run strategy and growth for 1Kosmos, and I'm joined today by Andras Cser. Andras, if you wouldn't mind saying hi to everybody and let people know what you do for a living.

Andras Cser:
Excellent. Thanks Mike. First of all, thanks for having me. My name is Andras Cser and I'm a vice president and principal analyst with Forrester. I work in a security and risk team at Forrester and I cover identity and access management, so mainly customer facing identity and access management, identity verification, and quite a bit of fraud management as well. Again, thanks for having me. Pleasure to be here.

Mike Engle:
Oh, very good. And I appreciate having you here. Before we get started, I just wanted to make sure that we're all on the same page. We're here today to talk about best practices in identity, and specifically the mechanics around decentralized identifiers and verifiable credentials. And so to that end, it's really important to make sure that you know who you're talking to on the other end of the line. Andras, would you mind sharing your username and password, just so we know that you are who you are, to kick things off?

Andras Cser:
I don't really think I have any of those, unfortunately. Sorry.

Mike Engle:
Oh, yeah, we might have to call it then. How about if I send you a one time magic link or a text message, or maybe you give me a secure ID token?

Andras Cser:
I can't really do that. That's just really not something I can do.

Mike Engle:
Maybe we'll try plan B. How about if we verify your identity using a decentralized identifier? Would you mind opening up your identity safe app and scanning this QR code to verify your identity?

Andras Cser:
One second. Let me go there. Hold on, hold on, hold on, hold on, hold on.

Mike Engle:
Sorry to put you on the spot like that, but it's [crosstalk 00:02:11]-

Andras Cser:
No worries. No worries. Yeah, absolutely. Let's check this out. Here's the phone.

Mike Engle:
There we go. All right.

Andras Cser:
I'm authenticated using my digital identity credential. Absolutely.

Mike Engle:
That's right. We can continue on now. So now I appreciate you being subjected to that. That put you on the spot.

Andras Cser:
No worries.

Mike Engle:
But now that we know that we're talking to the real Andras we can get started. Decentralized identifiers are changing how we prove our identity and interact with remote systems. That's what we're here today to talk about. Andras is going to run through Forrester's positioning and coverage of the DID market, DID being decentralized identifiers. I'll be using that acronym quite a bit, and then I'm going to follow up with a couple of real world examples of how organizations are and can leverage DIDs to solve identity and other types of related problems today. With that, Andras, I'm going to let you share your screen and we can get into it and I'll talk to you all in about 20 minutes.

Andras Cser:
Absolutely. Thanks so much. Let's see here. Okay, and we are going to put this presentation into full screen and go from here. Okay, I'm assuming the display is all fine. Just please confirm that real quick. You can hear me okay? It's all good.

Mike Engle:
Yep.

Andras Cser:
Beautiful. Excellent. Again, thanks so much for having me. I'm here to talk about decentralized digital identity, or self-sovereign identity. There's a lot of names for this type of thing. One thing is certain, we have to do it and let me tell you why. Okay, in today's world, we are seeing a lot more challenges around the whole digital onboarding, digital approach, enrolling, verifying the identities and authenticating and authorizing users. Digital approaches here, especially with the COVID pandemic, but even before that, we've seen this it is really a key consideration for all organizations, whether for onboarding customers, whether for onboarding employees, business partners, et cetera, that you have to do this digitally.

There is no way that during these times people will necessarily go easy into a branch or into a physical location to have their identity verified and authenticate again, to do any kind of transaction. Digital approach has been here before the COVID pandemic, but I think the whole pandemic just accelerated the adoption rate and the interest that we see in it. It's always a delicate balance and a hard problem to solve. Why? You have a lot of security issues. We hear about all these breaches, account takeovers, identity theft and various other types of issues in the whole identity and access management space. You have to be able to put the lock on your door and keep the bad guys out. That requirement does not go anywhere. It still is important out there.

At the same time, you have to have operational efficiencies. Operational efficiencies are pointing to the fact that you cannot hire an unlimited number of people to take care of your employees' passwords, customers' passwords, business partners' passwords or reissue tokens. You have to be able to minimize and keep and the control identity, administration, workloads of Automations. And then finally, customer satisfaction. Any client end user company we talked to on increase, or in any other one on one interactions and conversations, tells us that the customer satisfaction and low customer friction is very important. If they don't like the experience they're getting from your website, from the mobile app that you provide to them, they will likely go somewhere else if they're a customer, or they won't be able to help and serve your customers if they are workforce members at your organization. Again, super important to have this.

Why is identity verification important? Obviously, identity verification is the very first step of the user's journey. This is the step that really allows companies, organizations, retailers in pretty much any vertical to assign a digital credential to a user, and understanding that the user's credentials are very [inaudible 00:07:07]. This is the whole step around making sure that this is not Mickey Mouse joining and trying to enroll for services. Obviously, increased and remote access to services through online and mobile commerce, it's probably the biggest driver. The cost of business needs to decrease. A lot of customers are on a faceless channel. They just want to go online. They don't want to call call centers. They don't want to go any type of areas to be able to submit their applications in person.

Snail mail is also out of question for a lot of people. My children, they're 18 and 20, there's no way they're going to do anything other than interact on a mobile application, basically. Or at the worst case, on a website, online website, to create an account, authenticate, be verified, et cetera. The past data breaches have compromised usernames, passwords, credit card numbers, and all these issues still have... We have not recovered from those. And there is definitely a huge and rising identity theft, and basically the story here is that you have to actually go there and be able to do very much controlled identity registration, online enrollment and authentication. If we compare the period, the same period, first half of 2019 with the first half of 2020, our estimation is that we are seeing approximately 10 to 15% higher fraudulent activity, so identity theft, account takeovers, compared to the same period last year.

Again, this is another reason why you want to have a very solid and robust identity verification story here. If you look at identity verification, this is the alpha and omega of IM. If you don't know who you're dealing with, you're clearly lost. We've seen a lot of people onboarding dubious customers with synthetic identities, and obviously when we look at the current status quo, ie., companies using know knowledge-based authentication and out of wallet kinds of questions from the credit file header of a user, so answering questions like, "What was your monthly mortgage payment from 2005 to 2020? What kind of color vehicle have you leased in the past three years? What was your mortgage amount et cetera? Or what was your student loan amount?" These kinds of questions cost a ton of money to source. They are very difficult to answer for customers, causing friction, and people are really increasingly reluctant to actually answer these types of questions.

Some of the other areas of identity verification or other layers and sources of identity verifications include things like phone number. Is this prepaid, postpaid number? Is this a number that is related to the user that we have on file, et cetera? Social identity verification, which really looks at the digital exhaust of what the user had been doing online; social media profile linkages around these social identities, social media profiles. Behavioral analytics, understanding how you type on a keyboard, and the whole idea here is that if you have a legitimate user applying for credit or applying for some kind of a benefit, they'd be using different kind of mechanisms and different ways of moving the mouse, typing on the screen, swiping a smart device screen. Then what a fraudster would do would be, fraudsters typically copy phone numbers, typically copy email addresses from large Excel spreadsheets onto a file, all capital characters. And the way they type is also different from legitimate users.

And then consortium data, whitelist, blacklists, transactions, et cetera, that's also part of the story here. And then we're seeing a lot of physical document verification mechanisms as well. That's another area of understanding somebody's physical document. You take a picture from a mobile device of your document, then you take a selfie or multiple selfies, video, blink, et cetera, so do some liveness checks. And then from then on you can verify the identity. Some of the issues and trends around managing identity verification, so again, staying ahead of fraudsters is always the most important thing. They seem to be understanding end user clients and retailers, banks, et cetera. Fraud management, thresholds, guidelines, rules, et cetera, so they also know how to evade detection.

Fraud models, there's a lot of questions around that. Question generation using non-public data sources, so questions that can come from data sources that are not readily viable on the black market, or even legitimately. Measurement of any kind of question answerability, so being able to tune these models. Predictive models, so even before, so initial a customer onboarding predictive modeling is very important. And then identity resolution, getting a feel for if it's a translated name from a foreign language that is not using a Latin alphabet, what are some of the ways to spell one of these foreign names? And again, false positive and false negative reductions, very important. False accept rates need to be reduced, because of the security concerns. This is when you allow a user who's not the legitimate user to log in again, and then false reject rates is when you got the right user doing the right thing and they're still getting rejected. That's a customer satisfaction issue, and keeping the cost down is always a key consideration here.

Continuing some of the difficulties, so any kind of a fraud detection, velocity checks, pattern recognition, identity characteristic checks, device characteristics checks, known fraud patterns checks is very important. Link analysis can be hard to how you put together and put it into a large spider diagram all the entities. Maybe there's linkage or collusion based on a phone number or email address or date of birth or name or combination of name. False positives we thought about, and then context sensitive analytics to influence risk based authentication decisions in real time. This is understanding things like IP address, geolocation, device ID, device fingerprint, time of day, session speed kinds of aspects.

And then understanding last proliferation and sophistication of fraudulent identity documents. There's just a lot of these things, a lot of problems around these documents. It's not that hard to get a fake ID, just ask any teenager under 21. And linking online and real world identity uses again, the Nirvana here, of having a full view of what the users electronic and digital credentials and tracks are, and augmenting these with the real world type of identity characteristics, such as a driver's license or such as a credit file header report.

Some of the use cases that we see here, so obviously verifying a human identity before issuing a credential to them. Fraud prevention, access policy enforcement to apps and data. This is basically the login, a routine or step up authentication, account opening, so initial onboarding, and then the enterprise fraud detection story. Where you need to do this? Everywhere. It's a cross channel, omnichannel requirement, websites, mobile applications, call center, in store and branch processes, obviously they're significantly reduced these days, but they're not going really anywhere longer term, so they might come back in the future. We still have to be prepared to be able to handle these.

One thing definitely is out there, the decentralized model of identity verification, or IDV, is not a tenable model. This is something that represents a lot of problems, privacy being one of them, and the increased risk of a data breach is also out there. When you're looking at a centralized repository of ID verification information, such as the Equifax story, such as the OMB actually losing... The US Government losing millions of face ID images for government employees. These are all examples that fraudsters want to actually go after these centralized repositories and steal identity data from there. You can look at a number of these kind of fiascos. These are just a few.

What's the solution? The solution is decentralized digital identity, and really, at a high level, we've written about this, we've written about some of the benefits. I'm going to talk about some of the benefits here, but what is decentralized digital identity or self sovereign identity? You have an issuer... There's basically three parties here. There's an issuer, there's a verifier and there's a user. The issuer would be typically an organization that can be like a college, that can issue a diploma or certification of a degree. It can be a government body that can actually issue a digital version of a driver's license. It can be an employer that basically issue a certificate of a tenure of an employee.

And then you have a user who actually wants to be able to prove to a verifier, and the verifier I'll talk about those, but a user wants to prove to the verifier that they are eligible authenticated or real, in a way. How does this happen? The way this happens, that the user has an eWallet in which they store claims and proofs for issuers. Basically, when you have an issue, let's just stick to the government issue digital identity card example, the user would download the eWallet and would, after authenticating themselves, download their claim or proof or a version of the digital identity card into their eWallet.

At the same time, the issuer would make a note or a hash on a digital ledger, which is tamper evident and tamper resistant, that they had issued a signed, digitally signed, digital driver's license to the user and the user actually stored it into their eWallet. Let's say the user wants to go to a liquor store and basically the clerk at the liquor store wants to verify the person's eligibility to purchase alcohol. In other words, in the US, is this person over 21 years of age, or Europe, are they over 18 years of age? At this point, the verifier will actually ask the user to present this claim or proof, ie. the driver's license, and then after a handshake protocol that the user actually consents to the verifier verifying their driver's license, the verifier will check the validity of the claim and proof using digital signatures, and also checking the mark or the hash that the issuer stored on the digital ledger.

At a high level, this is how this works. And this is really, you could say, "Hey, this is nothing new. There's no real benefit to this." Basically, let's talk about what the benefits are. A lot for your privacy concerns, right? You don't don't have a centralized, gigantic source of information that is one singular database that hackers can go against. Every user stores these digital certificates, digital claims proofs in their own wallet. The security of the claim and proof is pretty high, because all the communication is encrypted. There is a blockchain hash, there is PKI certificates being used to actually sign these claims and proofs at the time of issuance and there's a number of additional security checks that can be added to the framework. The biggest thing is Zero Knowledge Proof. Basically, the whole idea here is that I don't have to present my ID, as a user, to the verifier or the liquor store clerk, with all the extra information, such as my name, my date of birth, my address, whether I need to wear glasses to drive a vehicle, et cetera.

The only thing I'm proving here is whether I'm over 21, yes or no? There is no additional information that is being shared, so basically as a user, you're not answering questions involuntarily that are not being asked of you. You are not sharing information about personally identifiable information or sensitive information that are not needed to complete that process. In this transaction in a liquor store, the only thing that you need to do is whether the picture is you and you are over 21 years of age. Tamper evidence, so these identity claims and proofs and wallets are a lot harder to falsify than physical documents, because of the signatures and the whole online nature of verification. There's instant revocation of claims and proofs, which is just very much unimpossible in the physical document space.

If I lose my driver's license and it falls out of my pocket with my wallet, that means that there's no way for me to actually stop that copy of that driver's license. I can stop my credit cards, I can stop my other payment type of devices, but if somebody finds my physical driver's license or a certificate of education, they are able to tamper with it and modify it and forge it and potentially use it. With digital claims and proof, this is not possible. There's a revocation mechanism that the issuer and the user can invoke here. There's a much larger ecosystem, new players. If you look at this previous slide, issuers and verifiers, it's possible to have issuers that are verifiers and verifiers that are issuers. There can be some duplication or cohabitation of these two [inaudible 00:23:16].

Some of the concerns that we see, users top concerns are data protection and data collection, not sharing any data from their own device. I'm going to share a slide and some data that we have a at Forrester to prove this. Definitely security, usability and friction and device data and eWallet backup. If you lose your mobile phone, and with the wallet with it and all the claims and proofs in the wallet, how are you going to actually recreate all this? How are you going to redownload and reinitiate the wallet and redownload, or get all the certificates claims and proofs that you have in your wallet. Again, some of the concerns are, this comes from the demographic survey at Forrester, which are the following concerns about your smartphone and how you use it. Security of personal data on the device, damage, obviously, but the security of financial data, losing files, viruses, theft of the device, et cetera. These are all big, big concerns out there.

Recommendations. If we have an organization that wants to build this, what do we see? What do we recommend? Do not build any standards on your own. There is a lot of open standards, a lot of protocols that are here. DID and BlockCipher are two, but if you want extend all this into a broader ecosystem for single sign on that you want to use; SAML, Open IDC, FIDO2 for two factor or passwordless, OAuth2 and others. Use a vendor. Try to look at end to end vendors here, that provide you with a ledger, the eWallet, the registration, authentication and other use cases. Obviously keep the vendors, DDID or DID solution openness in mind, and then how well it supports mobile biometrics, face, touch, voice and others. What size is the ecosystem that the vendor would have?

Be ready for bot and hacking attacks on day one. Even today, hackers are unfortunately not sleeping. You'd say that the COVID pandemic caused some kind of a lull here in bot and hacking attacks. No, this is back with a vengeance. And then obviously, using behavioral biometrics, again, understanding how a normal user works on a device, how they manipulate the screen, keyboard, how they hold the device, et cetera, is an important thing. On predictions, future elements here, we are going to see vertical, specific, decentralized digital identity networks, and the whole concept of DDID is very much applicable to healthcare, the eCommerce vertical, government type of verticals, education definitely is part of the conversation that we see here.

The use cases cover B2E, so employee or workforce facing identity management, B2B, so business partner facing identity management, and customer, B2C facing identity management, identity verification, authentication, step up authentication. We are going to see transitive trust, that's our prediction, so basically being able to move from one vendor's, DDID vendor's network, to another. Kind of have some inner connectivity and transitive trust between these networks, and a lot more standardization and protocols out there. There's still room for standardization. With that, I'd like to conclude my part of today's webinar and hand it over to Mike.

Mike Engle:
Excellent. Thank you, Andras. I'm going to take over your screen sharing here. All right, yeah, here at 1Kosmos, we're very much in line with Forrester's predictions on DIDs and the benefit of verifiable credentials. We see a couple key benefits to DIDs that we talked to our customers about, really in how we engage with users and solve IT problems today. The first is the privacy and convenience factor. When you only have to share the required elements about their identity to access the specific system service or application, it reduces the need for an intermediary. Nobody on the corporate side wants to trust login with Google or Facebook, and then the user has full control over how his or her identity is shared. This really simplifies the account set up and access and keeps the system free of using names and passwords.

Andras gave the example of being able to prove that you are or are not legal to drink in the United States, and that I am 21, yes or no is really all you need. Without DIDs, we're obligated to overshare by having the full credential. And then on the security and fraud side, users are more secure, because they aren't managing passwords anymore. And we're going to mention the word passwords here quite a bit, but it is a key enabler here. Businesses are more secure also, because they don't have to store huge volumes of descriptive PII, and identity fraud really becomes almost impossible, because the user data is stored on a private ledger, which is just about unhackable as it gets. And related identity issues, such as account takeovers, credential phishing, synthetic identities, et cetera, are all mitigated as well.

And then you have cost savings. You can reduce a number of costs for customer onboarding, data management and security, and also life cycle management. And then last you have new opportunities. Digital identity brings opportunities for new products and business models, where issuers and verifiers can participate, possibly earning money in a secure and more trusted model than what we have today. I just want to say that a lot of what people hear about with DIDs and the concepts around them, they think that they're just this futuristic concept that doesn't apply to the world we live in today. In a few years, users, issuers, verifiers, they're all going to participate in these networks. It's going to be fantastic. Take your ID, go cross a border with it. Don't need any documents, get rid of all the security risks.

And there's been a whole bunch of standards supporting this in the industry. The standards are only a few years old, but they're making great progress and being pursued by a lot of big names that you all know. Verizon offers a DID-based solution called Verizon Identity, solving their customer identity and authentication challenges today. And you have IBM, Microsoft, MasterCard, they all have dedicated teams and marketing efforts to bring the benefits of DIDs to market and to their customers. And on the government side, just in the US, the activity's been really frothy in the last year. A couple things we've been watching, the SSA is pursuing DIDs for customer identity and access management. Imagine social security administration and the threats they face, just hundreds of millions of identities. The TSA as well is using it, or are looking to use it for an alternative for physical document identification.

The FFA just put out an RFI, and last week there was an announcement for a competition by the Department of Homeland Security for the best UI for a digital wallet. And by the way, that's due on October 15th, for any of our colleagues and peers out there that want to take a crack at that. And we're tracking a dozen other countries that are digging into decentralized identity world as well. Without DIDs, this slide demonstrates where user data, most notably usernames and passwords, live today. This is the best we could do for the past 50 years, because we can't securely reach across the network and have someone prove who they are. I know the example that we did at the beginning, with Andras and his personal wallet, which by the way, we set that up yesterday, he enrolled his identity and that way I could have him authenticate to our web service here today.

But without this type of technology, you just really don't know. Every application has its own username and password representing something they know, which we know how much that sucks. And of course, something that they know is possibly known by somebody else. And so to mitigate this, we've introduced more factors, representing not only something they know, but something they have, like text messages, tokens, one time passwords, et cetera. These methods do not prove a user's identity. And as we all know too well, the experience of username passwords and MFA is just terrible. And for the security practitioners in the audience, the central credential store is a target and passwords can be coerced from our users by phishing and smishing and these other methods.

What did solve for enterprises today, and as the title of our webinar today indicates, I'm going to show you how you can realize the benefits of DIDs today for your workforce and your customers to solve three key issues. The first is who's at the other end of a digital connection? You can enroll and store digital identity and biometrics into an identity safe, and in some cases, without the user even knowing that a safe is involved. Standards such as the NST 800-63-3 can be used to strengthen the user's identity, and two, how can I best authenticate them? DIDs introduced public-private key pairs and biometrics, instead of usernames and passwords. This allows you to use identity-based authentication and not something that we've coined recently called hope-based authentication, which is what we use to describe usernames passwords and traditional MFA.

And FIDO Andras mentioned this as well, Fast Identity Online is a standard that's been around for about eight years, uses similar mechanisms to replace passwords with public-private key pairs as well, however, FIDO doesn't have an identity component. And so DIDs bring that to the table to enable FIDO to bring identity as well as strong authentication. And the third is what credentials do they have? Now you can assign and verify an industry credential or a personal credential in a safe and secure manner, and store it in that same identity safe. Sorry, one button ahead of myself there. It's easy to hear this. It's like an alphabet soup of acronyms. DIDs and FIDOs and IALs, and you can easily take away that this is going to be a very complex and cumbersome system to implement.

But now we're going to take a look at how you can turn the identity and authentication upside down, without breaking the bank or introducing too much complexity. A key enabler towards embracing DIDs today is that they can be used without heavy infrastructure changes. The last thing you want to do is try to implement something with a real heavy IT lift. Of course nothing's free, so you still have to do something and implement something here. But let's take a look at what need needs to change. This diagram represents traditional IAM functions here at the bottom, and all the applications that surround them. Some non-SSO apps on the left, SSO apps on the right, and a big part of the system is that you have to push credentials down into the target system. That's one of the major functions of IAM.

Instead, we're going to move the credential to the edge with the user. This is what DIDs do for us. There's three components required to enable DIDs for customers and workforce. The first one is here on the screen, is the digital safe for the user. This is typically embedded into an existing app or provided as a new one, and I'll cover how frictionless that is in a minute. And then you have an identity gateway. This can be a cloud or an on-prem service, and this bridges the user to the requesting application and it makes API calls to verify any identity information that is enrolled. When you embrace DIDs for workforce or customer IAM functions, your organization acts as the issuer and the verifier, and Andras hinted to that as he was wrapping up there.

This means you don't have to wait for the network effect to realize these benefits today. And then third are lightweight components. These connect existing applications to the system or provide simple federated login. These allow the DIDs to be translated into an existing username without requiring any application rearchitecting. And just to give a different view, an application based view, here in the middle you have the user managed identity safe, and on the right you have the application that they need access to. The users and the applications have their own keys. The identity gateway brokers the connection between the parties, allowing them to initiate a secure exchange of data and an immutable audit trail is written to a private distributed ledger as well.

The best part about this is enabling it on the application side is a simple modification to the login page with two lines of Java script code, similar to how you would enable a login with Google mechanism. And with this model now, application access is granted with a couple of different factors. Now you have something they have, which is the private key on their phone, and then something they are, which is the biometrics. I'll talk about real biometrics in a second. If desired, you can also introduce something they know in the form of a PIN. And the benefits to the organization are many. Some of them we've already stated, but there's no backend application code changes, there's consent-based authentication, a proofed identity, a better and consistent user experience and the removal of central password stores and mitigation of insider threat.

Now, let's move it one step further downstream and put the DID in the hand of the user. First, we give the user an app or enable the DID functionality into an existing customer app via an SDK. Upon launch, this user's DID public and private key pairs are created, and then we'll let the user enroll their existing account credentials. For example, this could be just their existing, active directory account that they're using every day today, or their current username and password for their banking app. And what this does is exchanges that credential for a key that mirrors what smart card functionality does without the need for a smart card reader.

And next, we'd simply capture their advanced biometrics with the camera. We call this a live ID. This has a liveness test which cannot be spoofed, interacts with the user, makes sure they're a real person. And it can also now link their device biometrics, which aren't as secure, but are pretty good. This is your touch ID, your face ID, et cetera. And in all this, the friction for the user is minimal. They're simply entering their existing name and password like they do today, and linking it to their biometrics. And this is the last time that they'll have to use that dreaded username or password going forward. And we can also increase the identity score by introducing government credentials as well. Something I'll touch on briefly in one of the use cases in a minute.

Now, we've enrolled the entity and now any user, whether it's an employee or a customer, will enjoy the same experience, no matter what type of service that they're accessing. They simply scan a QR code on the target system, and you saw Andras do that here today, and then they authenticate with the device or advanced biometrics. And then within a second, permission is granted. I'm going to run through a real world DID implementation example here. This is an example that one of our customers did, using DIDs to simplify life for their user base, and also made it easier for the IT department by reducing the moving parts in their existing system.

It's a legal requirement for doctors to be verified before they can interact with medical systems, for obvious reasons, and this is where strong identity proofing is done at first touch. I mentioned government credentials before; instead of them taking their documents to a notary or an office, they'll simply scan their government issued credentials with the app and they're validated in real time. And the security features of the documents are checked as well. API calls are then made to third party data sources of truth, such as a state or federal issuing authority. In this example, a physician's database is checked as well for this particular use case.

And in a matter of minutes, they're compliant with the company's onboarding priority policies, and this is something that could have taken days in a prior world. And now we need to give them access. They'll use device biometrics with touch ID, for example, and negating the need for usernames or passwords to get into the front door of the application. The third requirement is for a doctor to be verified with multifactor authentication whenever they prescribe a controlled substance. The legacy system required username, password, and then an external token as a second factor. Now their identity's verified in real time, in one step. And furthermore, due to the cryptographic capabilities of DIDs and decentralized distributed ledgers used, a digital signature is stored on that ledger, giving them an immutable audit trail. This satisfies all kinds of regulatory requirements as well.

And this isn't just for customers. We've mentioned workforce a few times. The Game of Life board that you see here demonstrates some of the low hanging fruit in an organization. Many companies have passwordless initiatives on their roadmap. By using a DID-based system, they future proof the IAM stack and they'll utilize the same stack for their customer identity as well. And they realize the benefits of passwordless on day one. A typical day one candidate for implementation is to use identity-based authentication for Windows workstations. Whoops, sorry, my little graphic's not working there. Windows passwords, as we all know, are a tremendous source of friction. They change every 75 days, 16 characters, very long, et cetera, and this is a huge burden to the help desk. A medium-sized organization can save six figures of ROI within the first few months. And also given how COVID, in the new COVID reality that we're in, remote access is a very likely candidate for early adoption for this type of technology as well. Now organizations can trust that the personnel accessing their systems from home is who they think they are, based on the identity, rather than username, password and MFA.

We've covered identity-based authentication, and DIDs can also extend their capabilities to cover verifiable credentials. This is a W3C standard that allows an organization to issue a qualification achievement, or really any other piece of information, and assign it. And so this isn't just, is this person who he or she claims to be? DIDs do that very well, but does this person really have a fine grain entitlement to their identity? Common credential types are education degrees, and Andras mentioned this one as well. There's a number of efforts amongst universities and other educational institutions to create a digital diploma or a core certificate. And so you, as an employer, will be able to verify these certificates with the press of a button, without having to contact the issuing institution. You'll be able to trust both the certificate and the identity of the applicant in one step.

And then another very common use case is your employer status or right to work. Forrester, in the example we gave originally, could have issued a verifiable claim that Andras is truly an employee, and that could be verified via a public URL that Andras could give out. That's a common use case that's getting traction. The other benefit to these is that they can be revoked or renewed, and the certificates get tied back to the original entity. There's no more swapping of usernames and passwords while somebody's brother fills in for them from an employment perspective. And then the recent example of COVID credentials has gotten a lot of industry attention as well. Without a verifiable credential, travelers are carrying around pieces of almost worthless paper to prove that they have a recent PCR test, for example, if you go to the Caribbean.

When vaccinations come out, there's going to be a need for a trusted digital attestation about immunity that can be trusted by your employers, by merchants, by the governments. This is a perfect use case for both DIDs, verifiable credentials as well, and your organization can issue these certificates to employees and they can be verified at the front desk without revealing any sensitive information to the person who's working there. And on day two, the organizations can be plugged in together and the network effect can start to kick in.

Verifiable credentials follow a lot of the same privacy preserving identity verification principles, such as zero knowledge proof. Andras had mentioned that. The original document does not need to be seen by the requester, and they also protect the user's identity, personal data and have renewal and revocable mechanisms. One last example of this, this is a verifiable credential in action. There's a mechanism within LinkedIn today that allows you to verify certain types of learning certificates, and this is going to be extended to education degrees and employment degrees as well. An example of this would be that you can verify, with the press of a button, that this person actually went to this university or college.

In summary, to wrap up, put DIDs at the center of your IAM stack and remove hope-based authentication from the mix. Sorry, getting rid of my animations here. Make sure you follow the standards that are evolving around the DID world. As the DID industry matures and more national and global players come together to create the network effect, you'll be ready, because your stack will already be compliant with these standards. That wraps up my part of the presentation. Our curator's been collecting some questions from the chat that have been flying in since we started this an hour ago, and we'll run through a couple of them. Michael, if you can just pop one up on this screen here. This is a question for Andras. What is the implementation length for decentralized identifier projects?

Andras Cser:
Based on what we are hearing from our customers, obviously this will depend on complexity, size, number of users, the size of the ecosystem, it's not uncommon to start seeing results in less than six months, but more likely in less than three months. Again, the more you have a standards based ecosystem in other aspects of identity, the shorter the implementation will be, because you don't have to create a bunch of other custom ecosystems, custom integrations.

Mike Engle:
Very good. Here's another one. How do you handle a lost or stolen phone? I'll take this one. There's several options for account recovery. Our product uses an industry standard called BIP 39 that lets the user move or restore to a new phone. They can move the identity around and it has a restoration process and the process is protected with their biometrics. Even if somebody gets their hands on any part of the private seed, it's protected with a second step. And then Andras, this one's for you as well. Who, from the company, participates in implementing decentralized identifiers? I don't know if that makes sense.

Andras Cser:
Sure. The departments, or typical titles or functions within organization that participate in the [inaudible 00:49:35] digital identity implementation would include obviously IT or IT security. Definitely the line of business, product owners, digital experience officers would be very much interested in this. If it's a external facing project, marketing would definitely be interested here, as well as we see compliance, basically wanting to have at least a validation of all this. We've seen, for employee facing projects, HR, human resources, also getting a stakeholder role here as well.

Mike Engle:
Great. Thank you, Andras. And this one here is, in your diagram with the IAM architecture, where does the identity gateway get installed? Well, most providers of DID-based authentication gateways, they offer a cloud service, so everything is cloud first these days. This allows the service to be used with really very little impact to IT. A properly designed system should be very infrastructure friendly. It shouldn't require any firewall or DMZ changes for it to work internally, or with customer facing systems. Some of your internal target systems, like Windows, has to interact with active directory. In that case, there'll be a lightweight agent that gets installed inside the company's network that brokers the connection to verify certain types of credentials. And most platforms today can also be packaged using Docker or Kubernetes-type technology, so if there is an on-prem or they need to move it from one cloud platform to another, or move it into another country for data privacy reasons, that should all be something that a vendor can speak to very well and have that flexibility for multinational organizations.

And then there was another question here, how is the doctor verified at the time of issuing a prescription? In that example of the controlled substance, the doctor's verified initially onto the platform by scanning their government credentials, so driver's license, passport, et cetera, and then validating it with the physician database. The data is triangulated. The face matches the credentials that are scanned in real time, the address is verified, so these are all the functions that a notary would do or that a bank would do before they allow a bank account to have monetary transactions for KYC purposes. And that NIST standard that I mentioned, which is 863-3, has a very detailed component and guidelines that they give to the government to get to that high level of assurance.

That's the process that the physicians would go through, and when they actually prescribe the controlled substance and press enter, that's when they would have to pop up and they get a push message to their phone and authenticate their live ID in real time, which replaces the need for the username, password and MFA. That's, I think, the last question we have here. I don't see any others coming in. With that, I think we'll wrap it up here today. Andras, I really appreciate you coming in today and sharing your insights with us.

Andras Cser:
Absolutely. My pleasure.

Mike Engle:
We look forward to seeing you on the DID circuit as this moves forward, and we're excited to be working with you on this. Just any questions, by all means, send them my way. My email and Andras's is here on the screen. With that, thank you everybody for attending, and we will see you around. Thank you very much.