SAML is Dead. Long Live SAML!

Welcome everyone. This is Craig Burton, distinguished Analyst for KuppingerCole and this slide doesn't show, but I have Pamela Dingle, the senior technical Analyst from, from ping identity with us today, and she's gonna participate. And I'm very excited about that. Pamela is very well known and schooled in these matters and will be a great participant. Welcome Pamela. Thank you.

So just go through a few things with you before we start, as you know, this is KACO, we have research and advisory and events, and especially, I want to remind you about the European identity and cloud conference that happens every spring in Munich this year, May 14th through the 17th. So just some quick guidelines here. Everyone is muted the panel and I, so you don't have to mute or unmute yourself. We will control that the recording of the webinar will be available tomorrow to everyone.

Now, the Q and a will be at the end of our discussion. You can ask questions at any time with the, in the chat box there and we'll queue those up. Or if there's something really relevant, right at the moment, the we'll we'll try and address that there, but it would prefer to try and do it at the end if we can. So there's we keep good pace. So let me go over the agenda here. First I'll present the view. Sam is dead.

I, I know this is a little bit tongue and cheek. Clearly something is important as SAML doesn't just die. And this is a perspective that I brought up at the cloud identity summit for that ping identity does this July and, and Colorado, and it's had a lot of controversy and discussion about it. So we've decided to continue it and talk about why I have that view.

And then the long loose Sammo Pamela will give a good perspective of why protocols change and move more slowly than, than just dying a sudden death that, that I point out and then Pam and I will discuss a little and then it'll have a Q and a. So this is a little more detail in the sections that I'm going to give. I'll do a little introduction to the API API economy ecosystem.

And the reason that I use this perspective is because it cuts right to the heart of why I think Sam and most of its current instantiations is incapable of embracing what has already happened, not what's going to happen in the future. So then I'll go over a little bit about what I call the Cambrian explosion of everything, actually that comes from Peter Vander, ARA from swift. But I think it really characterizes my point. And then one of the core tenants of, or axioms of the API economy that KuppingerCole is heading of, of following. And I'm doing that work is an API for everyone and everything.

Why admin based mapping of identity is broken a little bit about where things need to go with entity disservice automation. And then Pam will go through her long list, Sam presentation with a protocol fashion curve presentation. So these are the five API economy axioms for carpentry co. And I'm not saying that everyone needs to espouse these, but as we think about the API economy and the impact of the trends that are happening there that are so important, we've come up with these five basic tenants that I think should be thought about. Number one is everything.

And everyone will have an will be API enabled to is the API ecosystem is core to any, any cloud service. And that is, you know, if you're just signing a cloud service, you need to include the both budget and planning and thinking to embrace the API economy. Baking core competency in an API set is an imperative. And then the last two, which I think are really important, which is take the enterprise inside out and take the enterprise outside in with an API strategy. So let me just quickly go over how, just under our view about the API ecosystem and, and where that is.

And again, that the API ecosystem is divided into, into two types of API designs. I say, I misspelled two, if I didn't add a w so there's a type of there. One is the API provider and that's the enterprise inside out. And that's where you're providing an API to give access to your core competency, to your constituents. And as an API consumer, that's the enterprise outside in, and that's where you consume other APIs that are published by others, both what out, what I call open and dark, and also integrate those, that information and resource access with your business process.

So drilling down just a little bit, there again, the API I provider, which is the enterprise inside out, there are two types of APIs that we see emerging. One is called the open APIs, and these are the ones that are published for the outside consumption of your constituents. That that is publicly and well known.

So you, it doesn't necessarily mean that you have to have a one-to-one relationship with your constituent in order for them to consume your open APIs. The dark APIs though, are, are unpublished APIs for closed consumption. So for example, CNN Skype and salesforce.com, their API sets are open accessible. Anybody can get to them if they've been issued keys and are managed properly. Whereas dark APIs example of that, that I know of is there's a nutrition supplement company in the United States that that has a special API just for their resellers.

And they use the app on their iPhones and, and on their smartphones and tablets to access directly the, the sales sta statistics and delivery to their customers. Instead of going through a website or through a phone call, they can do it directly from their own personal app that accesses the data.

