Hello everyone. This is Craig Burton. Welcome to today's webinar, identity management as a service. Is it the dope or are we do so with me today, I have two distinguished participate participants, Kim Cameron identity architect for Microsoft and Chuck Mortimore senior directory of product management for identity products, and these, these guys know their stuff. So it should be a good discussion today. Welcome. So let me go over some housekeeping things. First, just a quick look at what KuppingerCole provides. Research services, advisory and events. This is in the event category as a webinar. And of course, don't forget about the European identity and cloud conference in may. So some guidelines for the webinar, everyone is muted centrally. You don't have to unmute or mute yourself. We control that we will record the webinar. And so everyone who attends will receive an email for the recording. So you can review it and look at it after ledger. Go ahead and type your questions while we're talking. If you want. I'll, I'll try to answer them if I can, but we we'll hold a little question and answer at the end and any questions that do not get answered. If we run out of time, we'll be answered by myself or the, any of, or Kim or Chuck. And I will then post that on my blog at the KuppingerCole website shortly after the webinar. So here's the agenda.
We're gonna look at identity management as a service from the perspective of the, of the API economy. And the reason for that is because the nature of the API economy, as it relates to identity and the number of devices and entities really brings into focus, just how important identity management services, both conceptually and also substantially. So that's the reason I took this approach. So I'll do a quick introduction to the API and the API economy ecosystem and the Cambridge explosion of everything. I'll introduce the carpentry co API axioms, and then a few sections on why the current models for managing identity and privacy are broken. And then we'll let Kim and Chuck go through not their products. This isn't gonna be a product specific conversation, but the thinking behind why these two companies are looking at doing identity, not looking at are in the process of building products that do identity management as a service, we'll have a summary in a little Q and a after that.
So here are the five cup Andry co axioms. The one we're gonna focus on today is number one, which is everything. And everyone will be API enabled. I'll go over the other four quickly. The API ecosystem is core to any cloud strategy. If you're building a cloud strategy, which I hope everyone isn't is doing you, you need to include how you're going to deal with the API economy, baking core competency into an API set and economic comparative, and four and five was enterprise inside out. And I that's a short term for, for being an API provider, as you'll see in a minute and enterprise outside in is being a API consumer, all part again of the API ecosystems. So the API ecosystem is divided into two designs. One is that of being an API provider. This is where organizations provide specific APIs to core competency to the outside.
Now that gets broken down a little more and I'll show you that in a second, but so that's the enterprise inside out the API consumers. Then the other side of the same coin, which is where organizations consume or use APIs and integrate them with their existing functions and data inside to provide services to the constituents of the company, both inside and out. So the I provider then gets broken down into two different types. I call them open APIs. This is different than the traditional term of open in the sense that it doesn't mean open source, but rather open in that they're published in available for public consumption in general. Now there are what are classified as open APIs that, that require either payment or some sort of registration in order to get to them. So, like I said, it's not the, the traditional use of the word open in the sense that it's just available and free and known and published to everyone, dark APIs.
However are the other side of that coin. These are unpublished APIs for, for closed consumption. And an example of that for is there's a nutrient company that has dark APIs that are used just for their constituents that buy and sell their products to be able to get in from their mobile devices and see what's happening with their commissions. And so on those APIs, aren't published for public consumption, but they are used and very active in a lot of activity for, for their closed constituents. Now onto the API consumer, there's also open and dark APIs there, but there's also then the third type, which is internally APIs, which have existed for some time, but then can be combined with both open and dark API types, sorry for the blurriness of this slide. But this is provided by the program of web people, John muster. It talks about the billionaires club.
When you start looking at these numbers, it's, it's pretty mind boggling of the number of companies that are in the billions of API types of calls either per day or, or multi-billion calls. Now, in case of Google, for example, was 5 billion API calls a day, even though it was probably a lot higher than that, cuz that number's already two years old, these are for their apps, not for search and I don't have I, this new slide doesn't have Salesforce dot coms on there, but they're also way into the billion in part of the billionaire club. So just looking at unpacking Twitter, for example, if you get 13 billion API calls a day, it comes down to, you know, a million API calls per minute, and that that's a lot of API building to be done. So to understand the API ecosystem, take a look at this graphic, traditionally, the way that your constituents or, and organizations constituents have had access to information and resources is through the browser in 40 80. And what we're looking at is providing APIs that as both providers and consumers, that can do business to business and business to customer third party apps, social apps, and so on through APIs to internal information and resources, this is a much larger access spectrum for the online population to a given organization's information and resources than has been traditionally available. And again, the position that that, that Ture coat takes is that this is an economic comparative to embrace and understand this and to be engaged in making it happen in your organization.
A little bit more information about the growth of APIs. This is a couple months old. So sometime this year, I think we'll get 8,000 open APIs that are published. The growth rate of the number of APIs that are published is over a hundred percent compound annual growth rate over a hundred per week. It's it's just, and as I explain here, the number of dark APIs are look like, look to be around five times larger than the published open APIs. So it continues with the current rate. My projection numbers look like by in three years, there'll be 16,000 open APIs and 80,000 dark APIs. And that's probably conservative. Now, the reason I call this, the Cambridge explosion of everything is because it matches interestingly, an era and in the growth of the planet is if you were there, you can remember of where moving from single cell to an incredibly rapid growth of cell and plant life, that animal and plant life that populated the planet at an unprecedented rate. And that's sort of what we're seeing with the number of devices and entities and APIs that need to have identities and identifiers associated with them. So
I'm just gonna quickly go over Apple's numbers. And the reason I use apple is not because they're the quintessential view of what's happening, but rather it's, it's one or one entity and these numbers are pretty recent. So there's over 400 million iOS devices, 700,000 apps at the store. And even these numbers are, are, are a quarter late
84 million plus iPads and, you know, close to a hundred percent of fortune 500 in the United States are investing or deploying. I iPads at work. Those, those numbers are astounding. So if you then take, combine that with Cisco's predictions, along with the KuppingerCole API, Axiom number one, which is everything, and everyone will be API enabled. If you take 2.8 devices per person, which is what Cisco says is going to happen by 2015, that's close to 20 billion devices. And you know, if everyone and everything is gonna be enabled, you have to include 7 billion people. So that's 26.6 billion APIs. Now, even that is a small number because that's just one API per entity. And as Kim Cameron pointed out to me, those things, that's those that number isn't even showing the associations and relationships between those devices and people. So it's a, it's actually a conservative number. If you can call 26 billion APIs conservative the current admin based model for provisioning a entity to a service of information and resources is, is very admin heavy.
And it requires that administration be involved with napping, an entity to a resource in each case through an administration screen in a browser. So if you take, I just did some somewhat whimsical numbers in the sense of assuming that an admin can provision an entity to a resource in 10 minutes, which is probably aggressive and can do it 24 hours a day, it would take 640,000 admins, 24 hours a day for five years to provision 26 billion devices. And the thing that's makes that somewhat whimsical is that nothing's going to stay the same within five years. And most of those would have to be deprovisioned or reprovision again in that timeframe. So it's impossible to have it happen and therefore, a broken model. Now, these graphics just once again, show how today's design is, is a one to one entity to device and this type of mapping, it makes no sense somebody's got their mic on and making a lot of noise.
So we need to move to a different model where there's some sort of service in the middle that that will provide an abstraction layer between entities that need to be provisioned in the resources there're identifying to. And as you'll see, that's the, the structure of identity management as a service. So I'm gonna go ahead now and turn this over to Kim Cameron. This is, this says the source of this is the I appol API phone rollout in the right hand corner. And that's not the case. I just didn't delete that. So Kim, go ahead and, and take this
Great. That's quite a source there. Okay. So I think, you know, the points that Craig is making are really key about the API economy and what the API economy represents to me is the fact that the new division of labor in the cloud will be one where all of the entities participating in it will, will specialize do what they do best resell that digitally and consume the things that aren't core through what, what Craig calls the API economy. And so the only way that that can happen is that the specialized services will interconnect and consume other specialized services that are running anywhere at all in the cloud.
And yet most government and enterprise data that will be sent to the cloud will be sensitive private data. So this has a lot of importance that really positions the enterprise use of the API economy as being of, of a different character than the consumer space use. That we've a lot of, which has we we've seen to date the, the enterprises are really aware of and have the personnel to understand and verify that the, that their data is, is going to be looked after in the proper fashion. So my conclusion there would be that API providers will have to abide by confidentiality policies and other policies, data protection policies, and everything else based on strong identity before they'll be trusted with data at all. So this enterprise branch of the API economy tree will, will, will be one in which there's a lot more attention to the authorization and identity aspects.
And what's really interesting here. And I would say difficult is that this ability to abide by policy and to base one's activity on identity will still have to be functional when one API calls another API. So it's the API economy. Isn't one where you have a service that calls an API. And that's the end of the story. The API that is called could, could well be relying on other APIs to produce its conclusions. And so the question of the security of the data then is not limited to just the relationship between the enterprise and the API that it calls, but to a whole potential chain of APIs, click this good of the next slide.
So I've sort of tried to graph that here, you have an enterprise application that calls into an API that API may call into other APIs, other APIs, and so on, and organizations have to be able to reliably identify authenticate and authorize across a multi-platform graph of services. So it's not a single point to point situation before reuse of specialized services can become practical and economical and the motor of cloud economics contain next slide, please. Well, in short existing identity paradigms, can't handle the identity security and privacy requirements of the cloud and its API economy. That the problem that we just sketched isn't isn't is a difficult one. Can't be, can't be met by the paradigms that are currently in place. Next slide, the domain based IBM model of, you know, the 1990s early two thousands is just a nonstarter because clearly no one will be staying inside a domain. Everything is cross domain. So it's just basically a known starter. Next slide.
The first technology that we developed that to deal with crossing domain boundaries was the meta directory virtual directory provisioning model. And it will continue to help, but it doesn't resolve the problem of the API economy. In, in this diagram, I have a meta hub service that provisions entities into various different other services. And it, the, the assumption here would be that the way that they handle identity would in many cases, the different and the identifiers in the different spaces, be different policies, be different. And so on next slide. And so if you then have a call from the yellow service into the red service, an API call and the yellow service received an identity of yellow identifier, it has no way to calculate what red identifier will be that is needed in order to determine the security characteristics and authorization in the second domain.
So the problem of just provisioning in, in, in disjoint name spaces, doesn't solve the problem of, of doing API calls across name spaces. So this is it's really is a new and, and more complex problem. One example I can give of this, that some people may be familiar with is for those who used SharePoint and SAP, there were products that allowed the user to go to a SharePoint site, and then the SharePoint site would hit out to SAP and get various information on behalf of the user and bring it back to SharePoint. Well, configuring all of that using traditional mechanisms was really, really difficult. And we had to invent a lot of stuff only in the last few years, have we had ways of doing that, that, that are humanly feasible, but they still require way too much overhead for the administrators. And that's just a microcosm of what will be a colossal larger problem within the enterprise API economy. Next slide please.
And similarly, the first generation identity Federation model, won't be able to, to handle these problems either. I think everybody's familiar with this next slide. One reason is because the different service providers, our, our, our, our structured and have legal agreements to consume identities from different identity providers. So once again, the diversity of people and of services in their relationships to identity providers is what prevents that cross API functioning from working. Next slide please. And next slide, we also can't oh, oh, there I get a little bit of, of an animation. We, we can't depend in this big cross cloud environment on a single identity provider that makes all of the claims that are going be needed. It's just unthinkable really unrealistic to imagine that any identity provider is going to achieve that degree of penetration, that it can have a ubiquitous and to pan optical ability to make claims across the whole of the, of the enterprise and government landscape. Next slide.
So we need simplification and we need to remember that we're in an economic crisis as well. So we need lower costs. And when you put these things, we also need these new capabilities and you put these things together. The only way that I can see that this could possibly happen is through identity management as a service and next slide. So let me summarize the argument to, to, to today, the API economy requires a new model of identity management that provides cloud error capabilities, but there's a condition attached. It can't make the cloud so expensive that it loses its reason for beating. So how do you get more capability for less? Money will be only possible. Answer is to use the efficiencies of the cloud to enable new functionality and efficiencies in identity. So it, the cloud itself leads to greater efficiency. We need to use the cloud for identity to be able to handle the new requirements that the cloud poses for in the eight API economy, period, next slide.
So now let's try and define what, what do I mean by identity management as a service, it provides cloud services to manage identity relationships for an organization's employees, partners, and customers. And if it's to be meaningful, it to be simple, it has to be cost effective, low risk and complete. And its job is to connect members of the enterprise social graph. So that's the customers and the partners, as well as the employees and the stockholders and everybody else to each other and to their applications and to their devices and to their information. Next slide. And so you could actually look at all of the things that we've done in identity management over the years, as well as these new requirements that I've outlined and see all of those as being capabilities that could, that will be offered in a, you know, as a service so that instead of people running all of this stuff in their own it zones, they'll be able to outsource that to be run and do these progressively more complex things in a, in a way that is very highly automated, very highly regulated subject to compliance requirements and, and so on guarantees of security and ownership of data, all those things that are necessary to make the notion of identity management in the cloud.
Realistic.
So now, if you talk about, I'll talk about Microsoft's role in this for, for a moment. I mean, one of the things that we, we have provided a lot of these capabilities in different products that we have, and a lot of it has been sold, has been taken to market through the rubric of active directory. So active directory of course, is more than a directory. It is a directory, but included in that it's a whole authentication system, you know, curbs, you know, Federation services, many of synchronization services of all kinds and so on. So we've always seen the directory of brand as being something that brought together a number of different identity management capabilities.
So from our point of view, we now see ourselves offering the same capabilities, not only to be run inside the enterprise, but also to be able to be obtained as a service offering. And in fact, we see the need for this to be completely connected in the sense that the systems that one runs on premises could could, and the directories that one has on premises could be projected into the cloud. And the ones that one runs in the cloud could be projected on premises with whatever guarantees of limiting information flow are necessary or desirable in different environments. So the, the notion then is to take active directory as a identity management system and add to it a, an integrated identity management as a service offering. And we call that Azure active directory. Next slide, please.
So now the question is how do you actually achieve the simplification that, that, that is necessary? So for example, if you take, imagine you have a directory that's operating in the cloud. In other words, you've projected part of your directory into the cloud, and you wanna make it available to some partners, but you certainly don't wanna make it available to other partners. If you do make it available to a partner, you want to be able to control how that partner uses the information and so on. So you run into the whole set of issues that we faced in first generation directory, Federation claims, Federation identity Federation, and that as Craig pointed out was all configured on a one-to-one basis and what was intolerably difficult. So what we're working on and what we believe in and along with others in the industry is the ability the need to be able to have trust frameworks that basically define a series of legal relationships that can be standardized and codes of behavior that can be enforced, and that can be audited.
And to be able to, to be, to be able to in our future generations of, of software services, allow people to select the trust frameworks that meet their compliance needs and meet their legal goals. And through that selection, very high level selection of basically functionalities and protections, be able to automatically configure the underlying access control and everything for people to be able to use their services people. So, for example, I gave the example of directory. It would configure the access control on the directory, according to people's memberships and trust frameworks, plus whatever access permissions have been granted. So our, our thinking our belief is, and we're, we're, we're building stuff that allows through selection of trust frameworks and, and just the use of portals that define options to be able to produce the legal agreements, compliance and verification, and the technical configurations set up so that it all doesn't all have to be done in an error prone, manual fashion. And the cloud of course, is makes all of that so much easier to, to, to, to do because one can, one can control all of the different aspects of the software that is interacting next slide. And last slide.
So just to give you this example, if we zoom in on directory as identity management, as a service, and we could have zoomed in on credentialing, we could have zoomed in on, you know, all those other components that, that were listed organizations can selectively expose their directory to other applications, services, customers, and partners under their own control. The organization decides who can see what, and in which applications. So it isn't like you're just taking your information and putting it in the cloud. And then it belongs to the cloud, the cloud isn't the, the identity management as a service operates your directory for you. That has to be the model before it becomes something that, that, that is practical and, and desirable. So the cloud directory is a service run on behalf of the enterprise, not the operator's cloud directory. So we have to make sure that we move towards this paradigm publication of one's own directory and subscription to other directories can be provided as part of the identity service, but controlled by the enterprise. And trust frameworks must be used to simplify the legal relationships involved in information sharing, otherwise this kind of new possibility enabling the cloud, a, the cloud, the API economy will just be a legal nightmare and possible to get off the ground.
So thanks. Maybe there'll be questions and we'll, I'll turn it over to Chuck.
Thank you, Tim. Thanks,
Kim. Yeah, let's move ahead. Here you go. Chuck, go ahead.
Great. So one of the things I wanted to do this morning was talk to you a bit about UHD as a service and the design center. We really used for Salesforce identity, how we believe this reflects some of the core tenants of IBM as a service where we really think the design center of the industry products as a whole needs to be going, what we put into this. It, it should dovetail well with what Kim was saying about some of the, the underlying concepts here. So with any of these services, we think that ultimately given the domain that we're talking about, customers need to start with a foundation of trust. We actually think that cloud-based services identities as services, a, a excellent environment for establishing this for a few different reasons. The, the main one though, is, is that if you look at multi-tenant models, and if you look at cloud models, what we tend to see as a democratization of security.
So if you look at Salesforce or Microsoft is we're running large scale services on behalf of governments, large, multi, you know, multinational corporations, et cetera. We get put through vetting processes and certification processes, but ultimately create environments of highest common denominator security. So as we roll out capabilities that are features that large customers invest, ask us to invest in those become available to everyone and therefore people that might not normally be able to afford certain features, afford a baseline of security, afford a team looking at and monitoring their services and doing the general protection that you need out of, of these types of capabilities, especially when you start exposing them, especially when you start federating, especially when you start opening up these APIs outside of your, your ecosystem. We think this basically takes the economics of this type of security posture and drops it way down low so that it's achievable and addressable for a much different market segment than usually could forward this type of security posture.
As we're doing that. One of the things everyone's focused on is also making sure that scaling up of that as possible. So certifications and establishing baselines of how you approach the cloud and how you understand what the environment is giving you, what capabilities are there, and what they've certified against in well known standards is also important for understanding how you're gonna be digesting these things. So on, on top of it is sort of a baseline of security and trust. What what we're doing is basically establishing a core directory service. So we think there's a few key tenants we've seen here from the past in identity systems and are transitioning those into the cloud. So one of the, the key things is of course, standard schema. So, but as we look at this schema, it's not just about users and groups, it tends to be about all sorts of entities.
Those could be other human entities, like contacts, leads, things that represent partners or customers in various states or state transitions as they interact with your organization. Or this could be, you know, very different sets of entities, things that represent organizations, things that represent companies, devices, et cetera. We also believe that because all of these entities are collaborating that you need a, a core social graph that's being established. So if you look at the, the core Salesforce identity, directory service, each identity within the system, and all of the other entities are inherently social. So as you create an entity in the system, it can collaborate. It can have its own feed, it can be followed. It can ultimately post information back and forth. And therefore, if state changes are happening on entities, that aren't necessarily humans, but you're collaborating around that entity. It can have social properties for it, just like humans might be connecting in, you know, in regular social collaboration.
So, and ultimately enterprises are complex and diverse. So a way to express a core security model on top of the directory service is also critical. So what we've been focused on is not only functional level security, so providing group structures and role structures to determine data access. So, you know, crud on core tables or entities within the system field level access to that also role level access. So how do we use things like role, role hierarchies, or queues, or different ways to model access to particular entities or rows of data within the system? So all of this is sort of laying down a, a baseline of you have to have a, a core directory service that can ultimately model the identity management system that you wanna put in place as an organization. Let's jump forward one slide.
So from there, we really think this needs to be extensible in program and do that both declaratively and programmatically. So if you look at the schema that we may have established, I talked about standard schema, but you should be able to walk up to one of these systems and really model any type of entity that you want. This was also something that was quite powerful and made, made LDAP successful the ability to have a standardized schema, but then dynamically extended that schema. You can do that in Salesforce identity by, you know, simply going up to webpage or do that programmatically through code running in the system or over APIs, allowing you basically to model your own concepts, your own entities, the, your own fields on those entities. We also think that from data type perspective, you know, strongly typing the extensions that you can have here in a variety of ways, be that, you know, simple text style capabilities, modeling relationships, so graph type relationships between people, structures, encrypted information, et cetera, all of these are different data modeling techniques that you need extensibility so that you can come up and express your concept of user, your concept of customer, your concept of device, or your concept of some entity that you know, that the identity management system out of the box didn't know about.
And indeed then can express validation rules around those constraints around those and do all of that declaratively. We then basically added into our system, a cloud runtime because we actually think this needs to be dynamically programmable. So we'll actually allow you to dip all the way down and into the, the state changes on entities themselves. So if you wanna create things like triggers, like concepts, we've seen popular in the database world, also depending on the directory server, sometimes in the directory world, the ability to inject yourself and actually execute code within the system in a, you know, secure, governed way in a multi-tenant environment, but execute code within the system or to higher level, do that declaratively for, you know, state changes on, you know, users, if their title changes to vice president, let's go ahead and execute this particular function, call out to this system.
Let's graphically define workflows for this batch processing. So you can do processing over a huge number of entities and do that in a, a reasonable amount of time. All of these things are capabilities you need so that you can customize the system to your particular needs and ultimately open up the system so that it's not constrained to the particular protocol or the particular data model that you've established, but then you can reprogram the system on the fly and tailor it to your particular particular needs. That then bring us us into the, the next concept, which is, if we look at how we extend the system, it's really internally focused. It's really, how are we modeling entities, programming entities, etcetera, as soon as we go out. And this is the main thing that you actually wanna do with one of these systems, you need to get standardized wire protocols, APIs in place.
And one of the things that we've really been focused on here is making sure that this is it's a PLO. Basically this goes back to, you know, something Kim said a long time ago, which is there's, you know, multiple operators and multiple technologies that are being employed in any type of identity meta system. And therefore we've really tried to be as open and as standard as possible. So if you look at traffic to login.salesforce.com, which is the core engine backing Salesforce identity only about 38% of our, of our traffic is web-based traffic. The remainder of that traffic is API calls, mobile clients, desktop clients, and all of these things connect up to the cloud in slightly different ways. So we've put in, in place basically a protocol engine that speaks all sorts of different protocols for all sorts of different, you know, constituent applications, devices, use cases, et cetera.
So SAML is certainly something that we're quite invested in, not dead. Despite rumors continues to be sort of the workhorse of current federations, but as, as Kim and and Craig were talking about one of its liabilities at this point is the lack of automation that really exists there. So we too believe that trust frameworks, automation, and metadata exchange and whatnot are, are required and we're continuing to, to invest in these areas so that we can scale up the ability to use this, this protocol. We're also investing in new protocols, things that are a little more dynamic by nature, a little simpler by nature, for different sets of clients, newer clients, et cetera. Oof, is something that we've been a big believer in has just achieved standardization. We've been working together with other large cloud providers like Microsoft on this. And we really use this in a lot of cases for API access, tablet, access, mobile access, et cetera, open ID connect adds in identity layer on top of that skims an important protocol for not only sort of standard push style provisioning, but also for what we believe is ultimately the ability to express in a standardized way, cloud directory structures, cloud graph structures.
You heard Kim talk a bit about claims transformation. We really think that oof and the assertion flows that exist with, you know, with JWT assertions, Sam assertions work we've actually done together in the standards body with Microsoft represents the ability to have sort of restful security token services. So if you want to be exchanging assertions and doing claims transformations, we think a lot of the nice properties of protocols like Ws trust can be brought to these frameworks with the approachable and, you know, developer-centric nature of Ola. And then we, we wrap it with a bunch of other APIs, RAs APIs, graph, APIs, soap, APIs, identity connectors, to different systems, be that consuming identity from things like Facebook or active directory or pushing it out to other systems. And ultimately we even let customers express custom APIs. Cause we really think this needs to be as open and as multilingual as possible. Moving on.
So this really talks to what Craig was talking about as API in and API out. So at any given time, you may be both consuming identity or producing identity and what we've really done and tried to do. And what we think any system like this needs to do is design so that you can layer or sequence your protocols together. So with a, within this system, we can potentially start out, oh, off, you may be a client that's trying to access an APIs. And when you get to the authentication phase, switch to SAML, go talk to a different identity provider rather than the cloud IDM service, go back to your, your enterprise IBM system. You jump back to ADFS for instance, and federate back into the cloud and then return back to oof. And those can be sequenced together. Or you could start out with SAML from, you know, a third party cloud like Google into Salesforce.
And we could in turn, decide on a per customer basis that we need to go talk to Facebook in order to log in. So by using web protocols in this way and using protocols that can be layered and sequenced, we really think you have the ability to not only consume identity and produce identity, but do those together. And what we use is the middle to be responsible for the business rules, the policies, the orchestration to determine for a particular transaction for particular tenant, cetera, how are we going to accept identity and consume identity and do that in one, in one cohesive. And then finally, as we talk about tenants, let's jump to the next and final slide and then we'll break for some questions. We really think that this all needs to be, of course multi-tenant, but it doesn't just stop there. So within your organiz or within your organization, you have your own concept of, of user your own schema, your own rules, your own constraints, your own code, and your own APIs that you wanna layer on this system.
And that nets needs to be done specific to your organization. So once again, like Kim said, we're not running this as the Salesforce identity service, we're running this on behalf of customers. So, and that's a, a critical part of these cloud identity management as a service systems, but they also need to open up both within themselves. So if you're inviting customers or partners, partners in for collaboration, you need to be able to connect with them and collaborate in a, in a secure way. So accept identity in and do that in an isolated portion of your graph, and then ultimately do the same, go out and join those customers in their environments and collaborate. So we need to facilitate the, the secure exchange of identity Federation, collaboration attribute exchange. And with that, we really think that that it's critical that it's open and it's standard space because ultimately this is the model that's going to win for enterprise identity management as a service. We won't see monolithic style directories exist like we do in the consumer space because the needs and jurisdiction of the enterprise is far different and, and leads to this federated model rather than a monolithic model with that. I'd love to turn it back over to Craig and maybe we can grab some questions from the audience.
Hi. Yeah, just to summarize before we field questions. And I do have several here, the API carpenter co API, Axiom that is germane to this conversation is that everyone and everything will be API API enabled and that the current identity provisioning models just don't scale to deal with that problem,
Especially when you look at it from the perspective of an API, because of the multiple types of relationships within multiple domains and providers that that ends up creating it's, it is so technically legally, emotionally complicated that it requires us to rethink how to do this. And I'm with both of these gentlemen in the opinion that doing it in the cloud as a service is the only way that we can look at possibly dealing with the issue that is not coming to us, but is already on us. So with that, I'm gonna go ahead and start looking at some of these questions. So I'm gonna throw this one at Kim, and it says, could you further elaborate on the trust framework that can Cameron mentioned who is involved in the setup of framework and what is the current status?
Yeah, sure. Well, there are several, first of all, the whole notion of trust framework has gone through the ITU and has been standardized there. And then there are entities that have, have, have started to become, what should I say, bodies to, to, to certify trust frameworks themselves. So, so you have sort of OI X is the number one example right now of an entity that is doing a lot of thinking and, and bringing a lot of people across the industry together to work on not one trust framework, but a framework of frameworks, if you want, because the idea is that this is not a one size fits all world. The trust framework that would be right for some consumer site might be really different from the trust framework. That would be right for an aeronautics consortium.
So there's gonna be many different trust frameworks. And by having a framework of frameworks, we're able to define, okay, this is what, what any trust framework should deal with and, and, and sort of scope out all of those things and then figure out all of the potential legal and other documents that are necessary to, to make that work. And then you have people like me and Chuck who are looking at the trust frameworks and going well, gee, okay. If we can get these trust frameworks that specify a bunch of things, how can we use that to drive the technical configuration of the, of the world if you want. So I would advise that to, to look at, you know, there's Camara, there's, there's lots of different trust frameworks. I, I just, just do a web search on O trust frameworks.
Yeah. I think it's worth commenting on that where we've seen trust frameworks be really successful in the past is where the, the member organizations like the people consuming and participating in the framework really have some, some means and motivation of cooperation, be that altruistic be that economic, you know, good examples of federations that, and trust frameworks that are functioning at large scale that have some of the dynamic properties that are people are looking at, would be in the, like the educational space where the universities are highly incented to collaborate and cooperate. So things, yeah,
Sh Schutze was a great example. Yep. We're seeing both the us government and the British government have, are, are set, are in the process of setting up and, and selecting trust or, or selecting trust frameworks, depending on the case. Another
Great point.
Yeah. And the, I think part of it, for example, you, you typically, you end up having a trust framework operator. So that's, I, I, I think Chuck made exactly the right point. You need a bunch of people who, who, who share the interest of having a trust framework. And then they probably nominate someone who makes sure that trust framework is operated properly. And so, for example, in Azure active directory, we, we actually have trust frameworks as entities that live inside our, our directory and the, the trust framework operators will be represented there. And trust frameworks will be represented there. And that can then be used, you know, in, in configuring a lot of the rest of the things.
So in regard to just close up on trust frameworks for a second, it's a big enough topic that we're gonna have to have separate webinars on trust framework. I
Think it's huge. So,
Yeah. And we're also preparing some documents, so we're running out of time. So I'm gonna just throw this one out, cuz I think it's good. And that's large to both of you, large organizations are very slow in adapting new protocols and spread it within the organization. Is there a recommendation how to start with doing this? Especially if partners, for example, at bank are even slower than our organization. So Chuck, why don't you try that first and then go ahead, Kim. And I think we're done after that.
Okay. Yeah, it, it's an excellent point. And you know, we're, we're really a firm believer that we're gonna continue to see hybrid architectures for a long time. It's not only that people are slow moving, but you know, large organizations have existing investments in technology that you know is working or that there may not be strong economic incentive to, to rip and replace in any big bang manner. So we, we think one of the main opportunities is that if you look at core imperatives for it organizations these days, it tends to be cloud and mobile applications that are big forcing functions for it investment as well as people looking at their existing IDM infrastructure and really running up against friction. Like how do I API expose this? How do I do, you know, API out for my organization? So we really think that cloud identity management systems, identity management as a service represents a nice transition path. As you start looking at those types of capabilities, you know, as you look at your social applications, your mobile applications, your applications that are up in the cloud, that's a good place to start rather than focusing on some things that you may have back buried inside the firewall. And then these can become enabling technologies that you get comfortable with. You can start interacting in partners in, in areas that have a little less friction and begin to pull those technologies back into your organizations as you get a little more success with them.
Hey Kim, instead of having you answer the same question, I think thanks a lot, Chuck. I think it was good. Let me throw another one because I think this is,
Can I just add one point though?
Oh yeah, sure. Go ahead.
Well, it's that, you know, both, I think that if you look at Salesforce or Microsoft, both of us have these big application suites that we're running in the cloud. And so basically people who use those application suites are already in, you know, creating these, these being part of the identity management as a service, if you wish, but the question may be what, how to extent do they want to take advantage of it? So I'd like, you know, I think that's very important cuz it's very incremental. It just, people actually will end up being involved in cloud-based directories just by virtue of using big cloud services. The, the second thing is the viral thing, which is a lot of this stuff is happening and a lot of Salesforce stuff, I see it all the time is happening, bottoms up, you know, departmental entities that, that, that adopt it. And then all of a sudden five departments have adopted it. And so on and incubation, incubation and projects. Sorry, just
That's good, but, but we've run out of time. So we're gonna have to go ahead and close this. And I, there are a few more questions that are really good ones that we want to answer. We will answer those and publish them in a few days. So thanks everyone for participating and appreciate your participation, especially Kim and Chuck. Thanks a lot. Yeah. Thank you.
Thanks, bye. All.
