My name is Alejandro. I'm a research Analyst at Coco.
My name is Watts.
Yeah. Check this. Yeah. So my name is Watts from one. Welcome before joining one. Welcome. I was building an authorization platform called scale access required by one talk a little bit more about,
Yeah, and my name is, and I'm heading to called style here in Europe creators and, and, or in Europe extent.
Well, thank you for the introduction, maybe for the members of the audience who perhaps are not very familiar with open. Maybe we can start talking about what ISPA and perhaps later we can expand on why open is growing so much.
Yeah,
You can start.
Yeah, I can start. Should I have this one or? Okay. SOPA is an open source. It's a Polish engine or called trust engine. So it's real an authorization solution. So the idea with OPPA is that instead of writing authorization in code in a microservice and APIs, you put it in an open Porwal and decouple it to get to dynamic and easily manageable because writing authorization in code worked kind of okay in a legacy application, but when you're moving to cloud native or microservice, you have much more complicated, much more moving part. And that means that you need to do authorization in a new way. So there lot of bold statements for, by, for all of authorization needs for the cloud nature stack that study.
Yep. And we, as a, as a software company, we wanted to build an externalized authorization service where we link an authorization to identity and not only to one identity, but to multiple identities that have relationships with each other. And so we were back in 2018, something like that. We were looking at how to include one, how to build one piece of that, that big puzzle. And we needed the rules engine. And there that that's when we started looking at options when we needed, wanted to build it from scratch or whether we wanted to use an open source rules engine. And that's how we started using actually as one of the first early adopters, I would say. Yeah, apparently next to Netflix as a yeah.
I
Early adopter
Oprah was released in a carbon computer foundation 2018. And you must have picked it up more or less the same time. Yeah. Correct.
You mentioned
That OPPA first was initiated, let's say a few years ago. How's the picture these days? Is it different?
Well, if you look well, only the short time I, that I've been working for Tyra when I joined Tyra year and a half ago, a little bit more, we had like 7 million downloads and we were on the open slack channel, which is the place to be, if you want information, there were like 1700 uses or something like that. And we thought we had grown a lot in, because that was 2020, this, and we joined 2018 in a ator computer foundation. After that we graduated last year in February, and last month we actually passed 130 million downloads. So it's real exploded. And we are closing in on 6,000 people on Uber slack channel. So Uber has quickly become the defactor standard for authorization in the cloud native stack. So I don't see any other initiative actually out there that are on the same size and the same traction.
What's your take on,
What's
Your, yeah. What's your take on that or so it all makes sense. So I think from the, the, the, the design principles of the rules engine implemented by OPPA are, are actually pretty old. So they go back to 93, 94, where there was a standard called network access control, NA, and it, it started making a distinction between an enforcement point and a decision point. So one component is basically determined whether something is allowed or not. And the other one takes a decision based on context and based on resources and based on attributes and making the distinction between these two is, is an idea that has been around for quite some time. And there also have been some standards likes that actually tried to build the factor standard for, for implementing this, this architecture. But the way how open now basically has redesigned the way, how that we can define policies based on Jason and, and, and, and, and our type of, of language makes actually easy to adopt. And I think that's one of the reasons why there isn't indeed such and adoption in, in the deaf community. You know, when I first started to, to read about OPPA, I was first of all, very interested in, in the idea how, how it all works. And I'm just wondering maybe the members of the audience would like to know who uses OPPA and, and why would they USEPA?
Well, it's, it's not an easy, it's one easy answer. Is that more or less everyone working in a cloud native environment uses open one way or another? Because the beauty of ATPA is that is so flexible. And that's one of the biggest difference. If you compare it to old SAC models and things like that, SOPA can work with Annie input and we can have Annie output extremely flexible, but that also means that the use cases are extremely broad. So we have people using OPPA for admission control for Kubernetes. It's one other use cases. We have people using OPA protected CICD pipelines who can improve things. We have people who wetting the Terraform pipelines. We live, we are people actually probably the biggest use case don't authorization for microservices, which is what you are into and APIs. But we also using see people now more and more adapting, actually dynamic filtration on databases and things like that.
So we really are in every place in the cloud native stack with the open poly surgeon. So that's what we see. And I think that's the beauty of ITPA. That's why he's growing so fast and is really been embraced at first by developers, more than identity people. But now we see is growing up. And when it goes from developers up to like production red and identity, then you need to have like a governance to around it, best practice, a control plane. That's that's the biggest difference between working with SMA and power was that when I was working with SMA, I needed to explain what is authorization? Why should you do that? What's the benefits. Now my conversation is more or less. Okay. We have used, we have used for three months, six months. We like it. Can you please tell me how to deploy it? The scale, what are the best practice? How should we deploy it in production? That's the questions I get today.
And actually on, on, on this use cases, the ones that you mentioned are still very much into the deaf community. Yeah. By productizing the rules engine, we actually implement use cases that much more linked to business use cases. Let's take insurance as an example. So in, in an insurance business, you've got an insurance policy and you've got an owner or a subscriber of an insurance policy. The fact that somebody is, is, is the owner of an insurance policy, gives them the permission to maybe invite other people to see that insurance policy as well. And so this is actually also an if then else clause, which we implement in, in a, as a rules engine, but the it's it's truly business, business logic. And the way to deal with that is that we, that we started basically building a, a management UI around policy editing so that you basically have a graphical user interface where, where business Analyst, Analyst, maybe not a business owner, but the business Analyst can basically start working with rules that are externalized from the business logic.
Yeah. I remember when, when I first spoke to you too, you were kind of half jokingly that you were in a way competitors, but seems like in the
Long run, it's going to be a bit different.
No, I think in the long run, we'll still be competitors. We are competitors. We are competing for the same business. I think we have a little bit more broad UR. So we're going after other pieces of business as well. But yes, we are competitors, but we both open users and there are, are a lot OFS elastic water company that are using OPPA to put in their stack. And we see a lot of other company we have con coma have embedded in the latest releases. So we see more and more address software companies embracing OPPA. And we will see that even more, I think, and Starra as a company are happy for that because we, we really want to better grow because the authorization market is rather untapped market. How many authentication providers do we have here today at exhibition floor 5, 6, 8, something like that? How many authorization providers do we have two
Kind of,
Kind of, and give us a few years, and we will be as manual authorization providers as authentication providers, because authorization is much more important.
Yeah, I, I can, I, I can completely support that idea. So whether we are competing or not, actually that's not relevant, but what is relevant is that the, the, the, the identity problem that has kind of been, that has been resolved. And so we, the industry, we, it took us like 10 years, 15 years to, to go from anonymous to known. So, and now we know who the identity is. So that has been resolved. The next big challenge is for me is what is that user allowed to do? And the fact that that is a decision that you basically want to centralize and that you want to decouple from backend logic. And that's the reasonable existence of, of, of actually both of us. Yeah. And even in the long run. So, so today you've got authorizations linked to an identifier of a user, but in the long run that identifier of user will become sophisticated or, or will be removed completely at a certain point in time think verifiable credential, stuff like that. And so in, in this era, managing authorizations becomes even more important than it is today.
Sure. So we, in that context, how do you think about as the engine and how to manage the data? It needs to make these
Decisions? Very good question. Yeah. That is exactly the reason why we do not only have a rules engine. Okay. But we combine it with data. So in the one world platform, we've got data about users, but we also have data about relationships between users and things, data object that they actually use. And so combining data with rules and policy basically puts you into position that you've got that we've got an authorizations platform that, that is easier to use because you do not have to care about the data anymore as a consumer, as user.
Yeah. And I kind agree on that one, and that's why we have a Tyra. And our also we have built a management platform on top just to do that, to control P scale, because as you say, yes, having APA without data, it will not bring you a volume. And what we see from the implementation, there are free ways to put data into today. You can send it into open the request and that we see that happens more or less every use case. So people are using that to send in a token and an action or something, and then you can load up data in a bundle in OPPA. And that we see very, very common, I wouldn't say a hundred percent, but 80, 90% of the use cases in the API Microsofts using that, what we call the bundle API. So they cash data in OPPA. The reason for that is to get performance in single leg at millisecond. So we want that there is a third way, and that is fetch data during evaluation. And people know that, but they really try to avoid it as long as possible because it will impact latency. It will add latency. If you do that,
Not only latency I'm worried about. Yeah. You can change your data sets that you're using to make your decisions most. Yeah. So your integrity of your decision engine should ideally be read only and deterministic.
Yeah. Our decision will never be better than data. It's a start.
Yeah.
One of the misconceptions in the, the, the PDP pep discussion is very often that people think that you can only have one decision endpoint and you can only have one enforcement endpoint while I, I think that that's a misconception. I think that it's more like from a design point of view, it's like a serial connection of different enforcement endpoints and different decision endpoints that each deal with a certain level of granularity. And so to come back, come back to your point. So the, at, at the, at the initial steps, in the journey of the end user, we want to have a, a fairly core grained decision, whether this user is allowed to continue his journey. And that course gain crane decision is based on the rule. And the outcome of that rule is, is an authorization decision that we inject in a, in a, in an access token, and basically becomes part of a piece of data that can be fed into a rules engine, which is for the down the line. And so that's, that's basically how you, you, you got the elephant in different levels of granularity. Make sense? Yeah.
Yeah.
Perhaps now we can share the biggest takeaway and maybe we can then open the floor to some questions.
Yeah. I would say the biggest takeaway is that OPPA, even as being a young technology is growing, is growing fast. And I think we'll see even more implementations, OFA, more people picking it up. So when we are here in a year or two years, we will have not like four empty shares. We will be probably five or six more people are talking ATPA why should we use it? And how are different when's using it? That's my takeaway.
And my takeaway would be that I'm very happy with the adoption of OPPA, because it, it helps the market to understand that you can truly externalize authorizations from backend platforms. So what we, what we've seen like 10 years ago, it was, it was a battle to convince developers to, to, to basically give away a piece of their puzzle to an external system. And I think now with the adoption of OPA the developer community starts to see a benefit of externalized authorization, externalizing, authorizations from their code base. Yeah. Thank you for such a fruitful discussion. Now we can open the floor to some questions there, any
Let somebody else go for, yeah.
Hi, thank you for this very nice presentation. I would basically like, like a feedback or a comment because when, when you're talking about OPPA and policy as code more, more or less people always think about APIs and access management, but what we are experiencing lately, at least in this user centric, identity world, or SSI where digital credentials come into play, you see that verification becomes an extremely costly process in terms of design and development and maintaining policies. So would you believe that that using OPPA in, in, in such case would make sense and is the life of, of, of development and design? So, so this is one. And then, then, then a subsequent question, we also see that we have different trust frameworks are European Canadian us, so on, so forth. And those policies are today written like, like by lawyers and, and regulators, but at some point digitalizing and trust translating them would probably simplify the interaction and probably ease the interoperability or translation between what's your thought on that?
Yeah, I can start. And I think that will happen more and more. We have done a first try on the Kubernetes side where we have like PCI policies and things that we have written Ingo and that we have had external auditors looked and pro. So I think it's very possible to do that. I haven't seen any attempt really to do that yet, but give it a few years. And I think that will happen because it's like policies and policies has coded. So we, we just need to write it in one way or another.
Yeah. And, and in terms of maintainability, if you externalize authorizations from your, your main code, you, you, you basically get a component with, with its own life cycle with it's a very small component. So I would argue that it's easier to maintain a small component than a big component. Yeah. So since that any change in authorizations doesn't need to go through complete software lifecycle anymore. It needs to go through testing and what have you. But at the end, the, the, the change that needs to be done is fairly, very condensed, very centralized, make sense.
The was some other question, one short one, we got time. Yeah.
So I'm, I'm super happy with the success of OPA, but it's like, so what is the thought about standardization? Right? It's like, if there's one thing that's authentication taught us, as soon as we have standards and protocols, it will all start to expand and alignment will happen. So what is the thought from OPA about driving standardization, how the language ego fits into this, which is an interesting choice. And so just one or two, see what you think about that.
Yeah. That's, I'm not the right person to answer that I should have to in our VP of open source here, I haven't heard anything. And our view is that so far that we have it open sourced. So that is one kind of standardization. So, and what I've also seen I'm, as I said, I'm working for AAL vendor before, and that was standardized. And I would rather work in an open source environment with OPPA. It's become much more successful than if we was standardized down the road. I have no idea right now to be honest, but I don't see any use for it right now.
So thank you all for this lovely conversation. Yeah. And discussion on Oprah. And I think you will be around on the, on the floor. So if there are any questions left.
Yeah. Last comment. You all have the question GE, where can I get this nice t-shirt yes. Come by the star. Both. And you will get a nice t-shirt
There. You have it. Thank you all.