So next, moving on to the API consumer, where it's the enterprise outside in, instead of types you wanna think about API uses. And the main use of the enterprise outside in is to consume both open and dark APIs that are published by the constituents of a given organization, and also to integrate the results of that consumption with, with traditional and new business process. So Just for a little more expect perspective of what's happening and understanding that these numbers are actually old, here are a list of companies who we call the ER club.

And the, the source of this is from, from the program of a web, which I, I don't show there, but that's who that's. This is from, and the number of API calls and the amount of data that's in traffic. That's going on through APIs is just mind boggling. I'm not gonna cover each one of those. You can look at that now or later, as you review this, I'll quickly just unpack the Twitter. When 13 billion API calls a day is, you know, a million API calls a minute. That's just, that gives a little bit of an idea of why they're going through such growing pains enough down the impact of the matter.

So moving on past that quickly is to just think a little bit about understanding this ecosystem now understand that this graphic is just looking at the API provider side. So, so traditionally a organization providing information about itself goes through a website, port 80 and, and just browser access. But there are so many other Applications and methods by which there is now moving to require access and provide access to constituents. That it's much larger than just the traditional browser to server access and is, and imperative.

As I said earlier, I want to go over what's happening in the API growth rate in the last year, the number of open APIs, this is, this is open APIs has doubled in the years time and is moving at a hundred percent compound annual growth rate. I get a, an email from program of a web of the new open APIs that are published every week. And it's always between 70 and 150 per week. It's just mind boggling to look at that just a little bit. We just hit the 7,000 API mark. We'll be at 8,000 by year end in 2013, we'll hit the nine and 10,000 API open API mark. I think we'll be easily at 16,000 by 2015.

These are very conservative numbers at the current growth rates. Dark IPIs are a lot more difficult to actually count because they are dark. They're not, they, they aren't published. So you have to sort of extrapolate and make phone calls and ask. And the source of this information is from three scale because they do a lot of that research, but their projections. And I think it's probably, again, conservative is to be around five or five times more or less of the open API growth. So you can see what the current run rate is, and also what the projection should be. It's a lot.

Let's just say that. So now moving to, oh, I moving to The growth in the Cambridge area. So the reason I call it Cian explosion of growth is because in, in the eras of growth on the planet, there, there was a point in time. What half a million years ago, half billion years ago, it's been a long time, but nonetheless, where there was an explosion of growth of animal and plant life that was unprecedented and, and has never occurred since. And it was so big that it had its own era and it's called Cambridge area.

So I think we're in a similar sort of thing, relative thing with what's happening with the growth of API access. So just this week on the 12th, apple of course announced the iPhone five, but as I watched the presentation, what I saw that that was relevant and especially to this conversation was the, the numbers that were given at the very beginning.

And the, and I, I wanna just go over those because they're so incredible and also relevant to our discussion. So he pointed out that there are 400 million iOS devices right now, let that sink in.

It's the, the it's just mind boggling 700,000 apps. The average person actually uses a hundred plus apps per device. There are now 84 million iPads. That's 68% market share year to year in 2012 that's. And in the last quarter from April to June, apple sold 17 million iPads. That's more iPads.

You know, that's more devices than any other PC vendors sold in the same year of their entire product line. I don't know if that number, those numbers are actually accurate, but that's that the position they took.

And I, I suspect that it likely is. And then the, the really interesting thing that he said was that 90, that, that this isn't just in education and individuals, 94% of fortune 500 companies are investing or deploying in iPads at work.

And, but the, these, these numbers, as you'll see in a moment are so remained to, to understanding that the imperative to be doing, embracing the API economy and to, to understand how to automate identity mapping to services and keep things secure is, is so important. So moving to Cisco's predictions, just to bolster my thinking here is centered around API 10, the, the carpenter co API 10, and number one, which is an API that everything and everyone will have an API. So Cisco's predictions were 2.8 devices per person on the planet by 2015.

Now don't interpret that to mean that every person on the planet will have 2.8 devices, just that, that the numbers are like that. So that means 19.6 billion devices And 7 billion people.

