Four Stages to Building a Passwordless Enterprise
Unlock On-Demand Webinar
All right, everybody, I think we're about four minutes past, and I think we can probably get moving here. So, welcome to our 1Kosmos webinar. Today, we're going to talk about the Four Stages to Building a Passwordless Enterprise.
I'm Rob MacDonald. I'm the VP of product marketing here at 1Kosmos. I've been here for probably little over a year and a half, and I'm joined with my bestest friend Javed. Javed, why don't you introduce yourself and tell us a little bit about what you do here?
Sure. Hello, everybody. My name is Javed, Javed Shah. I run product management at 1Kosmos, and it's obviously really exciting to be co-hosting this webinar with Robert here. Hopefully, we can shed some light into how to really do passwordless correct, to do it more securely, and to not just rely on a record in a database somewhere to say that that is indeed your identity. Hopefully, that message is what we get across, Robert, right?
Yeah, absolutely. Just full disclosure, this is a presentation that Javed and I gave at Gartner. So, if you were at the Gartner IAM Conference, we had a presentation that we held there, and we wanted to give it to a broader audience. So, these are essentially the slides that we used at that session. We thought it was good information that others should be able to take advantage of, so let's jump in.
Before we get deep into things, let's just quickly talk about how you can connect with us. We have a number of events going on over the next probably month and a bit. Actually, just May in general is pretty busy.
We've got the RSA Conference, which we just did. That was this week, so if you were at RSA and we ran into you there, good to see you again. If not, maybe we'll see you there next year. We have EIC coming up, that's the European Identity and Cloud Conference. That's in two weeks. We're going to be in Berlin for that with the folks at KuppingerCole. That's going to be a whole lot of fun.
We've got Identiverse. That's the end of May, May 30th to June 2nd. We've got the Texas Bankers Association, that's happening... When's that happening? That's happening May 17th to 19th, and then we also have Finovate, which is May 22nd to the 25th. And I don't think I mentioned what the dates of the EIC was, that's May 9th to 12th.
So, we have a bunch of events that we're going to. If you're going to happen to be at one of those, we would love to see you, swing by the booth. You can even book a meeting with us through our website. If you go to our events page, you can book meetings ahead of time so you can have everything lined up when you get there.
But if you're going to be at one of those, please swing by the booth and say hello. I might be there, Javed might be there, and of course, we'll have a whole host of other 1Kosmos people at those events as well.
Oh, I clicked on... There we go. So, another way you can connect with us if you like, Javed and I, we have IBA Fridays. It's a LinkedIn Live thing that we do. It's hosted by myself and Javed. We usually bring on some special guests and we talk about things that are happening either within our own platform or things that are going on in the market.
So, if you like the banter that we typically have, you'll get a little bit of that today. We have just short 15, 20-minute LinkedIn Live sessions that we host ideally every other Friday. So, every two weeks, but sometimes schedules get in the way, and it stretches a little bit longer than that, but for the most part, every two weeks we do a LinkedIn Live. Did one last week, we have one coming up again next week, so you're more than welcome to come in to do one of those.
And then after this webinar's over, we have another one. So, next month, May 18th at 1:00 PM Eastern, same time as today's, we have a session that's around the future of digital healthcare services, improving convenience, cost, and security.
So, it's going to be a combination of 1Kosmos and IC Consult, one of our partners. And Max from IC Consult is going to be on with our product manager Sheetal, who works for Javed coincidentally. They're going to go through and talk about things like the future of healthcare, new ways for providers to gain quick and secure access to systems while also being able to give patients control over their own information. We do some work with the CARIN Alliance, so we're going to go through some of that and talk about all the great things we've got going on there.
All right, so on that note, let's jump in. This session or this presentation is really around passwordless, but you can't talk about passwordless without talking about passwords. So, why are we still talking about passwords? Why are they still here?
Just to be clear, when you look at the shift in the IT space, I would say, Javed, and maybe you can back me up or maybe disagree with me here, but I think the technology, in general, has turned over a couple of times. We've got new ways of securing things, we've got new technologies to do all kinds of cool things.
We have a monitor, and watch, and secure, and authenticate. There's all kinds of cool things that we can do, but we're still using passwords, which was basically the very first thing that was developed from a security standpoint when they were trying to figure out, "Well, how do we get these shared terminals... How do we get people access to their own data and not somebody else's? Well, we use a username and password. They'll be able to get in and get access to only their stuff." That was the very first line of defense ever, and 60 years later, that hasn't changed. Am I wrong?
No, absolutely not. Actually, wasn't it at MIT if my-
It was, I think.
... memory serves me right. The password did turn 60, so respect, I guess, I don't know. I mean surviving that long in the software business is quite amazing. But I guess the reason probably why it continues to... I don't think it's thriving, in my opinion. I think the reason why it still exists and probably is on the way out is because of legacy applications. And the word legacy should not have a negative connotation here. They just, they're already-
They're there. They just exist.
They're there, they're being used, and it's hard to change applications. It's hard to change your services simply because you want to grow as a company. And I think we're going to hit on one of these really important points of coexistence later where we try to figure out.
That's right. Yeah, yeah, we absolutely are going to talk about that. I look at it like this. I'm a marketing guy, so I like to use pictures and use different ways to describe it and try to be creative in terms of why. Why? Why are we still talking about usernames and passwords?
We just expect them to be. Just like we expect the sun to rise every morning and set every evening, we expect that to happen. So, every time we go set up a new account somewhere, we just expect that username and passwords are going to be there.
There has been little in terms of our expectations in that we can do it differently. We can do it without passwords. We've been talking about it, but there really isn't a lot of it in full-on deployment yet, and there's a reason behind that. Well, we think there's a reason behind that.
We're going to talk about that here in a little bit, and that goes back to the coexistence thing that Javed talked about. But in a lot of cases, just expecting it's going to be there shouldn't be the way... Or being complacent that it's going to be there shouldn't be the way we really think about this.
We really do need to take a new approach in terms of how this stuff works. And the fact that we've accepted them as the norm shouldn't be okay, but that's where we are today. Now, that's going to change, that's going to shift, and we're going to talk about that.
And when you make that shift and you're able to figure out, "Well, who actually is that user behind the device?" You're able to tackle some pretty big issues. You're able to eliminate phishing attacks. There's nothing for somebody to steal, nothing for somebody to give away, nothing for somebody to share that goes away.
You're able to know who's authenticating, so once you know who that user is... And we're going to talk about what we mean by knowing who that user is because it's not just something like, "Oh, we're going to onboard a user and give them a multifactor authenticator and we know that it's Javed." That's not the way that works, and we're going to talk a little bit about what we mean by that here in a minute.
Being able to have users control privacy, third-party and contractor onboarding, contract hijacking, that stuff... These are all things. All of the issues that are on the screen here I'm sure you've seen some of these, you have some of these that you're trying to tackle, or maybe there might be a new one there going, "Oh, I never thought I could do that."
But there's lots of things that you can do once you move from this username and password experience where it's all knowledge-based, and you take out that human element and get it to something where you're identifying the identity of the user. And that's where we're going with this.
So, when you look at... We talked just... Not last slide but the slide before that about the fact that there's not a whole lot of passwordless around. We talk about it. We talk about getting rid of passwords, we talk about going passwordless, but there's really not as much of it around as maybe we think there is.
And there's a couple of challenges that pop up when you try to move passwordless. The first thing is there's no convenient way to really roll out a consistent way of doing it. Especially when Javed mentioned earlier, when you get into things like legacy systems. How do you address that? Because if everything else goes passwordless, there are going to be some things within the infrastructure just because you've built it over decades that you may not be able to go passwordless.
So, how do you do that in a way where you can roll it out and still have people do what they were doing while you either enroll different departments, different groups, different users? And still have people be able to do their day-to-day job without blowing up your help desk because on Friday they logged in with a username and password, and on Monday, they're presented with passwordless, and they don't know what to do.
So, the next big hurdle is being able to tailor the security controls and deploy them in stages that are aligned with the business and IT objectives that you put forth. When you go in and you undertake something like a passwordless initiative, you have objectives, you have goals. You have a plan in terms of what you want to accomplish.
And being able to tailor the controls around all that stuff and do this in a way that aligns with where you're going can be difficult. And these are two of the bigger hurdles that we see organizations run into when they're going passwordless.
So, there's two slides here. We're just going to try to level-set everything because when we talk passwordless, there is really two different ways you can go about doing it. And Javed, I'm going to hand this one over to you because I know that you want to dive into this, but there's a device-based way of doing it, and there's an identity-based way of doing it, which is the way we do it here at 1Kosmos.
Do you want to talk a little bit about those two approaches? And then we're going to jump into another slide to dig a little bit deeper into it.
Sure, yeah, so it's very interesting now, isn't it? Although it's quite ubiquitous, it's everywhere. Things like, well, I just sent a text to your phone, Robert. Enter the one-time password from there. Well, the problem with that approach is that your phone could be stolen. There could be a man in the middle somewhere, for example.
So, the current approaches are really broken. The current approaches to password authentication, passwordless authentication, they rely on proof of possession of the device, really. They rely on proof of possession of the device. They don't really come down to, well, is it indeed Robert, or is it indeed someone else whose identity was vetted and the person who was actually registered?
So, it's either a FIDO hardware key, or it's a smartphone with onboard biometrics, or it's your PC with the camera attached. But these approaches obviously are binding, and to your point, about binding the authentication to the device and not really the identity.
So, it's interesting that the preferred approach, and it's emerging, and even the analysts are talking about that. The preferred approach is to bind the authentication to services and applications instead of the device, is to bind it to the identity of the user.
For that, you have to obviously build this construct of verifiable identity. Only then you may be able to verify it day one onwards, but on day zero you have to build that. So, the first step really is to build the verified identity for the user by proofing them. There is no other way.
You have to proof the individual using either a driver's license or a passport or some other sanctioned government-issued identity document, and store cryptographically verifiable proof. Including the high-res image if one is available on the TPM of the device. That is a step that is further along the journey of binding the authentication to the identity of the user and not binding it to the device itself.
The second step, and I think this is really key, and we've obviously worked very hard here at 1Kosmos here to achieve this is to also check for liveness of the user. If you proofed a user and you have a high-res image stored safely encrypted by the individual's private key, no administrator in the world has access to it.
And then you're checking for a confirmation at authentication time that, yes, you indeed are live right now while you're trying to access this service. And the image, the face you are presenting matches with the face, with the image that we captured from the government issued at the time of registration on day zero.
So, day zero you onboard a user, you proof them. Day one and onwards, you authenticate them, ensure liveness, and make sure it is indeed the same person. And I think this trifecta of things, this comprises the journey that takes that solid step towards, okay, now we really do assert that the authentication is bound to the identity.
And you can do some more fun things with this Robert. Now that I know that it's indeed you and I know the type of device you might have used to proof yourself, I can actually assert, to use the NIST terminology, that you are at an assurance level perhaps. At an identity assurance level of two, for example, not just one. One would be you didn't present anything, for example.
So, that's a very nice journey-based approach to shifting focus away from authenticating based on devices and having just position of devices. Shifting those over to an assertion on identity itself, which represents a more mature secure passwordless journey, Robert.
Absolutely, and a far more secure journey on top of that. So, just as a follow-on to that, Javed, those small differences, because if you think about that, you're like, "Well, device-based. I mean the user has a device, so there is an assurance level that goes along with that to some degree."
The small differences between the two does make a big improvement to the overall security posture, in some cases even the user experience. When you look at a native device-based biometric versus an identity-based biometric. And I'm going to build out just the rest of the slide here and let you talk to some of the things that we heard at Gartner.
Because we know that Akif talks at length about some of this stuff. So, when you look at a native device... Let me try that again, a native device biometric, really, you're just affirming that there is an identity there. Not that it is the identity, but there's someone on the other end of that thing.
Versus when you get into identity proofing with an ID-plus-selfie, well then that's a whole other animal. Why don't you get in and talk a little bit about where the market's going with this and what the analysts are saying about it maybe?
Yeah, very interesting, obviously, how you phrased this and how you framed it as well. Affirmation is not the same as assertion that you are indeed you. Remember the iPhone we used to log into our Gartner booth for the demo?
Yeah, we had five fingerprints registered. Yeah.
Everybody just came along, registered their face ID, touch ID, and... That's possession of device. That's a classic example, a booth demo is a classic example of affirmation of someone opening the device, which then opens an app or opens a demo web portal so to speak.
Proofing is obviously the other next level of, "Okay, let's actually make sure the person presenting themselves is indeed the person we onboarded." And Akif Khan, a very well-known Gartner analyst, it's very interesting how he's dedicated at least three to four years into this ID-plus-selfie construct that he's been obviously... Not just preaching about, but he's been gathering his intel and obviously coming to this conclusion having traveled the whole world that this is indeed the case.
When you register an identity, day zero, again, day one onwards you present yourself for a liveness check and for an image match. Which then does indeed solve those day one onward problems where you're not proving possession of device.
Of course, nothing is perfect. Not everything is served on a platter, unfortunately, so the day zero problem does exist, Robert, where I do actually have to proof you. Which means you need to have some sort of a sanctioned government-issue identity document.
But those challenges along with... Like I said before, those challenges are somewhat fading with better technology, higher-res images, the fact that cameras are getting really better now in the smartphones across the platform stacks as you already know.
So, they will make a huge improvement for that day zero journey, but I think generally speaking, to summarize the slide, it's really important that the hard privacy construct that we had implemented here at 1Kosmos where only Robert has a key pair, a private and a public key. Only Robert has the private key on his device, using which he had onboarded.
So, no one else has access to anything that is encrypted with that private key if it's stored in the TPM, literally unbreakable rooted TPM of that device. That's really important, that's one. Having liveness and in some cases anti-spoofing depending on the resolution of the image, obviously, Robert, really helps to really put the second emphasis on this idea that day zero is not as hard to do for binding authentication with identity.
And I think dynamically being able to assert the IAL level, the identity assurance level is really important. It's not just about, Robert, you having IAL 2 because you brought your driver's license. Well, tomorrow your DL may expire, and then maybe some application, some services that you're consuming is part of either a workforce journey or even a customer journey, doesn't matter, that do require you to be in good standing with whatever, whichever government entity that issues you that document.
If your document has expired, you're not in good standing anymore even though you may have day zero registered with 1Kosmos. So, our platform offers the ability to dynamically assert that, tracks the expiration, and this is continuous trust. There is no higher version of continuous trust that is in the market today, Robert.
Yeah. No, I mean it's super cool stuff, and if you're going to make the jump, then there are two options. Look at what certainly works best for your organization, especially when it becomes super difficult with all of the different platforms that you have available.
In a lot of cases, it's like, "Well, where do I start?" I got stuff in the cloud, I got stuff on-prem. I got stuff that one company just acquired another, and now how do I... So, there are a lot of different elements at play, and looking at the different applications you have, the different levels of risk you have, what are some of the considerations here, Javed?
Do you think that this is just a smattering? This is a one one-hundredth of the applications that are likely available. But coming where you come from, what are some of the things that people should look for here?
Such a difficult question, but I mean look at the fabric here. This represents a solution coverage area that spans multiple domains, different use cases, developers-
And probably a whole bunch of different authenticators on top of that, right? There's probably authenticators on each one of these things.
Absolutely, look at the use case surface here. We're talking about all kinds of different application needs or end-user needs represented here, which generally means that a large company that probably has all of these applications or all of these services, or some of them at least, would be required. Okay, I should change that, mandated by regulatory pressures almost to add a semantic authenticator. While a Microsoft Authenticator may already be in the business, add yet another authenticator for passwordless. Get something else for a TOTP code.
So, it's a proliferation problem at this point of authenticators themselves, Robert. I mean just imagine that. We're not talking proliferation of passwords anymore. We're talking proliferation of agents, entities that solve technically for passwordless with MFA maybe potentially. That's a problem.
I was going to say, I would challenge everybody on the call right now to look on their device and say, "Hey." Just type in look for authenticators and how many pop up? I guarantee there's more than one.
At least three.
So, let's take a look at that complexity, Javed. If you look at it from a workforce perspective, everybody's like, "Well, I got single sign-on. Why do I need something like what 1Kosmos is pitching or whatever?
When you look at single sign-on and the providers, there's no cohesiveness in that. So that patchwork approach is destined to fail. Talk about some of the complexity and where identity fits in, and then I'll jump into the next slide to maybe illustrate that a little better.
Sure. I mean you already know that I worked for one of those companies in the first-
So did I.
So did you, actually. There you go. So, we shared that legacy and history. It's interesting, SSO providers who also call themselves identity providers key off of Robert's and Javed's identity based on a database record, an LDAP record, or a record somewhere. That record suddenly becomes the central point of all of those other upsells, all of the other accesses granted to either Javed or Robert.
So, it's very easy for someone to say as long as you have access to my record in a database, let's say to wrap a quote, unquote, identity manager SSO system solution on top and then federate access for me for a VPN or some other business apps or Linux and so on so forth. But you started with a database record, that's it.
And there is no journey-based harmony on, "Okay, Robert should not have to authenticate differently to a service that requires one type of authenticator, and to another service that requires a different authenticator because that service chose to integrate with a certain style or a certain type.
So, all of this, what we are really doing is that we are starting with not really an identity, but a record, adding complexity. And this entire fabric I think it sums it up very well here where it says you create complexity, but it still lacks identity, right?
Yeah. Yeah, absolutely. All right, so that's... Now things don't want to change... There we go. All right, so Javed, when I inject our identity, the 1Kosmos identity into this, what does that do for me? Let's talk about this one.
So, I'll use the analogy day zero is really important. Where you begin is important to ensuring that the passwordless access you're granting, given this is a passwordless webinar. The passwordless access that you're granting is indeed to the person who presented themselves on day zero to register themselves with the company.
Starting with identity is really, really important, and for us, in order to do that, as explained before, if you're able to build because you presented your government ID. If we're able to build a verifiable identity for you, we're also able to build a reusable identity for you.
Which means that you technically do not need all of these various authenticators, all of these various identity management solution wraps potentially to get access to services. You simply follow that same paradigm, which is you register yourself, we build a cryptographically verifiable identity for you, then we check for liveness for authentication purposes, and you get in.
And then we dynamically also assert on a rolling forward basis that you are in good standing for the document that you used to register yourself. So, that dynamic assertion, because you began with identity, the continuous trust makes sense because we are testing for your continued validity as a holder of that sanctioned document. That really helps.
Yeah, absolutely. I mean I watch my wife log in every morning, and she authenticates to get access to another authenticator. She authenticates to authenticate again to only... So, she's username, the password, 2FA, to a token, to... It's crazy.
So, from an experience standpoint too, even just lost time, I mean it takes her 20-30 minutes to log in every morning. It's pretty crazy, and just from a user experience, it's something that needs to be considered from a workforce. Not to mention CIAM, so customer identity and access management, which is what we're going to talk about now. Because if you create a poor experience and your competitor down the road doesn't, guess where your customers are going? Down there.
So, why don't you talk a little bit about the experiences behind some of this stuff, Javed? Again, the place that we came from focused a lot on the CIAM side of the house. So, talk a little bit about that.
Yeah, so it's interesting. Obviously, there's vastly more complexity on the workforce side, but the journey and the reduction of friction is really important on the customer side, obviously. You absolutely nailed it when you said that the more hurdles I present to an end-user, the less viable I make continued use and adoption of the service or the applications I'm trying to serve.
And I think what's really important here to understand is that the 1Kosmos capability, it's not pigeonholed into, "Okay, you did the proofing and that's it." I think in order to interoperate with all of these different, not only systems on the workforce side, but also to provide a journey-based, a tailored journey for the different end-user use cases on the CIAM side, we also do need the ability of potentially a one-time passcode. We do need it. You cannot run from it because otherwise, you end up adding more friction to the end-user.
The end-user is also learning, actually. This is something that is generally not discussed in passwordless webinars, Robert, that you're training the end-user also to trust a passwordless solution. But you can't just change everything in one go. It is okay for a period of time to continue to send that one-time passcode to the phone for the user to gain familiarity with, "Okay, I get it. You're going to phase this out, but for now, yes, this is an experience I remember, I recall."
So, I think, for that, obviously the platform has to have the capability, which the 1Kosmos platform does, to be able to continue that familiar journey for a while before sunsetting that journey and cutting over the user gently. And I think that experience is better than a cold cutover. You wake up in the morning and you suddenly see a QR code, and you have no idea what to do.
No idea. Yeah, no idea because if there's one thing that people hate more than passwords, it's probably change. So, you have to be able to manage that. We're going to talk about that when we get into coexistence, but let's quickly talk about being able to build that customizable user journey, and what that does. And then based on the way we do things, what does that mean for the future? Can you quickly run us through that?
Yeah, sure. I think the customizable journeys for end-user use cases, this construct has been around for a little bit. There are companies in the industry who bring an orchestration capability to the plate where an administrator, for example, for a large company serving insurance is able to customize journeys based on not only what the user is looking to do but also what the user has been doing for a few months, for a few years. And then taking external signals based on the current conditions in the environment potentially to make decisions.
Now, in order to take this forward and be able to draw from those signals and learn from them is where I think it positions the 1Kosmos identity platform very well to be able to solve for common issues such as account takeover attacks, synthetic identities.
Just think about it. We didn't even mention contract hijacking in the workforce slide because we just missed it, there is so much to talk about. Just the distance between, Robert, you scanning a QR code. The distance between where that web page rendered the QR code from where you holding your device is reading that QR code. That distance is something the 1Kosmos platform can track, and you can calibrate for risk.
So, just imagine, right? Now, synthetics is obviously a little bit of a troublesome area in the industry generally, Robert. It is really hard, generally speaking, to establish diversion, or to establish a pattern of behavior that resembles, "Okay, this is definitely synthetic identity fraud I'm looking at."
For that, you need very, very domain-specific data from past failures to build out a model that learns from what was reported as a synthetic fraud before to continue to track and detect in the future. Anyway, so that aside, pattern recognition aside, you can still do major anti-synthetic fraud. You can achieve good capability within the 1Kosmos platform with things like SIM binding, Robert.
I know as long as after your consent I'm able to bind the SIM of the device that you're using, Robert, to your profile. So, the next time around when you show up, you not only have to pass the liveness test, the ID-plus-selfie construct from before but also, we check for whether the same SIM that you registered is what you're using now to log in.
So, that's really interesting because, for that, we have to use a reflector pattern, the SMS gateway that confirms, yes, this is the number indeed, and let's bind that SIM with your consent to your account. So, that's very interesting that SIM swapping, anti-SIM swapping patterns are really, really important to have in your platform. Especially if you're looking to be taken seriously in the banking and financial services industry as we know already given our clientele.
Yeah. Yeah, absolutely. And then, so just from a future-proof standpoint, you didn't really touch on that. Once you do that customizable user journey, as we look to the future, Web 3, whatever that's going to look like. I mean we have an idea the construct of that with the decentralized web and verified credentials and all that kind of stuff.
What's the web and mobile wallet? What does that mean? Just take two seconds and just quickly talk about what we mean by future-proof there.
Thank you for reminding me. Yeah, that's a huge, huge area. It's exploding. Because the 1Kosmos platform is able to recognize and establish a verifiable identity, and like I said, draw a reusable identity from it, what that really means is, Robert, I know who you are. And I know that at an assertion level of let's say IAL 2 to remain NIST compliant, that I know you truly are the person who registered and you're trying to access this service.
Now, what we are able to also build is a verifiable credential for you, and present a portion of that credential, for example, to services. Now, for you to have mobility as... We love freedom, we love mobility, we would love to be able to use any service we like without having to register again and again, correct?
So, I think this concept of wallets, which obviously we support. And we support multiple channels on wallets, web and mobile included, able to carry your credential in your wallet, which is completely cryptographically sound because you can encrypt it with your private key, I don't have access to it, and then store it in the TPM of the device.
So, the future-proofing side of this is that not only do we start with the identity, Robert. Not only do we minimize the number of authenticators companies have to deploy to gain access to services, we're also able to provide custom-tailored journeys to prevent ATO, to thwart synthetic fraud, to thwart SIM swapping but we're doing it using a multichannel approach using constructs such as the wallet, which is a data structure that stores the proof of those verifications that we have done for you.
So, you, the end-user is a bit more mobile, and you have more freedom to sign up for services and have 1Kosmos attest that, yes, this is indeed Robert who's trying to gain access to let's say an HDFC Bank account. We know because here is the verifiable credential we have for him. Let's present it to the bank.
Or if we want to offer a new service that maybe might need a IAL level 2 we can walk them through that journey that's stored in their wallet, gives them instant access into that new service kind of thing. So, it's a concept, really bring your own identities to some degree.
Everything we just talked about from an experience standpoint, I tried to go to Dallas. I live in Ottawa, Ontario. The prices that I was getting at some of the Canadian carriers were a little bit expensive. I have an account with United. I tried to go book a flight with United, but I couldn't remember my username and password, and the reset wasn't... Anyway, it was a bit of a nightmare.
So, I was like, "You know what? I'll go back to Air Canada. I know my username and password, I know what that is." I logged in, I got my 2FA, entered that in, and I was in. So, what happened there was because I couldn't remember the username and password for the United one, I went and spent my money somewhere else. It was actually 1Kosmos's money, but that's beside the point.
But that experience, and I don't know if there is a metric or a measurement that organizations can go through, but if you're not giving the right experience to that and I have to reset it every time, my wife resets passwords every day, it's crazy.
But if we start to get rid of some of this stuff, the engagement level of customers will likely increase, and they'll potentially end up buying more because you're likely not tracking all the times that this scenario happened on your website. And that's why this stuff is ultimately important.
Anyway, we only have about 10 minutes left, Javed, because we want to get some questions in before we wrap up. Just quickly, when you look at the before state: identity, authentication, and data silos. When you look at the user enrollment, that's usually a one-and-done scenario, or if you do do it, you never go back and redo it.
And that's like Javed was saying earlier, when documents expire, do you ever really go back and get them to reverify? Not normally. So, when you move that into the user authentication standpoint, we're not leveraging anything we learned in that user enrollment during the authentication that takes place, which is what we've been talking about using that facial biometric. Doing the ID-plus-selfie.
So, combining those two silos makes it a significantly more secure experience. And then when you look at privacy controls where user data is... It's scrambled, it's everywhere, you don't know where it is. Who has access to it? Who doesn't have access to it?
When you look at the approach that we're bringing here, you unify these three pillars together where you do the ID proofing, which then gives you a high level of assurance that that user is how they claim to be. And then you also give them a digital wallet where they're able to control and manage their data on their device through that TPM with the public and private keys where it's encrypted, buried deep. And it eliminates a lot of pressure and cost and just churn within the organization being able to combine all those together.
So, Javed and I have been talking about this concept of coexistence. If you think about those three things that I just talked about previously, and you decide, "Yeah, okay, we're going to go passwordless." And many of you were probably already thinking about, "Yeah, we're going to do that."
I ask you, is this a all-or-nothing type scenario where you've got to go and rip out everything you were doing? Because if that's the only option for you, it's going to leave holes and gaps because there are things that can't go passwordless, so how are you going to manage that? Different authenticators, different company doing that, what does that look like?
But from a user experience, whether it be customer, whether it be workforce, it's irrelevant. We have a customer that does show... We have a number of customers, actually, that show this exact screen. This is a demo screen that we do, but this exact screen where users can either log in passwordless, or they can continue doing the way things they've been doing it.
And that coexistence eliminates the burden on help desk because if it's I do the thing on the right on Friday and everybody comes in and does the thing on the left on Monday, that's going to be a nightmare. Because people are either... They probably didn't watch the training videos, they didn't know it was coming, whatever.
So, don't set yourself up for failure. Set it up in a way that everybody's going to succeed. We have a customer that has done just this, and the employees that are doing the stuff on the right have been curious about the stuff on the left and have been asking people. And they started self-registering themselves for the passwordless experience, even though it wasn't required for them or their business unit as an example.
So, this concept and idea of coexistence is really the way to drive success within the organization because it enables you to roll it out at your own pace that the organization from a risk standpoint is comfortable with. And it's not going to impact the day-to-day business. It's not going to impact users at a high level. And it's going to generate curiosity about what's going on on the left.
And then once people understand what's coming, they're like, "Oh, I can't wait for that because I don't like doing this stuff on the right. So, it builds some momentum within the organization, and like I said earlier, if there's one thing that people hate more than maybe passwords, it's change. And if you can manage that change, you're going to have a whole lot more success rolling this stuff out, right, Javed?
Okay, so just quickly, when we look at our own customers, they typically start in one of three areas, and we help them with just an authentication enhancement. So, they want to streamline, they've got too many authenticators. They want to bring that into one platform.
So, they have either one app or just one way of offering the multitude of maybe different authenticators that they have, and that includes stuff that's in the cloud, stuff that's on-prem, whatever that may be. Or they just want to jump right into passwordless authentication and get their feet wet. We help them with that. And again, it's up to your organization, where you are in that maturity level.
Or the other one that we see a lot of are the people who are just like, "You know what? I just got to get my users onboarded properly. Data's everywhere, I got third-party contractors coming in. I have no idea if that's the person that's actually doing the job after we brought them in. So, we need some help trying to onboard users and get our arms wrapped around who's actually coming into our system."
And those are typically one of the three ways that organizations start with us as an example. Anything to add to that, Javed?
No, no, perfect.
All right, so your road to passwordless. How are you going to secure your passwordless rollout? There are a couple of ways that you can look at doing that, and it ties right back into the slide that I had previously on here. So, Javed, do you want to just quickly talk about the different ways users can go about doing this, and then maybe what that futureproofing looks like when you work with a company like 1Kosmos?
Sure, really quickly obviously because we do want to take questions.
Exactly, so I think the day zero journey of really bringing in those users is really where the friction normally is. As we have seen from our own findings as well as from how the analysts describe this new journey that folks need to start looking at like Akif always talks about.
It's interesting. Your enrollment could use existing accounts. Other types of identity accounts, just corporate identity, bank identity so to speak. Even there's national identifiers now, Robert, that... I mean Europe is a great example of national identity being a thing and being positioned to be onboarded for a service cross-sell and things like that.
And we already mentioned sanctioned government-issued documents as a starting journey for something that 1Kosmos platform supports. So, you identify and you onboard users based on the different types of identity available. That's your set of new users.
Now, it's really important to also think about the coexistence strategy where you do want to slowly phase out existing factors, schemes of authentication, username and password included, but then also lure end-users to... Unless they're mandated to in the workforce setting, obviously, lure them to explore, investigate, "What's a QR code? How can I use it? How safe is it?"
And obviously, we take care of all of those things. Our QR codes are secure. Our platform manages encrypted travel of data between service and between platform.
So, there's so many different factors available. FIDO, we haven't even spoken about it, but it's really, really important. Obviously, we support that. We support that in a Web 3 setting actually where every individual has a DID. And even the authenticator that we're using for FIDO purposes is bound to your true identity, a proofed version of identity, at which point you have a DID as well.
So, that's interesting because we check for linking and unlinking of DIDs. I already said that we proof for IAL, but we also collect AAL information. This is all NIST terminology, authenticator assurance levels.
We track dynamically, Robert, whether your document expired, or if your AAL dropped because that does factor in what types of services you may or may not be maybe be allowed to access. And native onboard biometrics are their step one, so touch ID and face ID to unlock your wallet before you may be ready to then do live ID, which is your ID-plus-selfie construct to gain access to service.
So, we build support for all of that, and I leave it here because the future-proofing aspect, Robert, we already discussed.
That's right, that's right. And again, single platform for both workforce and customer use cases. And with those flexible levels of the identity assurance that Javed just referred to, and then the different ways that users can authenticate, it's a great way to bring everything into one common experience, which is also another critical step.
So, just quickly, again, don't forget. We have a number of events coming up that we'd love to meet you face-to-face and chat more. Don't forget our IBA Fridays. Javed and I, we got one next week, so I recommend you go follow us on LinkedIn and you'll be notified when we're live.
And then we have another webinar coming up next month around healthcare, so if you're interested in that, please go to our website and register. Registration is open and ready to roll for that one as well. So, let's start taking some questions. Let me go get some of the questions here. Hang on one second.
All right, so Javed, there's a question here, I'm going to paraphrase it. It talks about documents and document scanning. How do we go about accomplishing that? It's asking how do we check if documents are real and not photocopied?
Yeah, good question. Robert, we didn't even mention the AAMVA type of an integration.
We didn't. Yeah, let's talk about that. That's a good point.
So, for driver's licenses in the United States, we integrate with AAMVA, and do not ask me to recall the full form now. Oh, goodness, it's-
Yeah, I forget too. It's American Automobile-
Very simple, DMVs expose an API, okay? All the DMVs in the country. Not all, 48 states expose an API that you can call to validate that the driver's license is valid and it returns not only the validity of the driver's license but also the identity information that the DMV has on record.
So, this AAMVA is a wrapper. What is the full form of that? Automobile Administration-
Oh, I have it. No, I have it here. It's American Association of Motor Vehicle Administrators.
Motor Vehicle Administrators, there you go. We have an API integration with them. It's a highly available API, fully redundant for East, West, wherever in the US, and we are able to tell you, of course, that your driver's license is valid, not valid. And the identity information that we get back, and also in the platform we have this technique for, obviously, not only collecting the identity information that one source such as the AAMVA source gives us but also then cross-check that with the other signals that we do have for you.
So, we build this identity score if you will. We don't publish it just yet as such, but we are very close to actually being able to publish that for consumption. But the point is that we do build that heuristic for you, and that is how we're able to not only validate the document. That's just the beginning step, but also to validate you, the identity.
The same binding technique is not a document-specific technique, Robert, but it is a candidate signal to us to also make sure that, yes, not only do you have a valid driver's license, but you're using the same phone that you registered for the bank account.
So, I mean just as a follow-on to that, Javed, we didn't actually cover a lot of the documents that we can use.
Yeah, we can probably send information.
Yeah, so we do driver's license, passport, and we can read the chip off the passport as well to validate the data.
Yeah, I mean 205 countries, Robert, right? So, we do this in Latin America, we've done it in Asia. We have so many projects going on right now. Europe also we have, so yeah.
Social security number.
All cool stuff. A question about QR codes, and you briefly just touched on that. People are a little bit skeptical about whether or not QR codes are safe. Do you want to just quickly talk on that?
Yeah, I mean generically speaking, you don't want to scan any QR code you see on the internet, "Let me just bring out my phone and scan it." That's probably not a good idea, but it just comes down to, for us, the way we implement, the reason for the QR code is to exchange information and to authenticate the user.
For that, you want to make sure that any information that we are exchanging, the user is, after scanning the QR code from the app, that is encrypted, and there's no information leakage either at the device or at the platform.
So, that's how we ensure that the QR code... We keep QR codes secure. And we also have a single-use QR code, which is not something that you will find normally for folks who provide support for QR codes. You can scan the same QR code multiple times, not with us. For us, each QR code rendition, display, render, is a unique session ID, and we track that in the platform. Yeah.
Cool, and then there is... Again, I'm going to paraphrase, it's a long one. It's about single sign-on using Okta in this case. It sounds like we do a lot of the things that Okta already does, and why would they replace Okta with us? And I'm going to start answering that one.
We're not advocating that you rip out Okta. Listen, every... Not every, but a good chunk of enterprise organizations have single sign-on platforms built into their organization, and you should keep them because they do what they do extremely well.
What we do is we're the identity provider to authenticate users into your Okta platform. So, you would stand us up in front of Okta. We would handle the authentication and then I guess federate into Okta, which would then allow users to go get whatever Okta's standing in front of.
You're not replacing Okta or Ping or ForgeRock or Microsoft or any of those platforms with our technologies. You're using us as a secure authentication platform that also does the identity verification at the front end, the beginning of that journey. Anything that I'm missing there, Javed?
Yeah. No, you're not missing anything, but it's very interesting this question because folks probably want to understand that there is this idea of identity life cycle management, and then there is this idea of identity proofing. And then there is this entity called identity provider, which for me and you, Robert, for our platform is also asserting with how much assurance can we vouch for you, Robert, right?
So, very important to understand that when you start with a database record or an LDAP record, which is what most of the SSO systems will do, you haven't vetted that record. Someone else vetted that record for you. You're putting implicit trust on a database or an LDAP record.
So, you can bolster your Okta implementation by starting with a proofed and verifiable identity, which 1Kosmos can build for you, and then we can expose, relay, federate portions of the identity via either attributes or what have you to your Okta platform to then further relay upstream or downstream to the applications that user wants access to.
And the assertion of continued validity of the user, that also will come from the 1Kosmos platform, which is not something an SSO provider like Okta is in the business of doing.
So, there should be no quote, unquote, "conflict" there for coexistence. The idea is to assert for the identity. That's what we do. We don't do management of the life cycle of the identity. That's what Okta will do very well, so those two solutions can coexist.
Very good, and if you're ever wondering what the difference between a product marketing person is and a product management person is, the answer to that question should be all you need to know. Anyway, all right, Javed, we are exactly at the top of the hour. Everybody, I really appreciate, or we really appreciate you coming along for the ride today.
We have recorded this, it will be posted on our website by the end of the day. If you want to watch it again or send it to some of your friends, it'll be there. If you'd like to register for the next one, it's also on our website.
So, thanks a lot, we appreciate it, and we can't wait to see you next month or at one of the events that we have coming up over the next four to five weeks. Thanks again.
Thank you very much.
It’s no secret that passwords are not meeting the security needs of workers, customers, and citizens or the organizations that serve them. Passwordless authentication has promise, but has yet to be widely adopted, and for good reason.
Too often passwordless MFA presents IT teams with an all-or-nothing approach. But, disparate systems built over decades present many challenges in the various authentication edge cases and integrations across the business. Passwordless can amount to just another product for IT to add to an already bloated tech stack.
During this session, Rob and Javed discussed how to eliminate passwords, reduce authentication silos, improve the user experience, and establish a secure architecture through four stages:
- Building a passwordless MFA strategy
- Accommodating legacy technologies
- Controlling implementation to ease users into a new experience
- Tailoring security controls to specific business and IT objectives