So welcome to this event from my side, my keynote is entitled "Towards a unified, modular, trusted, and connected identity ecosystem". And here I try to lay out how I think a future identity and access management might look like this is my perspective, but feel free to contradict, to ask questions, whatever you think is appropriate when I do my presentation here. So to have a quick look at the agenda, as I planted for today, I'm looking at different aspects that combined together to that. What I then think is this unified, modular, trusted, and connected identity ecosystem. And I start out with the drivers and I think that this has clearly moved to the business. I want to quickly explain why unified module are trusted and connected. And that has a look at the changing types of identities that we're looking at. I want to look at different levels of trust and sovereignty, of course, the topic of decentralized identity.
And we had a specific event just for that topic recently. And the summary will be a way of moving towards this, this ecosystem and a quick summary. And since these are lots of slides, I have to start now undercurrent and speed up. So first of all, the many drivers as one of the components that I want to talk about, first of all, the business is at the core, and this is important for me because the role of IBM has changed dramatically in the years. Since I said, since the early 1990s, we have new identities and the pandemic, we still have to mention it again. And again has put a spotlight on what needs to change and what has gone wrong and what needed immediate change. So if we look back to how I am changed over time, we started out early with looking at administrative efficiency.
We try to speed up processes to, to make sure that the administrator only does the work that is required and everything else is automatically done. The next step was user experience and convenience. So we moved towards single sign on not having to type in your username password again. And again, next up was governance compliance. There were some incidents in the states and the Sarbanes Oxley act was one of the first starting points when it came to compliance governance, regulatory requirements and laws. And that was reflected within ILM as access requests and approvals access reviews. So how key by access to the user who approves it and who checks it. But on the other hand, when we look at GDPR also constant data protection, making sure that the management and the storage and the processing of data is done in a lawful manner. And now we are moving to the era to the era where I am is one of the main foundations for, for business, for security and compliance.
So we have these three aspects that come well together here, and we have so many different types of business models that I am, has to fulfill and has to work within. So it's B2B really working with partners, B2C working with, with consumers and customers, and even B2B to see when you provide services that your partners provide to their customers and all of this that is required. Federation adaptive, authentication, the paradigm of thinking of IAM services and API ecosystems, tying this all together. These are the building blocks that we need. When we talk about that still unified, modular, trusted, and connected identity ecosystem. So it's business enablement. I am has changed. We still have the employee account, but we go far beyond that. So we have digital identities for everyone and everything, and the lines between employees and all the other identities are actually blurring. The digital services in the digital transformation are the core business and they build on digital identities.
And we at KuppingerCole believe that there is no successful digital business without the I am done. Right. And on the other side, that means the am enables it to achieve this business enablement, to make sure that new applications often now in the cloud, as a service that can be onboarded quickly, new groups of users and identities that can be quickly onboarded or just added to an existing systems. And just to mention it dev ops and agile it, so the way how we develop systems and how we run systems, they require a modern IAM and Pam, which is not the topic for today. And again, there's also no cybersecurity without I am.
What do I mean by unified, modular, trusted and connected. We will see that later in, in, in some images, but in general, we need to understand that I am is not a piece of software. It's not a system that you can buy from one single vendor is a concept because it integrates and combines services. It, it provides capabilities under one single umbrella, ideally for an organization of an overarching ecosystem. And that helps to maintain access for all types of identities, to all types of services. And if we think of all these types of identities, if I read out all of this, that is on that slide on my 20 minutes, we'll be done already. So I just go quickly across that. And this is still not the full picture. There are more to think of, and there will be more in a future I am, but nevertheless, a very quick walk through.
We have still have the enterprise users with their traditional lifestyles. We have external staff and that are changing as well. So we have still these six months external freelancers that stay within the organization, but we are more moving also to quick on and off boarding for, for, for a few hours for promoters, doing stuff in, in the, in the consumer market and meeting access to a system we need to weekly on and off port partners. And they come with their own identities. You don't have to store them anymore. So they are federated and trusted. Again, the word trusted. We need to think of all the clients that we might want to serve. And I used the word clients that the term clients really on purpose, because that might be consumers customers, but also subscribers to service citizens, patients, whatever you have on the right side, there are the non-personal users.
So it's devices, and it's not only the corporate owned device. It might be bring your own device. And again, pandemic has shown that's true. So managed and unmanaged corporate on and bring your own device, personal devices and even share devices. Think for example, of a car or a tablet that is used by more than one user thing, of course they might be autonomous. They might be personal. They might be shared so very different aspects to things, and they need to be represented and reflected. And yeah, designed within an I am in the proper way, according to their characteristics. So they might be user specific, but all, they might be autonomous and they do things on their own, need their identity of their own. Finally robots and automation. Again, the same concepts. They might be autonomous. They might be acting on behalf of somebody doing work for me, which would be great.
They might be self-learning robotic process automation. They might be shared or on the shop floor. So all these types of identities, these are building blocks within our identity access management, next stop levels of trust and sovereignty. I say that this, there should be yeah, a unified, modular, trusted, and connected identity ecosystem to reiterate on that. So we need to understand the levels of trust that there are, and that we make sure that we act upon these different levels of trust and sovereignty. And if we look at the typical way of how identities were mentioned before, this is not over as I stayed here, but it's far from being the complete picture. That will be still centrally managed identities done by them HR with an IAM system. But this is losing. We have more, I, I isolated identities, identities that are in the ownership of the individual user, and that is starting with the consumer and the customer has already started.
And I expected also to change for the identities in business. So as mentioned, we still have the central corporate identities the traditional way, and it remains important. We have federated trusted identities. So we have an identity provider system in IAM system that has well-managed identities. And we integrate them within our identity and access management system. So connected and trusted. We have registration at vetting, the traditional onboarding processes, either really using a form and adding in information or building upon social accounts or whatever you have. And on top of that, then vetting and know your customer scenarios and all these different types of identities. They have different levels of trust, trust associated with them. So we make sure need to make sure that they are trusted at the level that they should be trusted. And finally mentioned that already. And we go into more detail here as well.
Decentralized identities. The self-sovereign identity is managed by the uterus users themselves either really self-managed or through providers of trusted identities with them verifiable credentials. So you make sure that you use the identity and reuse the identity that is provided by say, your bank, your state, your municipality, your insurer, whatever you have, or an organization like very me or the like, and they can provide verifiable credentials so that you can say I'm off legal age to do something by alcohol as the traditional example, or that you can reliably prove that you're disabled without showing what the disabling is more decentralized identity. We at KuppingerCole expect that parts important parts of identity and access management is moving towards decentralized solutions. So they allow that we can store and Sherry share verified on self sovereign identities or parts thereof whenever that is required. And that is reflected in these five fundamentals for future identity.
As one of the building blocks that we want to look at for this unified modular, trusted, and connected identity ecosystem. We expect that to be more and more important. First, the future of identity is digital sounds like a truism, but we need to understand that we are moving away from traditional analog identity verification. If you want to extend your passport during a pandemic, you know that this is not an easy thing to do. At least not in every country, we're moving towards a more private privacy forward future of identity. So data is necessary and we parallel want to make sure that this information is kept as private as possible so that we really only disclose the information that is required. So really at least privilege also here, the future of identity is user centric. We put the user into the center of the stage and the user decides what to do with the identity at what to disclose from the identity attributes that are there.
So the user is the common factor and he or she is in control. And we as providers of services as companies, we have to adapt because they won't, or they are already doing so when these identities are user centric, they should be, and we expect them to be reusable. And that again means connected, modular, trusted. So my surname usually does not change too often by date of person, hopefully never. So why should we onboard again and again? So we create this identity created ideally in a decentralized manner and share whatever you want to share with individual services that use these data sources and reuse is the only option. And that means that we're moving more and more towards a decentralized identity subsystem apart, or building block of capability where the user holds the identity data, make sure that they can provide that basic curate. The mechanisms behind that are designed to secure these, these data and these identities.
And then you can reuse them between identity ecosystems, for everything that you want to achieve, authentication and transactions. How do we get there? There is this thinking of, I am being that no longer I employee I am anymore. I said, it's an umbrella, it's an overarching concept. So we need to make sure that there is an overarching blueprint that achieves what we want to achieve. So controlled and secure access for each identity to every service. And this is a picture that has been talked about in several events of KuppingerCole in the, in the past. So if you are interested in learning more about this identity fabric, there's great material around provided by Martin Kuppinger by me. I just want to show it. And I want to go into more detail because the idea here is to give all the users to the left access, to all the systems that are to the right, to the top and to the bottom and in the middle is the identity fabric that achieves what I just described.
This unified, modular, trusted, and connected identity ecosystem. So if we drill deeper here, we understand that there's really benefit because this I am blueprint is as versatile and as generic so that it allows to be compatible with all types of identities, including the external digital decentralized identities that I mentioned before. And there's benefit. As I said, there's benefit for the enterprises really quickly onboard partners, customers, clients, you get better information quality because people take care of the information for themselves. And we have central control, but decentralized identity. So we have best of both worlds. We provide services and how that will look like will be one of my next slides. And there's of course, benefit for users. You exert control over personal information, you manage your credential credentials, hopefully no longer passwords, more securely. You can quickly onboard login, exchange information and control information by enabling and unlimited. And the principle of minimal minimal disclose. Sure.
And you as an organization, we remain in control across all these identity types. This is something that the identity fabric achieves. So if we look at the process, there are different aspects to look at and they, these are very simple and very easy to explain. And that shows that we can remain in control of the information that is relevant for us. So the customer, the identity, every of these identities that I mentioned before, they use an authenticated to prove who they are. That might be an app on the iPhone that might be using in implants within the browser or a certificate somewhere stored in the device. They authenticate towards an IDP and they use standardized protocols, again, a connected identity ecosystem, these IDPs, they maintain account information, and that could be anybody, Amazon social login, your employer, your state, your bank, and they provide you with account details that can be used for specific purposes.
And when an identity is authenticated towards an IDP and it can have access to applications and services. So it can work in business applications as an employee, it can do commerce as a customer and many other services can be used as well. And if you want more access to this information, this might be integrated in a system of records. That could be something like an HR, a CRM, a customer data platform within CIM. It could be even your IAM where your identity record recites your identity record for this identity resides and based on consent and business decisions, you can then say, we use this information for the purposes and where's controlled here is control the organization trusts the IDP authorizes applications manages the system of records and leverage is this information for, for the purposes, final slide, the summary very quickly, nothing new on this slide.
We have the identity expanding and we are in a connected world, and we need to make sure that we provide all the identities to all the services that are required. And centralized identities are on the rise. We think of identity services for digital services. We need to have that this works. We need to have interoperability, interoperability standards, integration to make this thing work together, connected into operable. And in the end, we need an overarching concept. And this is where we think it could be. Nicole. This identity fabric is a great way to doing that, but thinking in an abstract, in a unified approach for, I am, that's it from my side. So back to any, if there are any questions,
We had a few more questions regarding my opening keynote, the future of IAM towards a unified, modular, trusted, and connected identity ecosystem. And I want to answer them and just read them out and try to dig a bit deeper into the background of these questions. The first question was when you say identities for everyone, can you talk about non-human identities such as RPA bots? Yeah, of course. RPA bot of course means a robotic process automation. These are the software products, which are acting either autonomously or they act on behalf of a user. And that also defines more or less the relationship of the identities that are used here. If the bot is acting on behalf of the user, there are more than one possibilities. It might be that the user is using, or the robot user is using an identity, which is linked and closely related to the actual entry of the user.
So that these working on behalf it's reflected also in a kind of ownership or relationship. And so that there is also some more or less liability possible between what the robot does or the process does and what the actual user would have done. If the user is acting autonomously, they will have their own identity really as a standalone identity, which is really not connected to a human user. So they act as if they were another identity and then they really have their own life, their own life cycle, their own access rights, et cetera. So that would be something when we talk about non-human identities, a second question is closely related to that. And I read it out. Would you classify or SART identities of service accounts and RPA robot in the employee IDP or in one or many IDPs of their own?
There are many answers to that question. First of all, there are two identities thrown together. And that question, which I think should be looked at differently, first of all, service accounts, these are technical accounts. These are accounts that represent either a service or a technical user within an IAM system. And usually from our experience, these service accounts are technical and privileged accounts. And as such, they should be maintained somewhat differently. They should be kept in a privileged access management system so that they have that very special own lifecycle management around them. And also the way how they are accessed should go through a Pam system, maybe a Pam system for integrating with, into a coding environment, with, into software development or real, really a traditional privileged access management RPA robots. Again goes back to the, to the answer of my first question. It depends whether they are related to an, a human user.
So they act on behalf of them. They should always be kept separately, not necessarily in a separate IDP, but in a separate logical context. But when they are related to an identity of a, of a human user of a personalized user, they should be closely related to that. And if they are autonomous, they should be kept separately anyway. And it does not mean that they have to be that they have to be different IDPs. I assume in most cases, this will be the case, but nevertheless, as long as they are kept in a separate context, a separate naming context, subtree whatever you have within your structure, they should not be mixed with, with personalized human identity users.
The question was if, in my opinion, in the, in the fields or out there in the world, whether policy and regulation such as IDAs pushed the acceptance and implementation of decentralized identity, modern identities, more than the extraordinary powers like the pandemic, or if it is a combination of both that forced the flexibility in a modern IAM ecosystem. As I described that also is not a simple answer because it it's it's varies from country to country. There are countries where Ida's has had a very big impact and where lots of changes would have really been triggered by regulations and such trends like the Ida's in other countries, I can Germany, for example, the, the thousand dollars wise, the Eid card is something that has not really gained the traction that it should have. And there, this regulation part is not of that importance. When you look at regulations and things like GDPR, that's a different, that's a different game. Of course, this, this GDPR as a compliance requirement has changed things dramatically. But to, to be more Frank, I think that the COVID-19 pandemic has had more impact on the changes that we see in identity management right now than anything else that it's surely true. Many organizations had to move towards multifactor authentication, authorization, and multifactor authentication. That was really something that they needed to change immediately just to protect their systems and to get more flexible. Many more cloud services have been used.
Another question, how will self sovereign identity be integrated in the two landscape? And this is really not simple to answer because self sovereign identities come with a variety of different concepts, how you get a self-sovereign identity, where to start, how it is controlled, how it is authenticated and authorized. At that point, I really would like to recommend reading the compass documents that my colleague, Annie Bailey has provided because they sh they don't these documents. They look at the different varieties of how this connection could be made and how it is integrated in the tool landscape. When these self-sovereign identities are used for an onboarding process, then this will be usually done through some kind of Federation processes or Federation protocols, or every other type of integration that should be really looked into the implementation of the actual self suffering identities solution. And that is also very closely connected with the, with the next question, how will self-sovereign identities be reviewed?
How is ownership different than non self sovereign identities? And the answer here is clear self-sovereign means ownership is with the actual user, with the identity, with the holder of the identity. So there is a high importance that this ownership remains with the owner of the self sovereign identity when it comes to reviewing the self-sovereign identities. Then again, the question is, first of all, how is this self sovereign identity modeled within the overall IAM concept? If we think back of my presentation, that was a systems of record, which combines information from different areas where for example, the initiating identity would be related with some ghost or shadow identity within the actual identity nexus management system, which then augment the sovereign identity with runtime information, with history information, with credibility information. And in that situation, you will then review more or less this shadow entry. And if there are some changes within the actual self sovereign identity and this ID, then this should be looked at more closely in general.
I would assume that an organization allowing access via self sovereign identities apply a risk-based approach that makes sure that they understand what is provided from the outset as the self self, an ID ID, and then add their information at runtime over the lifetime of this identity and review that. So I think that would be an answer for that question, although this surely not comprehensive, if there are more questions, please get back to me. I'll get back to my colleague, Annie, finally, the identity fabric. The, the question is this fabric sounds a lot like as parental great concept, but not easily implemented. That's true. It's not simple, nevertheless, it's worthwhile doing so because it applies a, a service-based approach that is really important because then you can separate individual services within your identity and access management and have a close relationship between the services, but you can delineate them very simple.
If you delineate something that is a service, you can either scale it up, scale it down, you can replace it, rip it out and add something else. Or you can smoothly transfer from one service to the next, or even have them in coexistence. And so this service based approach is the first starting point. And once you have achieved that, then you have not Esperanto, but you have components that talk to each other via API via clearly defined interfaces. And that allows you to create the high level capabilities. The services on top of that, that are implemented through the individual building blocks that have you in within the fabric, we, as KuppingerCole are using this identity fabric approach for, for assessing existing I am infrastructures, and for changing them for making them more future-proof or scaling them up for broadening their scope towards all the identities that I've mentioned within the, within the presentation.
And I think that is the, the, the, the, the, the, the beauty of the concept that makes sure that you can really scale up and rip and replace without interfering with the overall functioning of the, of the overall system of your identity and access management ecosystem that communicates with services with identity, provide providers with external services and provides services. I think that is the beauty of that. The second part of that question is not fully clear to me too. I really would like to ask the person that raised that question or that issue to get back to me to explain more what is meant. It says that the problem is some of the component requirements have weaknesses that can be exploited. If there are weaknesses, I would assume that they are mitigated that they're not controlled, or the building block is not used and replaced by something else, but maybe I did not get the question, right. If there are any more questions, please feel free to get in touch with KuppingerCole dot com with me, MR@KuppingerCole.com for, for just a mail or a follow me on Twitter and get in touch there via direct messaging.