So it's, I mean, the numbers are, aren't exactly accurate, but it, but it gives you an idea of some 26 billion entities with just one with just a number of devices and a number of people. And, and so if you say that everyone and everything has an API, the numbers there are, are staggering. So this then sets up why the way Sam is implemented from every vendor who has a Sam implementation is a problem because this ad, because they're all admin intensive. And so it requires an administrator to do the mapping between any entity and any service and any identifier for use of that service.

So If, if you look at the numbers that I just did just for apple, and just for the number of people that Cisco's provided, and those are conservative, how do you map 26 billion entities in five years to one, just one service? And the reality is that there's many, one, many identities and many services it's even bigger than that. So I did the math and it's, if we had 640,000 plus admins, all working 24 hours a day for five years, that's how long it would take them just to do one entity to, to one service with, and, and, and in reality, it's bigger than that.

So the, the, my position there is that the way we're doing it right now, it's broken and simply doesn't scale can't address. What's already happening on what's going to happen in the future. So here's another kind of a new term that we're coining an entity to service automation, because that's what I think has to occur in order to solve this problem in order for, for Sam or any other mapping mechanism to, to entities, to services, identity mapping has to be done through an API and automated and not done by hand by an administrator And any other method. I just can't see how it's possible.

It's not there aren't enough admins alive on the planet to do the job or enough time and further these numbers are conservative. So what is it then that is gonna happen?

Well, we, we are all of the opinion and open ID connect is Sam's API future and, and can provide the, potentially provide the API or automated infrastructure protocol, capable of letting the existing and future channel legacy and new customers to get these mappings done in a way that is usable. However, no vendor is doing automation yet, or using open ID connected to this. The trackability of open ID cat connect is still unknown.

And, and no one is doing entity service automation at all. There have been some proprietary individual vendor centric approaches to this. And while those are admirable, they're not adequate. It needs to be done in an industry way, so all can participate and interact with each other to do it.

Now, skim is a protocol without an API, but uses oof and works well with Sam to, and is a potential protocol also in conjunction with open ID connect to that will help. But again, this is also new.

We don't, we just don't know. So I've covered my position in thinking I'm gonna introduce you to Pamela Ingle and let her go over her view.

So Pamela, welcome and go right ahead and I'll advance these slides for you. All right, Craig, can you hear me? I can Assuming I'm off mute now.

Oh, good. It's nothing worse than talking to a room that can't hear you. Great. Thanks Craig. Yes. My name is Pamela Dingle. I work for a company called ping identity and I am a senior technical architect for them in their, in the office at the CTO. So we talk to a lot of customers. We make a product that does API security today. It does OWA 2.0 and has since August of last year, our product also works with Sams.

So we, you know, we, we really believe in all of these protocols. We're not trying to push one over the other. We simply wanna make our customers happy. And so you can imagine that this represents, I believe the pragmatic approach that most of our customers take. And so the first thing I have to say is that the only protocol that matters is the one that you can actually connect with. It can be a decade old. It can have been around for an eon, but if it actually allows you to pass identity information from an authoritative source to something that wants to consume it, then it wins.

And as such, what I find in the identity industry and in Federation specifically, is that you get the thing working. It's happy, your users are happy. You never touch it again. Right? Many of our customers have very old SAML, 1.1 implementations.

They have, you know, very old integrations that they've had around for years. And generally speaking, there is no concept of, of renewing those until a business choice has to be made that causes you to make a change. So as such, I would say that it's a very much a case of looking for a Swiss army knife. You wanna be able to make as many flexible decisions to make your partners happy and to support a successful Federation as possible, but we can't just do that.

So we really have two jobs as far as I'm concerned, especially when you're running a large organization and you're in charge of identity for that organization. You have to be able to deal with the comfort of the moment. You have to be able to quickly deploy federations. You have to be able to interact with your, with your end users and, you know, accept the responsibility for authentication decisions like two-factor authentication or anything else. But you also have to keep an eye on the future. Let me know when you want me to advance.

