Yeah. Boy, that’s a great one. It’s always integration. It’s always integration and deployment. As we mentioned, IAM in any enterprise, really of any size, is a constant target. It’s always in flux, and changing, and evolving. And it’s generally central to everything that happens, so it’s a very difficult place to start playing around with R&D projects. So it’s always integration, and that’s really what drove IdRamp to do what IdRamp does, was the concept of being able to say, “We are going to integrate with existing IAM, and make a seamless transition to this new verifiable credential,” or maybe it’s just other identity systems, or other services.
So the toughest challenge is, without question, it’s always the integration of the decentralization. And self-sovereign is … Again, if you think about that, that’s going to be a whole ‘nother challenge. How does an organization go from a centralized trust model to a decentralized trust model? What’s going to be involved in that? Well, it’s going to be governance. I mean, there’s going to be a lot of things. Right now, it’s pretty easy to control. It’s centralized. This is you. I create my impression of you in my identity, and that’s it. And that’s all changing now. So it always comes down to the integration and deployment that we see as the constant need from our customers.
And that is changing, all of the time, right? You have a lot of organizations that have hybrid and heterogeneous computing environments with mountains of legacy systems where interoperability is always one of the main challenges. And also, from a consumer perspective, you have the challenge where maybe the average internet user has 140 or more credentials that they know of, that they manage. That really comes down to how you define credential. But in the broader sense, we have a lot of documents and data that can be defined as credentials. So that number can actually be a lot larger.
For one, you can’t just go password-less overnight. Maybe Microsoft can come to market and say, “Hey, 80 or 90% of our staff are all password-less now.” But that’s not a standard by which to evaluate or to use as a reference for other companies or for consumers, because that’s really a pretty daunting challenge.
As you think about those same challenges, what does good look like to you in the next cycle or this next generation of identity and access management? And if I could play devil’s advocate for a moment, how can we know that we aren’t just trading one set of problems for another?
Sure. No, that’s a great question. Next-gen for me would be the identity and access management system integrating digital verifiable credentials into the service delivery process. So that’s not to say the IAM goes away. The identity and access management system doesn’t go away in favor of self-sovereign or something like that. That’s a lofty goal, but the current identity and access management stack provides great value today, and it seems a more natural progression to augment identity delivery with verifiable credentials to streamline the user authentication process, as well as access control.
So this manifests in things like we’ve been talking about, like password elimination for end users, decentralization for service authentication, which is the removal of the dependency on the IAM system during the authentication process. So instead of that traditional backhaul connection through the IAM for every single user interaction, we can now fracture that. We can decentralize that with credentials. I can give you a credential. You can interact with that service without having to backhaul that connection through my centralized identity and access management system every single time.
And that’s the big security point, is that it’s easy if you are delivering a service to your customers, it’s easy for me as a potential bad actor to know exactly where you’re going to authenticate, which gives me … I know exactly where I need to attack. So we can now fracture that with credentials. We can get rid of that dependency. We can even go so far as to put that identity and access management system behind the firewall and not even make it publicly viewable or accessible, which will really help reduce that threat surface.
And that’s not a heavy lift. That’s not a dramatic change from where we are today. It’s simply the application of verifiable credentials and the integration of that process into our existing IAM strategies that then allows us to change our fundamental business practices to be more secure and more streamlined. And if you take away the password requirement for your users on your service delivery, and just sit and back out, and what cost savings you enjoy from that, it’s pretty dramatic. Your help desk costs go down for password resets. The risk of exposure for the impersonation stuff we were talking about earlier goes down. There’s just a lot of advantages to doing that.
And that path is not … It sounds like it would take a big diversion to get from where we are now to that world, but it’s really pretty straightforward. And that’s the most exciting thing about it. There’s always a risk that we’re trading problems, that we’re just saying, “Oh, this is now a new set of challenges.” But in my mind, getting the identity information where the identity information belongs is never going to be considered a wrong move.
So I see this working as an organization is going to associate with me as an employee, not issue me, “Here is your identity.” Instead they’re going to say, “Oh, I see your identity. Here’s a credential that allows you to interact with me, with my organization.” And so it’s more of a technology partnership than today, which today is a very structured relationship. You are an employee of ABC, and here is the proximity card or whatever that controls your access.
And I see this as more of a natural thing. We’re all going to show up with our identity. That identity is going to receive some credentials that allow me to interact and do my thing. And when that relationship is over, we sever those connections, we revoke those credentials, whatever the case might be, and we both go on.
I’m tempted here to ask how is this different than federation. I don’t really want to go down a technical rabbit hole here, but I do want to pose the question. I don’t know if you think that it’s easy, but the shift may be a fundamental shift, but there are also things along the way that you could do that just help make this transition to be smoother. It begs the question, at least for me, how big of a change is this for big players like Okta or Ping Identity? And why can’t they just make minor changes to their tech stack to go after this decentralized identity and self-sovereign identity opportunity?
Yeah. Well, and they potentially can. There’s certainly no reason that those systems couldn’t be updated to support it. And this is really where IdRamp’s vision of the world is a little bit different than most other IAM vendors. So IdRamp doesn’t do identity. So we’re really good at orchestrating, and managing, and building policy for service delivery or identity integration, different identity sources with different services.
But we’ve never … And this was a very, very, very difficult decision to make. Many times we’ve come to the table and said, “You know what? Life would be so much easier if we just kept a copy of this identity for a user coming through, and we’d just treat our own identity as master.” But it was never the right decision. My vision has always been that the world has enough identity providers, and we just need to be smarter about how we use them.
So the biggest change that IdRamp brings is that we’re not treating an identity as something that we own and control, and then entitle services based upon. And so I think the challenge with a traditional identity and access management system is that very point. It’s that I can’t take someone coming in with their own identity or with an identity from another location, and still provide the same level of service delivery that I can if I’m controlling that user’s identity.
And so I think that’s where IdRamp is really kind of fundamentally different. And I think that’s where others will have some challenges with that integration, going forward. We look at the world completely open and say, “I don’t care where your identity is coming from or where it’s rooted. Just bring it in, and tell us where you are trying to go and what you’re trying to do, and we can orchestrate policy across that.”
So I think that’s one of the fundamental differences. And it is certainly different than traditional federation, which you touched on, which is I’m going to tie my thing to your thing, and then those are going to be … and then we’re going to do some entitlement based on that whole federation. We see the world a little bit differently there. We see the world more as a connected fabric of identities, and not necessarily a point-to-point connection.
So traditional federation is very centralized, point-to-point connections, and we see it as just a mesh. Why make 10 connections to 10 different identity systems when I can just make one connection into some larger mesh that can then help me facilitate communications with all of these other 10 systems?
You make so many great points, Mike. And I spent quite a number of years, way too many, managing, architecting, owning really, large identity management implementations for big companies in finance, telecommunications, the high-tech sector. You would know all of them.
And as an owner, and manager, and operator of the systems, I think one of the things that vendors tend to overlook is the need for management, how these systems are managed. And when you’re trying to manage hundreds of applications or thousands, really, if you factor in now IOT devices, edge devices, SaaS, and cloud, and APIs, that this problem has really exploded exponentially.
I used to say, “Why does anybody need standards anymore,” because at the end of the day, the enterprise has the burden or the responsibility to support all of them, whether you’re an OAuth, or a SAML, or a basic Auth, or whatever the case may be. Large enterprises have the responsibility to really support a lot of different ways of authenticating users.
And so Gartner has referred to this as an identity bridge or an access bridge. And your company, likewise, has some pretty deep expertise in the traditional identity and access management stack. What were the early indicators that decentralized identity and self-sovereign identity was going to be a big enough business problem to pivot your focus and your company, and allocate time and resources to pursue that? And then maybe tell us about your story about you made that pivot, and where you’re at today.
Sure. Without question, the promise of protecting the identity and access management stack was paramount around that concern. Once we really understood that decentralization … specifically verifiable credentials, which is the ultimate decentralization. That’s a connection. That’s a relationship between me and my consumer directly. So that still falls under the governance of the organization providing that issuance. They still have the ability to revoke, all of the different things that they can do with a traditional identity today.
Once we really understood that dynamic, then it became about protecting the identity and access management stack. So we can take, through credential management, and we can issue a credential, and we can send you out to interact with services, and do your service delivery experience without having to expose that identity system to each of those 100 different cloud services you might be integrating with. That’s a game changer for service delivery.
Also, not having to build those bridges. It is a very onerous process for the enterprise, right now. They have armies of people that sit around and do nothing but build SSO connections. Some are SAML, some are OAuth, some are OIDC. It’s a big vegetable soup of different technologies and things that we have to understand and learn. And verifiable credentials offers the promise of completely flattening that, and standardizing that, and doing exactly what TCP/IP did to the networking world in the ’90s. I’m showing my vintage a little bit.
But that’s the promise, so it can take away a lot of these complexities, and standardize. So I’d be lying if I didn’t say that password elimination wasn’t top-of-mind. I mean, I hate passwords. They’re just my … I’ve got so many, like you mentioned, that I can’t manage them. And it’s just a terrible thing. There’s so much bad that comes from passwords that they have to go away.
And since we’ve been living in this world of verifiable credentials, I’ve freed myself from a lot of passwords. All of our internal services and things that we interact with as an organization are all done through different credentials that are issued to me to control my access and entitlement level with the services that we use in the wild. And it’s so much easier. It’s so freeing for me to go and log in to Zoom by scanning a QR code instead of putting in a username and password. Things like that just are very, very freeing. So I have to mention that as a requirement, or [crosstalk 00:27:45].
Of course, I love it. It sounds … I think anything that helps organizations to improve their protection capabilities, their detection capabilities, their management capabilities, because that’s where they suffer. In our industry, we have less than a 1% unemployment rate, and you just can’t keep adding teams of SSO engineers and security engineers to manage this problem. If you offered that as a solution accelerator for large organizations who all have this common integration challenge, that you’re very well positioned.
So while preparing for our conversation, reading up on your website, it talks about what everyone is talking about; SSI, password elimination, SSO, identity management, and so forth. But what really stood out to me was this concept you’ve really narrowed down your marketing focus on decentralized directory integration, I guess as a service, which I was intrigued. So is this IdRamp’s approach to decentralized identity governance, or is it decentralized infrastructure and tools management, or both?