Techniques for Securing Transactions With Identity Verification and Verifiable Claims

Hello, and welcome to our webinar today. Our topic is "Techniques for securing transactions with identity verification and verifiable claims". And we're joined today by Mike Engle, the chief strategy officer of 1Kosmos. So a little bit about our upcoming events. These days, you know, KuppingerCole does a lot of events, including virtual events. These days. Next up, we have customer technology world CusTech that starts the week of October 20th. And we also have a parallel event as a KClive tools choice about privacy and consent management. And then after that, we have our cyber security leadership summit, which has both virtual and it has an on-premise component to in November. So we hope you can join us for those.
A little bit about the webinar itself here, we control the audio. There's no need to mute or unmute yourself. We are recording the webcast and the, both the webcast and the slides should be available within a day or so.
And we are saving time at the end for questions and answers. And if you look at the go to webinar control panel, there's a blank for entering questions. You can type in questions at any time as we're going here. So I'm John Tolbert lead analyst. I'm going to start off by talking about identity fabric framework, some fraud trends and mitigation techniques, specifically identity vetting and decentralized IDs, and how we eventually want to use this to move to all multi-factored passwordless authentication and still get high identity assurance. Then I'll turn it over to Mike and then we'll go for questions and answers.
So we'll start off by looking at identity fabric for consumer identity specifically. So what is an identity fabric? This is our concept for really it's an architecture. It's how do you deploy an architecture that can serve, you know, very modern needs of identity management in the workplace, and then also for consumers. And we found that where we definitely see trends that I am vendors. See, I have vendors are really turning their products into identity API platforms as the delivery model. And this means everything essentially against instantiated as a microservice, that can be both managed by an, in many cases, API APIs, but then also third-party applications have the, to pull information that they may need about end user identity consumer identity into their applications and use that as well. And there are several advantages and we'll talk about those in just a minute. Ultimately it reduces complexity for the team that administers it by building this set of technologies and being able to access it via API.
You know, we contrast this with, you know, how have typically we'd done. I am management for the last 20 years, you know, years ago you'd buy an identity management suite. It would either come with, or you'd build up a silo of user data, typically an Eldep active directory or something like that. It'd be managed by admin users, just using a Dewey, not necessarily is extensible, is many enterprises needed it to be for a long time. It was difficult to integrate with other applications because you know, they really weren't standards to support it. The data models were inflexible. You know, you were limited to El dab, couldn't really evolve to meet all the needs that businesses had, not only for, you know, business to employ business, to business use cases, but especially for consumer key use cases.
So as I was mentioning about identity API platforms, the idea behind this is let's break oil, all the different functions and specific services. So let's have authentication functions, authorization functions, identity proofing, and vetting services. And then this allows enterprises to add functionality or upgrade functionality discreetly. You can, you know, add authenticators more easily if you don't have to upgrade your entire I M system. And then also, you know, many enterprises found that they wanted to use data stores that were different than LDP. And I, we find Mongo DB and in the no SQL databases are sometimes commonly used for consumer facing applications. And these platforms can more easily communicate with CIM. And I am solutions as well as, you know, line of business applications. And it's really made more for a developer point of view than just an administrator who uses a gooey.
So let's look at the structure of this. They're service-oriented meaning you've got your application, but you also have the identity API layer and then the platform, which is the backend and more and more, we see enterprises using cloud delivered services for this microservices in containers. This is for agile delivery dev ops methodology. Again, you can, if you have an authentication microservice, it's much easier to add functionality to that rather than having to replace, you know, a whole IAM stack, same thing with authorization. You know, there are discreet authorization services now and where you can add protocol functionality again, without having to make major changes to other aspects of your IAM deployment.
And then it's ultimately about access to identity, information and data, but we need to be able to provide access to these things very securely. It's good to not have your identity data spread around in different end-user or line of business applications, but to be able to centralize that and then control access to the identity data as needed. So this chart shows it's, it's kind of a busy chart, but I think there are a couple of things that we want to express about what identity fabric means from a consumer identity point of view, looking at the three big blocks in the middle we've got capabilities, including things like adaptive authentication, credential intelligence, and things like that, that we'll mention later that need to be brought to life as services. And again, here, this is where we have things like an authentication service, fraud, risk intelligence service, maybe augmented by things like device identity and intelligence services and how that translates into your actual security and identity architecture. They're exposed via API APIs, but built as microservices. And the purpose for this is not only to make it easier to bring on new, totally digital services to support digital transformation, but also have a layer that can communicate with legacy I am. And then other line of business applications that may not necessarily support all the, the latest protocols and standards.
Well, let's talk a little bit about decentralized IDs. So I think, you know, we've, we've heard about BYO you're on device for quite a while now, the BYO ID is bringing your own identity. And yeah, obviously we're doing that in the consumer world for quite some time where, you know, consumers are used to being able to take their preferred ID from a preferred identity provider and use that, you know, in different locations, all around the web with things like BYOB in the consumer space, if you couple that maybe with the notion of self-sovereign identity that might be backed up by a blockchain in some cases, then we can also add attributes as necessary from a authoritative sources. And again, we can talk about that just a bit more in a minute, too. You know, you may want to enrich that with government provided identity attributes or employer provided or school provided, and then these can be used to help satisfy use cases, like know your customer and anti money laundering and believe it or not.
We see cases where employees, some companies might enable employees to use other third-party credentials, which can then be sort of enriched with additional attribute information. And this, this hasn't been going on for a while, too, in the partner space. So you think about the federated authentication, federated authorization. You know, if you're in like a supply chain relationship with, with contractors, you know, you will utilize the partners, identity schemes, and trust their authentication. So we have this notion of bringing your own identity has been in place for a while and it's actually being expanded. And then lastly, here on the chart, we've got devices and things, devices, mostly we're thinking about mobile phones, tablets, things that, that may have an identity of their own and may be associated with a particular user identity, whether it's employee or consumer, but that ownership may change over time. So it's important to be able to express that relationship, same thing with IOT devices or things, they, they can have a device identity in many cases, and they may be linked to particular human user IDs as well.
So when we look at a decentralized identity, we first look at the users identity credential, and then look at potential cases where it can be enriched by additional attributes. For example, a bank, you know, in the Nordic region, the bank ID is, is a fairly well trusted ID that can not only be enriched by the bank, but many service providers actually accept bank IDs. And, and these in turn can also be enriched by other attributes sources to let's say, a health provider it's possible to use things like zero knowledge proofs, such that a health provider could provide a proof of age without actually giving away things like birth date.
Same with government issued ID is government issued IDs. As we'll see later, too, can be the basis for credentials can be used to verify identity. And then there are various kinds of attributes that need to enter the ecosystem. Let's say address verification, for example. So that's use for government issued ID credentials employer. There are use cases where proof of employment is needed maybe for getting a bank loan or something like that. So having decentralized IDs with the ability to add that kind of attribute information is very useful. And then same thing with auto insurers, we see use cases where maybe you need proof from like the department of motor vehicles or some other government agency passed on to an auto insurer and then vice versa. The auto insurer can provide information about a driving record as far as then these things are useful because fraud happens as we all know, and fraud is increasing. Unfortunately it's estimated that we'll hit about $6 trillion with a drain off the global economy next year. And really just about every industry is a target. We always commonly think about banks or financial institutions and retail, but telecom is often hard hit healthcare. Healthcare can be kind of a rich source of records, travel and hospitality, not as much anymore, but you know, the GDC government to citizen, that's been hard hit in the last few months related to COVID and, and various scams of fraudulent actors trying to get different kinds of payments from citizens.
So we'll look at a couple of major fraud types. On the one hand, we've got new account fraud, synthetic fraud, sometimes called account opening fraud, and then account takeover fraud. And we'll dive into those here, we'll start account takeover. How do bad actors get that? Well, phishing is probably the most prevalent method, you know, send a email or text or, you know, even vishing voice phishing is becoming increasingly common. Again, the idea is still the credentials. It can happen through drive by downloads or fake websites that are designed to harvest credentials, key loggers root kits. Sometimes spyware can get identity information out of cookies, credential, stuffing attacks. That's using information and compromised credentials from the dark web, and then blasting that out against lots of other websites to see what they might get into. And that works in cases where users have reused passwords. And then there's the old brute force password guessing method.
The idea behind it is take these username passwords that have been recovered from a breach password dumps on the dark web. And they're used for financial fraud, just like you might expect banks, financial accounts, 401ks, you know, anything that's convertible into money is often a target, you know, rewards programs even. And we think the best mitigation against this is multifactor authentication, risk adaptive authentication powered by fraud in threat intelligence, doing things like identity vetting. And we always tell people don't use password reuse passwords and better yet. Don't use knowledge based authentication for account recovery. New account fraud happens when fraudulent actors go out and grab, you know, PII and use it to build accounts that are not associated with the actual individual and, and sources of this information can be healthcare companies, government agencies, school records, and they too are used for financial fraud, but they're, you know, to create mule accounts, to move money around, you know, get credit cards, why would they do that? And it takes more effort, but it's harder to detect and simply stealing and using a credit card number once or twice before it gets canceled. The major mitigation is here, but Intel and management, a lot of the activities perpetrated by bots, identity voting as we'll get into. And then some cases users can request credit freezes.
So the main fraud reduction techniques, as I see it, our identity proofing and vetting Prudential intelligence device intelligence, this is, you know, where's your phone or other device been? Is it healthy user behavioral analysis that's looking at, you know, is the current transaction requests sort of in the, the same spirit as other requests in the past behavioral or passive biometrics, that's maybe using swipe analysis or how users use their keyboards and then bot intelligence and management as being able to determine what activity against your website is, is real what's bought. And then, you know, how do you want to handle that? I'm only really going to talk about identity proofing here today, but this is using government issued credentials generally to validate a person against, you know, these authoritative documents. It's often driver's license or passport, as you might expect. And just to reiterate, these can help a lot with complying with anti money laundering laws and getting information for know your customer regulations. And then, you know, there's also value if properly consented to know your customer initiatives in terms of doing personalized marketing. But this also the main driver here is to increase identity assurance in, in not only consumer use cases, but even in BTE or B2B business relationships as well.
And finally, just wanting to talk a little bit here about risk adaptive and the move to passwordless authentication again for not only high identity assurance, but high authentication assurance. So risk adaptive authentication. We mean doing a risk analysis upon every transaction, and this is a combination of user device and then an environmental context. So what attributes can you pull from about the user, whether it's from L DAP or, you know, a behavioral analysis, a bit about the device where the request is originating, what do we know about it? Has it been fingerprint and what's the history? Is it healthy? Does it have anti-malware installed OSTP patch level and then looking at an in context of the environment, whereas the requests coming from geolocation, you know, when, what network do we think it's a bot activity? Do we think this has been influenced by malware in any way, this kind of decision needs to take place, you know, ideally with every transaction.
And again, the goal here is to provide a passwordless authentication experience, especially for consumers, because you want to make the user journeys POS as easy as possible, but also for employees and B2B partners too. And we do this by using things like MFA, get away from the password, use biometrics, behavioral biometrics, things that are, are easy for people to use. The don't require them to memorize passwords, which can also be fished or stolen. And then using adaptive authentication to, to really do this sort of continuously in the background and two ways forward. But this, this is now pretty well supported in the latest versions windows. And then also Fido two is a good standard for passwordless authentication. It brings together, you know, some of the best things about earlier versions, Fido, UAF, and YouTube. And then also with the web often specification allows access to web resources and is pretty well supported. And we increasingly see vendors moving toward Fido two as a standard to promote passwordless authentication. And with that, I'd like to turn it over to Mike.
I appreciate it. So once again, everybody, my name is Mike Engle. I run strategy and business development for 1Kosmos, and I'm going to touch on a couple of, of the identity concepts that John brought up in his slide, specifically, decentralized identifiers and identity proofing and what we can do with them from a passwordless perspective. So, you know, John touched on a bit on the challenges side and the fraud and so forth, and I'm going to get a little pretty deep into two specific sources of these frauds. And the number one item that he had called out was fishing specifically fishing, and you know, which leads to business, email compromise lead to 60% of all breaches. And this is in stat after stat from major research, from the likes of Verizon IBM Barracuda, et cetera, right? And, and what's changing of course, is COVID over the past six months, everybody's working remotely and increases the tax surfaces dramatically.
And business email compromise is a very targeted type. And so if someone gains access to a trusted email via phishing, you know, I target a thousand corporate users with a spray and pray technique. I get five people to bite, right? I now have five trusted accounts to do my spear fishing resulting in business, email compromise. And the stats on this are really staggering. I'm not one to throw stats around, but these are really significant. There's been a 700% increase in phishing and business, email compromise attacks since COVID. And I know on my personal device, I'm getting fake ups and election type texts, trying to get me to click on links all the time. I'm sure you guys are too. And the impact of this goes beyond just potential data loss and somebody getting inside. Cause now it professionals are always walking a tight rope between two activities, right?
We have to defend against breaches. All right. And then we also have to support top line activities. So now we're spending more time defending and less time supporting the business and that's has taken quite a toll on, on our, our time effort, et cetera, along with everything else that we're struggling with today, we're being pulled in many different directions and fishing. Isn't the only vector, just take a look over any of your coworkers, shoulders and on the next zoom that you're doing. And you'll see, I'm sure an improperly secured home router with some password that the user selected out of their brain. And then the other side of the room, you have half a dozen cloud enabled IOT devices, probably using the same password. And then you have half a dozen personal devices and social accounts for the employee. And we know creatures, you know, humans are creatures of habit.
We all try to use different passwords, but we don't even when it comes to corporate. So the other thing John mentioned is password reuse becomes a real challenge. So what's to stop somebody from using their Microsoft live account or their Facebook account to come in and use that on the front layer of your VPN or your Citrix or, or, you know, front door into the, into the environment. And yeah, you may put some MFA on top of that, which helps then I'll touch on MFA in a minute. So the point of this is it's not just phishing, it's username and password exposure that are really exasperating the problem. So now what if we could authenticate the user without usernames and passwords? So getting back to the header on this slide, what's the common theme across all these services it's identity, right? And identity is not a username and password or username.
And password is hope that the user coming in is who they say they are, right? So we've replaced today's we have to replace today's hope based authentication with identity based application. And here's one last way to think about this. And this slide is really a way for me to make a little bit of fun at our own expense, right? I've been in it for 30 plus years and insecurity for 20. So when we use usernames and passwords for authentication, it's what we hear at 1Kosmos referred to as HBA or hope-based authentication. So we ask our users to use a username and password to come into windows or whatever banking, et cetera. And we hope that they can remember it, right? And we hope that they've created a strong password. You make them change it every 75 days. Now you hope they don't get locked out.
And then you'll sprinkle on some MFA and you hope they can figure that out as well. Don't lose their Coke and et cetera. And then you hope the password was not stolen from a central database. And it wasn't man in the middle, middle or socially engineered or fish as we brought up before. Right. And I'll share a quote with you from James Cameron. That really resonated with me when I heard it. And what helped us kind of coin this phrase. And it's relating to the balance. We all have between risk aversion and risk taking, and you need to balance it too, right? It's what we all do as security professionals. But what James said is luck is not a factor. Hope is not a strategy and fear is not an option.
And this slide is one of those kind of logo, vomit slides that try to show all of the cybersecurity players that exist in the identity space. And you know, everybody in the audience knows this well, there's so many vendors in the space. It's hard to know which way is up or down when you talk to them. And the reality is over 50% of these companies exist due to the insecurity of using usernames and passwords to guess who's accessing our systems. So I'd like to call these companies a lot of them, password mitigation companies, and they fall into a bunch of different categories that we're all familiar with. And John touched on a couple of these earlier. So of course you have the username and password, which is the root of the problem. But since that's not good enough, we make the passwords expire every two, three months.
And we put some crazy complex character requirements into them. And then we'll add some two factor authentication, which includes email, SMS, one-time passwords. And then since when two's not enough, we'll add more factors. We have MFA and we have RBA for risk. We have KBA for knowledge-based. We now are implementing single sign on. And then we have password managers, which put one big password around all your little passwords. And we're using also using things like pins and keys. John mentioned Fido. And I'll talk about that a little bit more because that is a, definitely a step in the right direction, but all of this is to strengthen the username and password. So now the two of Faye's gotten really popular just about every cloud service is pushing this typically via SMS, right? And your apple everybody's going to, to FFA. However, it's not the answer.
All right. We've already touched on the notion that adding layers on top of usernames and passwords just doesn't work. It exasperates the user, and it's still very susceptible to phishing, right? And most notably note how Jack Dorsey was hacked two months ago, the FBI is also warning that there's four specific types of two theft attacks going on. They're on the rise, right? And these layers just they're, they're, they're tiring out our users and they're not really helping that much. So it's time to get rid of the credential, which closes the vector a hundred percent of the time if you do it right. And I'm not just talking about going, passwordless, I'm talking about going credentialist right. Getting rid of both usernames and passwords and external MFA systems and migrating from HBA hope-based authentication, identity based authentication. So now we had our, our other slide, right? This looks familiar and I'm by now, you're all probably like Mike, you know enough about passwords. I've I get it. You're like describing the water while I'm drowning in it.
So, you know, w we've secured the network, we've secured. Many of our devices we're protecting the data as well. And this final layer is to now, as John brought up very early in his presentation, verify the identity and authenticate the user properly, right? Cause we all the security that we put on the networks and the systems is useless if we opened the door for the wrong person. So what the technologies that John mentioned specifically around identity proofing, decentralized identifiers, what they do is allow us to ask the question of your remote users. How do I know you really are? Who you say you are, and to do this, we need to introduce the concepts of identity verification and proofing to our IAM stack. And there's a couple of ways to do it. So John touched on credentials. You can always ask your employee new hire or customers for a government issue credential, or you can exchange their current username and password for a public private key pair. And that's some of the principles that are coming out in like the Fido two concepts.
So that principle of the public private key pairs is what decentralized identifiers brings to the table for you. And when you think of public private key pairs, you're probably thinking, oh God, not PKI, not smart cards, right? Cause they're a management nightmare will decentralize identifiers solve a lot of those usability challenges, right? So the first, the decentralized identifiers will bring three benefits and solve three key issues for your IAM stack. The first is who's at the other end of a digital connection. So now you can enroll in store digital identity, and more importantly, Biometrix into an identity, safer wallet. And many times the user doesn't even need to know that a identity safe is involved. They just go about doing things the way they do today. And there's identity proofing standards, specifically NIST 863 dash three. And as a whole framework, which allows you to make sure that you have a strong remote identity at the other end of the connection.
The second is how do you authenticate them now? All right. So we've enrolled in identity. How do I integrate them without passwords? So as I mentioned, DIDs, provide a public private key pairs and introduce that along with biometrics instead of usernames and passwords. So this allows you to use identity based authentication and not hope, which is what I've belabored on it quite a bit. And as John also mentioned, Fido uses similar mechanisms to replace passwords with public and private keys. However, phyto doesn't have an identity component and does bring that to the table. So when you combine DIDs with Fido principles, it really strengthens the story. And the third challenge that decentralized identifier stalled is what credentials does this person have. And John had that one slide that showed education and health and so forth. And I'll give some real world examples of those in a minute, but now you can assign and verify an industry or personal credential in a very safe and secure manner and store it into the identity safe. And the, the best part of that is you don't have to present the original credential. You Nope, you don't have to give somebody your diploma or some type of employer card, for example. So, you know, it's easy to see this kind of alphabet soup here on the right side of the screen and think that it's going to be very cumbersome to implement, but let's take a look at how we can turn identity and authentication a little bit upside down without introducing too much complexity.
So a key enabler towards embracing decentralized identifiers is that they can be used without requiring a whole lot of infrastructure changes. Really all you're doing is pushing the key out into the user's hand, right? Because the last thing you want to do is try to implement some heavy user interface or backend it lifts, right? So, you know, obviously nothing in life is free. You do have to make some changes, but let's take a look at what little really needs to change. So this diagram here on the bottom is your typical IAM stack, right? And John's, what's much more complex and detailed, but if you really boil it down, you have account management authorization, these types of buckets here in the middle, and we're going to move the credential to the edge with the user. So the three components that are required to enable DIDs, decentralized identifiers for customers or for your workforce employees, the first is a digital safer wallet.
And this is typically embedded into an existing app, or you can be handed a new one and I'll cover how frictionless this is in a minute. The second component is an identity gateway. And basically this is a, either a cloud or an on-prem service. It bridges the user to the requesting application. And then it can also make API calls to verify identity information either when they're enrolled or when risk calls for it. So when you put DIDs into workforce or customer, I am functions your organization acts as the issuer and the verifier, if you're familiar with those terms. But what this means is that you don't have to wait for this futuristic network effect to come about, to realize the benefits of decentralized identifiers today, the third piece of the puzzle are lightweight connectors or simple federated login changes. So this allows the dead to be translated into an existing username. For example, your did would be translated into your windows, username, and password behind the scenes without requiring any application rearchitecting.
So if you put the data in the hand of the user, there's a couple of steps involved. First, we give the user an app or enable the did functionality into their existing app via like an STK. And once the app is launched, the users decentralized identifier, public and private keys are generated. And the key is stored in the enclave of the phone. Most times there's a couple of ways to do it and next we'll let the user enroll their existing account credentials. So for example, this is where they'll put in an ID, username and password, or their current banking username or password with their banking app. So you kind of proof them based on their existing authentication mechanism behind the scenes, you're exchanging the credential for a key that mirrors smart card functionality without the need for a smart card reader. And then the fourth step is we'll capture their biometrics.
So we will use from 1Kosmos what we call live ID, where we use the camera with a liveliness test, which can't be spoofed. And then we can also turn on their device biometrics as well, right? Your touch ID and your face ID, which have they're very trusted and liked by the users. So you have a couple options. So the friction for the user is minimal. They're simply entering their existing username and password just like they do today, linking it to their biometrics. And this is the last time that they'll have to rely on hope to get into a system.
And now that we've enrolled in identity, the employee or the customer will enjoy the same experience, no matter what type of service they're coming into, right. It can be a workstation, any webpage, even physical buildings for access control systems. So simply scan a QR code or they'll get a push message. They'll offend a Cate with either device or advanced biometrics live ID. And then lastly permission is granted. So I'd like to give a real world example of how one of our customers uses decentralized identifiers today to simplify the user experience coming into the, to the systems and making life easier for the it department, focusing on a, a doctor prescribing controlled substances here. So as you can imagine, it's a legal requirement for doctors to be verified before they can work with a system like epic, right? And this is where strong identity proofing is done on first touch.
Let's prove that physician and make sure there really are a physician. So instead of taking their documents, driver's license passport doctor's card or whatever, to the notary or to the, the home office, they'll scan their government issued credentials with the app and validated against backend sources in real time. And the security features of the documents are checked and API calls are made to third-party sources of truth, right? Like the federal issuing authority for a stator or passports, then the physicians database is checked as well. So you can check does John Smith, this position card matched John Smith's driver's license and passport. So in a matter of minutes, they're compliant with company onboarding policy.
The next step is for general systems access. So they'll use device biometrics, touch ID, negating the need for username or password they get in the front door of the application. And the third requirement is for the doctor to be fair verified with MFA, whenever they prescribe a controlled substance. So the legacy system had a cumbersome, external tokens as a second factor using a password before that. Now their identity is verified in real time as they authenticate in one step. And furthermore, because a decentralized identifiers can have cryptographic capabilities with them. A digital signature can be stored on a distributed ledger. So now you've got an immutable audit trail, which is also required from a compliance perspective for most systems that companies like this deal with.
So we've, we've covered identity based authentication, right? We know how to get them in the door now, but DIDs can also extend their capabilities to cover verifiable credentials. So this is a W3C standard. John touched on them briefly where he was showing that you could have certain credentials tied to an identity. Basically it allows an organization to issue any type of qualification or other piece of information to somebody. So this isn't just is this person who he or she claims to be, which does do very well, but does this person really have a fine grained, identity entitlement? So common credential types are education degrees. There's a number of efforts among universities and other educational institutions where they're trying to create a digital diploma or like a core certificate. And you as an employer will be able to get a copy of this digital certificate and verify it without seeing the original diploma and then employers themselves can issue employment status, right?
So this has right to work type use cases. And this is another way for organizations to trust who they're working with without having to do heavy federated authentication, tying two active directories together, et cetera. So these certificates get tied back to the original identity. So imagine where your contractors could prove who they are, that they work for a consulting company and link it back to their biometrics. There's no more swapping of usernames while somebody's brother fills in for them. And recently with COVID, the COVID credential has gotten a whole bunch of industry attention. So without a verifiable credential, Traveler's just starting to maybe leave their houses. Now are carrying around pieces of paper that said they had a PCR test yesterday, right? It's almost useless, incredibly easy to forge and incredibly difficult to verify. And when vaccinations come out, there's going to be a need for a trusted digital attestation about immunity that can be used by employers, merchants, governments, airports, et cetera.
And this is a perfect use case for it. So day one, when these credentials come out, your organization can issue a go back to work certificate and they can be verified at the front desk of the building without having to reveal, you know, health records or any other personal information on day two national organizations will plug in and the network effect will start to bring efficiencies across the globe. And this is happening like at the world economic forum level, we're plugged into those efforts and verifiable credentials follow all kinds of privacy principles around identity verification, such as zero knowledge proof. So this is where the original document doesn't need to be seen by the requester. And they also protect the user's identity and personal data and have very powerful mechanisms for sharing the credential revocation and renewal. Right? All those kind of key based app applications are built into the standards as well.
So w one last slide on a real world, verifiable credential in action. So the beauty of did based verifiable credentials is that the same platform that enrolls and authenticates can issue these credentials. So here's an example of a LinkedIn page with employment and education properties, right? We all see these every day. We never know if they're true, like you guys didn't know that I actually went to Oxford there's parts of LinkedIn that already allowed the issuing of verifiable credentials to prove that an individual actually has a certain education certificate. So your organization can participate in this as an issuer or a verifier with minimal friction. And we're starting to see this come out, Microsoft talking about it, obviously they own LinkedIn. So we're very optimistic that this is going to, to be a big enabler. So with that, I'll hand it back over to John. Thank you everybody for listening and I'll see you on the, on the web.
So yeah. Now we have some questions. The first question is, are there standards for identity services? Yeah, there's quite a number of them, actually. Let's see. So some of the ones that we've talked about, we'll go way back. We'll talk about El Def. That's a standard for directory access, lightweight directory, access protocol, SAML security, assertion, markup language. That's the way of representing authentication between different domains. There's, JWC jot Jason web tokens. There's auth is an sort of a federated authorization service and open ID connect, which is layer on top of that. And then, you know, we've talked about Fido as a, I think is a, you know, it's an identity standard. It's a way of specifically being able to translate authentication events between different domains. So yeah, there's a lot of different identity standards and I'm happy to discuss that in more detail offline and can refer you to some other publications that we have about the anything you'd like to add on the standards, Mike.
Yeah, absolutely. I mentioned one standard, the NIST, you know, federal guidelines for identity proofing, it's special publication, 863 dash three. And that covers how you there's three levels. They call it IHL one, two and three, and three is a very strong identity. It's kind of the identity. You need to move money in a bank. So for banking, they have KYC and anti money laundering. They need a level three identity, which is typically two forms of government identity proof that you live at, the address you live at, et cetera. So he entered 63, 3 is, is one, you mentioned Fido and web authen, which are emerging and kind of getting a lot of attention. And the two concepts of did and verifiable credentials are from the W3C governing body. So they kind of tie everything together as well. But yeah, the other ones you hit on, I think that really rounds it out.
Then there are a couple of questions about the slides and presentation themselves. Yeah. They'll be available probably by tomorrow. We'll have them uploaded on the website. And then another question, any comment on S IOP, some reason I'm not getting the context to that. Yeah. If you, you want to follow up with more information on that. We'll, we'll address it here in the next couple of minutes. Next question. I think this was pretty good too. Companies really trust documents, scanning for the onboarding of employees and contractors. Yeah. You know, I, I think my perspective on this, so now I'll let you have a go at it, Mike, you know, there, there are enrollment attacks, I guess we call them for both, you know, IRL in real life kinds of situations where somebody might go to a bank and present a, a driver's license that's forged or something like that. I mean, so there's, there's always a risk, but I think what these mobile onboarding documents scanning does is sort of enable business, especially today because of things like COVID, when it's, hasn't really been that easy for the last six months for people to do things in person, I think there are definitely technical means for reducing that risk that are, that are just as good in many cases as some of the in-person kinds of presentation and document creation and verification. What's your take on that mic?
Yeah. We've been doing credential scanning for quite some time. You know, driver's license passport. It is difficult because take your driver's license. You know, there's 50 different formats in the U S and other, every country has its own format. And we rely on partners like key Singh and my tech to augment what we do and give us a global footprint there. So it's getting stronger on the passport side, we have the chip that we can read off the passport. So that's very difficult to forge and I would say nearly impossible for most actors. And that, what that does is it say it's signed by the issue of authority and it gives you a high quality photo. The other thing is, you know, w the alternative to doing it on a phone is some person sitting at a desk at the branch of a bank, or the auto dealer is trying to do it themselves, right?
And you're when you can apply consistent technology and then possibly go deeper into three, four or five different sources of truth. It really strengthens your chance to know that this person is who they say they are. So as all the proofing government documents mature, right, the states are going digital. There's two states issuing digital driver's licenses. Now there'll be less opportunity for forgery as that matures as well. So it's in the early stages. It's being a mature very quickly, and we like where it is now, because it's better than the alternatives that people have to present scanning, faxing, you know, putting a copy in a filing cabinet. Okay.
Let's see. Next question. A couple of follow ups on the, let me read through this more about identity services, take a up a notch. What about API coding level authentication, authorization create and manage something to hide protocol details? Yeah. You know, I think that there are, well, let's think about OAuth and a YDC. I think there are some profiles there. And I think that relates to the next question about SIO PZ selfish issued there. Yeah. There are profiles, an open ID that I think can help with in that realm, which is, you know, probably the largest percentage of protocols that are in use today in this area, you know, but I think there's actually additional room for some standardization at the API level. And I, you know, I think that's a good question because that brings out the point that if you're using different kinds of products, even different services, you want to be able to abstract the details of, you know, how an API is implemented away from the calling application. So, you know, I think the, the question is a good one because I, it, to me, I believe shows that there is additional need for standardization, particularly, you know, around how to address API APIs for the individual services and an identity fabric.
Do you have any comment on that mic? No. It, it really does come down to your provider of identity proofing and authentication being flexible. Standards-based loosely coupled. So you're not locking yourself in. And for example, you know, why can't an, an API that's relying on, you know, a token, a username, be able to go back out and ask the user, interact with that system and say, I need a higher level of assurance. I need that NIST from this user and kick off a workflow to be able to do that. So it's right in line with the concept of the identity fabric that you had on that, you know, rather busy slide. I think those pieces need to fit in there. And it ties into the API that you're mentioning.
The next is a clarification about SALP it's the extension of OITC where did is, can cause OAuth tokens to be self-generated. I don't have, I haven't delved into that too much. Have you looked at that Mike in context of did?
No, I haven't just, just being honest. I, you know, we, we use OITC for authentication and typically this is the type of thing that our, our CTO we're on Pinto would get deep into the weeds on I think. So I'm gonna have to take that one offline and I have a little bit of education to do on, on that one, another acronym for us to add to the mix. I like it.
Well, yeah. You know, the OEDC space is very, very active right now. And then there are lots of profiles, you know, that's opportunities there too, because there was a potential complexity with keeping up with, with protocol changes. And I, I will say I w w w one of the things that I really liked about what open ID is doing is offering certifications for products and that space, that support different parts of that. I think that's, it's really necessary in the standards world. They kind of going back to the other question about standards. I think certification for products is increasingly important because it's one thing to say, you know, I support the standard, but then, well, what part of that standard do you support? And, and are you keeping up with it? Because even though the, the standards writing process can, can take a while, there are enough of them that there are substantive changes that come out, you know, from year to year, that that require vendors to keep up to date with it. So, you know, merely saying that you support X standard without some sort of really a third-party demonstration and certification of that, I think is very important.
Next question. Is, are there any enterprise business problems, the decentralized identity is a good solution for the well-known use cases seem to fall into B2C or GTC? I, I, yeah. I typically like to use B2C and GDC use cases as examples. Mike, you started to hit on some of these as well. Would you want to go into any more detail on sort of the, the use cases there for enterprise?
Yeah, yeah. Actually, if you, let me share a screen, I've got a picture worth, a thousand words on this one, and that's, that's a key enabler, the benefits of decentralized identifiers and giving the user the key can really simplify the, the whole stack that you have. So if you move away from usernames and passwords in the enterprise, there's a couple of things that happen first is your fixing the user experience. So usernames, passwords, changing, forgetting, et cetera, or, you know, one of the biggest detractors for your net promoter score is if you check your users on these experiences of their internal systems. So I mentioned the binding, you know, getting their active directory, username and password, and then using that internally, we will apply that, that seamless passwordless experience to windows as they sit down for the first time, you know, at their, in their chair, remote access VPN.
And then from there, let it hand off into Okta or painting, et cetera. So you don't even need a username and password to get into those systems. So it's not just for customers. In fact, some of the quickest benefit of this technology is for workforce, because you can measure the ROI at your help desk level in two months, right. You know, you had 200,000 help desk calls in, in 2019 X number per month. Just measure it once you get rid of usernames and passwords, that number will come down and, you know, the analysts all out there put the cost of a password at that between 25 and $70, depending on the cost of the user, that's getting locked out. So yeah, we're seeing this being the first place that DIDs are being used today is in, in the workforce. And again, Fido, which is all over is a, is based on the concepts of it, did it just doesn't bring any identity to the, to the solution. So we're very optimistic that that workforce is going to be a big enabler for dads as well.
Yeah. There's another great question here. Any comment about how the UIX needed to affect fine grain in user consent? Yeah, I think that's a fantastic point. And actually we're going to address privacy and consent in this Casey live tools choice event coming up on October 20th, we've got leadership compass and additional research documents on privacy and consent management platforms and how to put that into place, because yeah, I mean, there, there, depending on jurisdiction, there are differing needs for collecting end user consent, particularly for the use of specific attributes, you know, GDPR and now CCPA are getting a lot of attention, but those, those are just two of many different privacy regulations that even though they may be similar in some ways we'll probably wind up having different implementations. So yeah, I think that's, that's, that's a whole other subject that we can start to address and then the Casey live tools choice and happy to, to discuss that with you offline too. One more question, and I'll, I'll drop this one on you and Mike it's about what's the performance performance overhead that, cause I'm assuming it's talking about the, the did use cases and attribute enrichment that you were looking at. Can you say anything about how this performs?
Yeah, it's, it's a very lightweight exchange. So take the example of going to a banking website. First of all, the, the performance from the user experience is much better. You're typing in 20 digit username and password, and then go going in fetch you're at MFA out of band, whatever, right. That's probably a 10, 20 plus second exercise. So then the user's doing it in two seconds. All right. Scan a QR code, or, or get a push message touch ID in their end. And the is there's really no overhead no more than there is, you know, pressing enter and verifying hash is, is a very, very lightweight exchange. And typically these designed these systems are designed to scale horizontally as well, if they're properly designed. So performance really isn't an issue and yeah, that's, that's pretty straight forward.
Well, great. That looks like the last question that came in and we're at the top of the hour. So one of the thank you Mike, for your time today and good information and thanks to everyone who attended and all the really, really good questions here.
Great. Thank you, John. It's fun to be in here.
Great. Well, thanks everyone. And yeah, these slides and webcast should be up in the next day or so, and join us for our next, thank you. Have a good day. Take care.