Yeah, I will. I might get you to mute though, Craig, cause I can, I can hear you a bit. Oh yeah. That's all right. So when I've, you know, when I, for example, went out in Google's fashion, because I like to put pre pictures in my presentations, it turns out that red bridal dresses are in fashion this year. And ironically, I would never have known that such a trend existed. And you know, there's a very small group of people who actually have to care about that trend. All that has to happen is a few experts need to care.

And then it gets pushed through a system that ends up with a red bridal dress available in Walmart for 99 95. And people can make comfort decisions based on a fashion that has come down the pipe and been shepherded through a system by the people who are in the know, Craig, go ahead and flip me to the next one, if you will. All right. So what does that mean for the API economy? I completely agree with Craig that this API economy is coming. It is crucial and it is the new fashion coming down the line and every single one of us needs to pay attention to it. All right.

And as much as fashion seems like a very flippant analogy to make it matters that we protect against new business cases and device security is the new business case that's happening. So we have no choice, but to open our eyes and look ahead and say, yes, things are gonna change. We have to expect our architecture to change. We have to adapt to whatever's gonna happen in the future. So I think everyone out there should be expecting to add an API security component to their, to their organization. If they're a large organization in, you know, the near future.

And we expect that most of the security around this is going to be oof, 2.0, but I think it's absolutely critical to understand the difference between what Sam does and what API security apps like OAuth 2.0, do, because they don't do the same thing. And you know, the issue I have with the idea that Sam is dead is that the implication is that OAuth will replace it. And I don't believe that's the case.

They, they work together. They're complimentary to each other. They do not replace each other. Go ahead. Great. So what does that mean?

Well, it means that just like every other Federation protocol before it, Sam will be a critical piece of your wardrobe for a long, long time to come. Will it solve all your problems? Absolutely not. Sam does not.

You know, Sam has always been a user present protocol, right? Sam is about sending an assertion that represents an authenticated user between domains. That is actually very different than what an OAuth does. OAuth is about device authentication. It's about a device showing up at an API and presenting a token that token represents not the user present and authenticated, but a delegated right of the user. And so that's a very, very different thing.

When we talk about, you know, when Craig talks about 54 million logins, an hour or 54 million API FES an hour, some very small portion of those such as our actual identity, you know, consent or authentication events. So, well, I do believe that this is a very important wave.

This, this API security wave and the enterprise API economy is gonna be a big deal. I don't believe that the scale that SAML is incapable of taking care of the identity piece of an API economy, keep in mind that you only really need to use SAML when you're sending identities across domain boundaries. So what we expect to see is, for example, if you have a third party that you're interacting with, you may be acting as an API client to that third party, but you may also be wanting to assert identity across for the initial consent or for web single sign on Sam will still works for that.

Sam does a great job with that. You don't have to send a Sam assertion for every iPad you register, nor should you. So is it perfect?

No, but I believe that it is good enough for us to layer API security on top of a Sam infrastructure and at least get started. Now Craig mentioned open ID connect. I completely support that idea. I believe that open ID connect is going to be crucial to us in the identity industry, but like any identity protocol. It takes time.

I, I mean, Craig also mentioned that. So there is this point of time between now and the point where open ID connect is well known. Well loved, well tested, well interoperable, well interoperable. I don't think that's a correct grammatical statement, but you, you get my point. There is a, there is a point in time where you will be constructing your federations with SAML, and I believe you will be successful in that enterprise.

Craig, you can go to my last slide. So what does this mean? Realistically? It means that you will have change coming down the pipe. You should be looking at oat two. And most importantly, if you're watching this and you're saying to yourself, what API security APIs are, the developer's problem, not my problem. Then you need to screw your head off, turn it around and screw it back on because everything is moving to this API interface.

And if you, as the identity person is not involved, that means that your it department has completely given up a ton of responsibility for securing your organization. So my advice to you is to a B looking for API security, or at least a discussion on API security from all of your vendors, you should be getting involved in the API operations of your company, no matter how big or small that company is, you should be aware of when your company is acting as an API client, calling out to other organizations.

And, you know, you should be looking at design patterns that layer Sam on top of OSU, where it's appropriate. You know, there are a couple of design patterns, for example, that really let you use your existing, your, your existing architecture, but still participate in the API economy. So an example to this is the case where you have a, a huge Ws star component in your business.

