In thinking about life management platform, it, it would be real easy to fall into the trap that what we're looking for is another silo. And that some vendor is going to own this and be able to impinge their, their technologies on you. And the way we see it at KuppingerCole is that it it's a concept that is designed to not be dominated by a vendor. Now, many times, the approach that the industry takes to make sure that happens is go to open source providers the way we see it. There's nothing wrong with open source, but it's not a requirement. It's not, doesn't have to happen nothing again, nothing wrong with it, but it's not something that we feel is a minimal requirement or even a broader one. It, this can be done by commercial vendors just as easy it could by open source.
And one of the other reasons is because we wanted it on all devices, not just opensource platform or operating systems. So, you know, we want to see it on your mobile device, your laptop, your traditional system, and on Linux systems too. So, you know, lots of platforms that can be done that way, but in general, what we see the life management platform is, is a living evolutionary product that is a set of services all at layer seven. Interestingly enough, you know, it's not the, it's not the plumbing, it's a set of services that inter operate well with each other from and from different vendors. So that you're never locked in to a particular vendor in order to use that service. And yet can still be interoperable and communicate with other individual services and individual life management platform frameworks. So in thinking about that, we've come up with a, a set of minimal requirements that, that will drive that there might be some that come up later, but here's, here's what they are. We want the, the API designed to be restful. We think that OAuth is the best authentication mechanism right now.
So, you know, the combination of restful APIs coupled with OAuth authentication is a start there. The next is that they're loosely coupled you don't require services to have to have a state stateful connection that can be stateless. Matter of fact, by design, it should be the other is event driven. And the reason you want it to be event driven is that when there is an, a service or a, or a device or a component in your life management infrastructure that has something happen and needs to communicate with another component, the way that it does that is to signal an event. And then the logic around other systems could say, Hey event happened, what do I do? So that's a loosely couple part. If, whereas if I have to do, and recently there's a lot of talk about how the internet of things we're gonna create a protocol that teaches these things to communicate to each other directly, never happen.
It's never going to happen it the way to do it is keep them loosely coupled and use events systems to go back and forth between the communication with business logic in between them. And that's what the web hook is for is a structure whereby these two components can do event driven communications. And finally, really important is what I call a facade proxy. And there's a lot written about that. But the facade proxy basically is a shows you a time and place to do privacy by design so that you're making sure that informed out and permissioned input is or controlled input is maintained. If, if we can't maintain the privacy in this design, then it's never gonna get off the ground. So the, the closest thing that's happening in the restful community is a facade proxy that lets you design specifically through trust frameworks. What the privacy components are, have two communi communicating systems. Now I think I would add that another really picketing that's making this like management platform so compelling is, or a couple of things. And it's the five tenets of, of the carpentry co API economy. And one is that everything and every one will be IPA API enabled. Now, when you start thinking about how big that
Is, it's trillions of identities in the next 20 years, that need to be not just generated, but generated just in time automated and regenerated. I really liked Pam Eagle's notion today that our binary thinking of what an object does when it presents itself as a, to be identified and authenticated, it isn't gonna work. And when you're talking about trends of identity, you can start to think why cuz the ability to manage that in any way, shape or form that will scale is extremely difficult. So the combination of a trust framework, which gives you the analog elements that so you don't have to have binary is coupled with the API economy is going to build that foundation for us. Anyway, finally, one thing that really helps in understanding life management platform is to state some of the things that's not, oh, I didn't tell you the rest of the tenants of the API economy. One is I said everything and everyone will be API enabled.
Then the other is, if you're not engaged in creating a strategy in your organization to be both a API provider and consumer you're, you're behind the game, you need to get involved with that. And then the other two that are really important here, the enterprise inside out and the enterprise outside in, and that's the API consumption coming in and API consumption coming out. And it's very similar to the things we talk about with the life management platform and why I like the notion of an enterprise of one, because you become as important as a big company. When you have a life management platform that operates, cuz now it's become your it infrastructure. That's letting you deal with the planet in an organized way. So two other little things, what life management platform is not, is it's not a social network and it's also not a personal data store. These are elements there that are, that the life management platform supersede it's much bigger than that. So there's my basic little review. Great.