And you, you know, you may think that because you have such an XML investment that you can't participate here, but you can it's transformable. So you can set up a restful API that sits around the outside of your enterprise and you can use O two tokens and transform them to Ws trust, you know, Sam tokens using the Ws trust protocol by putting something at the edge of your enterprise. So that's one example.

You can also put Sam tokens, make Sam tokens into the token that gets sent via OAuth so that you can still use your SAML infrastructure and you still get the ease of use of something like oat two. So that would be my passionate plea for the life of, of SAML. And I would like to note that there's in fact, a webinar happening on the 25th of September at 11:00 AM, Eastern time, us Eastern time about what SAML 2.1 will contain.

So if you're interested in seeing what that next generation of Sam will be, you, you can probably look for that online and follow that webinar to find out, Okay, so quickly now we'll go to a little discussion between him and I about how the graphic on the right, I think represents the thinking that, that this is a fashion protocol. I think it's a good metaphor if we were in normal times and that we are not. And indeed I would say that that, That this perspective, that all is well and that we can just sit around and wait for and hang 10.

What we wait for the protocol trend of, or, or fashion to catch up with is night. And that what has already washed over is, is a huge wave from device to the internet of things, to entities and individuals and programs that are trying to, that have to have access to information and resources within organizations or, or those organizations are in trouble. And this isn't something that's going to happen in a couple years, it's already happened and we need to be pulling our heads out of the sand and deal with it as fast as possible.

And it can't be done via the traditional mechanisms that are found in the existing sample products, Pam. So I would say, absolutely, that is true. But most of us in the vendor community have known this for a long time. And so there is a long list of vendors that will help you to, to do API security. And whether that involves Sam or doesn't involve Samil, you know, there are a ton of options available to people today. I would say that that needs to be the order.

So yes, if you're an Analyst, you should be panicking right now because you can see what's coming. If you're a vendor and you don't have some kind of way to handle devices in your identity product today, then you're, it's too late. You're in trouble, right?

You are, you are scrambling to catch up. If you're a large enterprise, you're probably already doing this. Most of our large customers are far down the road of API security.

So, you know, I do believe you're right. There is a wave coming in. It is an important wave, but many people are already taking action. And the people who aren't taking action, the smaller companies, they can't.

I mean, when identity's not your core business, you are in some senses at the whim of the fashionistas. You, you wait, you see what looks good when it's something that you think is gonna serve your business, then you pick it up and you run with it.

Well, I can't, I just think it's at the wave of, of the explosion of everything and the need to connect devices to us is not a wave that's coming. It's already washed over us. So why don't we go ahead and look at some of these questions, Pam, because one of them comes to you. So it says, did you, can you see it? I cannot see it. Okay. So it says, my understanding is that Sam is not good for cross domain authentication. Can you come on on this?

I, I don't, that's what it's for. So Yeah, Sam is, Sam is exactly for asserting identity across domains. So what Sam does is it creates a structured document. That's usually an XML file that actually says who the user is and gives attributes about the user, but also gives cryptographically verifiable information about who is making the assertion. So what a Santo, what a San token will do is replace a shared secret, like a password. And it does so in a way that you can forensically evaluate and you have multiple points to make sure that the assertion that arrives is correct. Good. Thank you.

So Another question that just came up and I'll read it and I'll answer it and let you also answer, ma'am sure it says, it says, and I quote, this many companies are outsourcing it functions to outside providers. At what point do we just make this to the end degree and just let organizations like Google or apple handle identity for us, or is that too scary? So to answer that question, I actually think that, that the basic infrastructure to do identity as a service, which would be outsourcing that to another company is going to happen.

And that the leader in doing that is not, is neither Google or apple. Matter of fact, I, I think Google and apple are way off base in doing this. And apple is the furthest bind.

It, it, it appears ironically that apple does not understand cross domain single sign on and, and cross device identity at all. It's so focused on itself. And that makes sense, given they think they are invincible. So one company that I do see actually understanding this surprisingly is Microsoft and Kim Cameron is leading building infrastructure that is basically outsourceable identity management as a service.

And the, and that is indeed what, what Azure active directory is about. So yes, I do expect to see that happen. I expect to see it from a industry of vendors, not just one and that the one, the, the leader in even thinking about and doing it is, is Microsoft. So Yeah. What do you think I would, I would agree it's it's in fact happening today, but there's actually one additional question that, that, that comes to bear on this. And that is where does the actual user data validation data sit?

So right now, I think what I would call the most common pattern is that you put your identity service in the cloud, but you keep your directory with your user information at home, right? So, so this is the idea that your identity service has to call home to validate your users, either with an L D call that gets punched through a hole in your firewall or through a small agent that does still stay on premise that securely sends validates the user's password and sends information back up to the identity in the cloud.

However, the new trend is, I mean, what Craig is talking about is this idea of actually storing your, your authoritative user database in the cloud. So Salesforce is a perfect example of this. Microsoft is an example of this Google apps for your domain. Google apps for business is another example. And we're seeing, you know, these are the options for companies who really don't wanna have data centers, right? They have to store even their, even their usernames and passwords. Everything goes into the cloud.

So that's happening today and I expect it to continue, but there are some companies that will never do this. They will never ever, you know, for regulatory reasons or, you know, whatever the reasons are, they will never ever put their identity infrastructure outside of their, their domain. And I think we have to support both models and expect they'll both continue.

Thanks, Pam. So the next question says, and I, I, I want you to answer this to, even though it's directed at me, it says, okay, Craig, how do you deal with 2.8 billion identities? And by the way, that's 26.6 billion, not 2.8, any and who numbers them, who vets them, what fraud is possible, what is the meta system? And does it really matter whether it's OAuth Sam open ID? Okay.

So again, the it's another order of magnitude and larger than you're saying and who vets them is the very question that I'm trying to address here, betting them needs to be done via mechanisms that can be automated. Now, what we haven't talked about is that there, there is a trust model that is probably gonna have to come into play. That is more complicated than what we use today, which is an ID, a single identity provider being the third party that, that, that that's the identity of the requester for access to, to resources. And that what we'll most likely do is move to a more complicated.

What, what we're calling a trust framework model for, for as a meta system for vetting and, and giving a A, Shall we say, a factor of reliability of the person being who they say they are both, both for a peer based and also paid mechanisms that organizations can do to make sure that the entities, not just individuals, because this, this view isn't to just say it's about people or even organizations, it can be an application representing an organization or a whole group of organizations that isn't really a person.

How do you know that that entity is something that you should grant access to your resources for, or if they are, is in, is not causing fraud or difficulties that go down that could bite you later, Pam? Well, first thing I would say is, is that we're talking about these, these, I, you know, the identities of these devices as things that everyone everywhere will have to deal with.

And I, I don't think that's realistic, at least in the short term. So most people who are running identity infrastructures today, unless you're Facebook are dealing with a very small subset of those identities. And so you really only have to interact with the identities that are re relevant to you. That's a bit of a cop out because yes, I believe these identities will still scale.

However, if you look at the responsibilities of the average enterprise, they're not going to have to deal with every iPad on the planet. They only have to manage the iPad associated with, you know, the hundreds, thousands, 10 thousands of users that they're, that they're worried about.

So I, I think that we, you know, just the fact that we're dealing with a specific Only that, Sorry, Craig, I'm just teasing you only 20,000, Only 20,000. Well, yeah.

I mean, that's why I say it's a bit of a cough out. However, I mean, it is useful to chunk these things down into manageable proportions. So nobody is likely, right. Probably nobody on this call. Nobody I work with is likely to have to manage every, a, an identity for every person on the planet. The people who are responsible for it have a very different problem. But you know, when we talk about this stuff, we're not talking about discovering the global identity of one of these devices. We're just, we're talking about a device registering itself to become useful in a network.

And, you know, the, the mechanism that happens for that today is, is something called a public client, right? So when you, you think about a game application that gets deployed to every iPhone in America or every iPhone in the world, they don't each have separate unique identities in, in most oats, you know, in the oats systems that are associated with their servers, they tend to have generic client IDs. So it will be the same client identifier that is calling into an API. It just happens to be deployed on 1.2 million iPads. So that changes the scale calculation too.

You're not having to authenticate and register separate client IDs for every single iPhone instance of an iPhone app only for the iPhone app itself. Now, will that change possibly because trying to actually manage individual clients when everybody has the same client identifier is a problem, but you know, we do have mechanisms right now to deal with this kind of scale. I'm sure they will evolve to become smarter. Thanks. Ma'am so the next question here is, is a complicated one, and I'll try to keep it simple here.

It says, since the organizations are still not migrated in Tyler to APIs, we still have web browser based applications. So my question is instead of implementing different solutions, one for browser based apps and one for API based apps, do you suggest a common way to support both users? Okay.

So to, to have a single server that can manage all of your applications within an organization and thus have a mechanism that does one single time authentication for all entities is not practical and it's not gonna happen that way. It it's in the same way that you can't scale an individual's entities being authenticated to many systems. You can't have one system authenticating everybody that wants access to all your information and resources.

So it's going to be many to many on both sides, many identities trying to gain access and many services that are relevant, and some of which are in control by your company. And some of which are not, this, this again is why naming Federation comes, comes into play. And it's so important is because it is both cross domain and cross organization and cross individual. So it it's, it's a huge met network of identities, identifiers information, resources, and identity providers. And that makes it very complicated and makes it difficult.

And, but, you know, it's not any more difficult than many of the problems we've already resolved. So we just need to be more move ahead with intentionality to address it at a faster pace than we normally look at putting out protocols to address these kinds of problems. Normally it takes 10 years for a, an existing protocol to address this. And we simply don't have that kind of time. It's it's like, I've already pointed out here, this trend, isn't something that's going to happen tomorrow. It's already happened. It's already in our face. We need to stand up and address it.

So the answer is, no, you can't do it that way. You need to be figuring out how to have an ecosystem of identity management for all of the information and resources that you consume and all the information and resources that you provide.

Pam, any comments on that? Well, I actually interpreted the question slightly differently, so I'm not sure which one's right, but if, if the concern is this idea that you have to give different instructions to your partners, if they're web browser partners compared to giving instructions to your partners who are writing client applications like native apps on a phone today, it certainly is bifurcated.

You know, the best practices Sam on the website. And it's oof, 2.0 on for native apps. My answer to that would be that open ID connect is your hope for the future. Open ID connect will give you the ability to do both web browser single sign on and native client apps. So if you can imagine a case where, you know, you really putting to practice everything Craig is saying, and you've essentially set up your enterprise as a cloud platform, right? You are the, you are, you know, no different than a sales force. And you are trying to put out a set of APIs that are static.

And one way that those APIs can be used to, to establish sessions or securely request scopes for apps to, to access APIs, open connect is the thing that's gonna make you happy. And it's gonna be the one thing you can hand them a document and say, if you're compliant with this, you will be able to access our platform. Would you agree, Craig? Is that Yeah, like I said, it's a complicated question.

So I, I, I Think you're entering on the meta level. Yeah, I, I, yeah, so I think we're out of time and there are some more questions and so on, but we need to close, but let me just go through this summary. I went through the API economy enterprise inside, out and outside in the Cambridge explosion of everything. And this post PC identity crunch, and Pamela went through protocols as fashion. I'm sorry. I had to Google.

So our, our, both our recommendations are get on board for managing this Cambridge explosion. As soon as you can understand the implications, try to get your arms around it and understand what the SAML options are now and what they're looking like in the future. And finally move with intent towards understanding and implementing management identity automation. So I want to encourage you to get a hold of either Pamela or I, you know, I, I'm not showing either of our emails. I'm gonna give you mine and then I'll have Pam give you hers and please feel free to do that.

And we look forward to hear from you and then we'll close. So my email is CB that's for Craig Burton, CB Kuppinger com and Mine is P Dingle, P D I N G E. Ping identity.com. I wanna thank everybody and especially UPenn for attending and thank you very much and look forward to the next opportunity. That was really fun.

Thanks, Craig.