Okay, everyone. Thank you. So now we have our panel and I'm gonna hand this over to, into the Cape, hands of Eve, and you'll be in charge of keeping these people in order and making them answer all the questions. Okay. Right.
Take it away.
Sounds good. Thank you so much, Paul. Yeah. I'm sort of stepping into a herd, these particular cats and I, I feel like Alex and David, you should stand up for a second. They're illustrating, permit and deny in local fashion.
Woo.
So, so I'm Eve Mailer, I'm founder of Consultancy Event Factory and I'm a member of the Zen Working Group. And we'll be focusing quite a bit on that today and I'll just invite each one of you to introduce yourselves.
Alright.
Hi, I'm Gert Draper, founder of a certo part of the Zen community as well before that active directory, Azure AD and some other startups. But yeah, that's it.
Hi Alex Banu. I sit at three edges, generally the graph guy in the room.
Hi, I am David CT at Somatic. Generally the, the policy guy in the room and part of Axiomatic had the pleasure to work for Ian at Salesforce.
Oh yeah, that happened. Yeah. Yeah.
Let's try this one.
Let's see.
Alright, in this context, I'm still Ian Glaser. However, the reason why I'm here is long time authorization list. Went to the first autism board meeting, which actually qualified me for a panel. I have no idea. An Open ID foundation board member.
So he basically wandered off the street and, you know, found his people.
Well, I'm glad you're all here today. You know, you've just heard another talk about, you know, some of the benefits of externalizing authorization and, and servos is also at the A table. And so all, all of us except Ian, have been working together to, to kind of bring a modern sensibility to auth authorization and bring some of the, the recent insights to light. And so I kind of wanna ask you all, why are we talking about modern authorization now?
Like, you know, we have some older artifacts from 20 something years ago that had some of the same patterns. So what's changed? What's new?
I, for me, from my perspective, one of the things is, and I just do have to comment, I do have minions and spies in the off end working here, but just not there myself. Moles. Moles. I think the thing is different now is that the surfaces over which we need to exert control have expanded greatly and the controls available to us have expanded greatly. And both of those things are happening feeling like geometric progression, right? And so now more than ever getting our arms around the mess we need to actually express policy around has gotten more difficult.
And so I think we've hit a sort of wall that says classical tooling for things like our back and identity governance administration don't work at these kinds of scales or with this kind of nuance, right? I wanna understand context, I wanna understand the environmental state. And so these things are all seemingly happening at the same time. And it's sort of created this condition under which it's almost an inevitability, right? We have to do something different.
And that's why we're seeing this renewed in interest, I think,
Yeah, to, to sum it up, more data, more users, more services, more expectation, more regulation. You've gotta handle authorization. You can't put it off anymore. Plus the fact that we've been dealing with authentication for the past, you know, 10 plus years and we're finally getting to a point of maturity, hopefully that is gonna free up some time for people to focus on authorization.
Yeah. And also the use cases are so varied that I don't think, well, I mean, we don't think there'll be one a one size fits all for authorization.
And so we needed a way for all these systems to communicate with each other. And I think that's where odds and comes into play.
Well, we'll try to work on a protocol on a set of recommendations for all these systems to communicate with each other, including existing apps or even one day off the shelf applications like Salesforce.
You can dream. I know we'll talk about that too. You
Can dream.
So I, to summarize it, it's like we're trying to achieve our open ID oas moment in authorization.
All
Right, so we can make this finally pluggable. So hopefully there is some transparency between implementations. Why is that important? Because as said before, it's like there are various use cases and there's no one size fits all. But hopefully from an application integration or service integration point of view that allows it to make more traction and solve more problems.
Okay, so that's a really interesting analogy. It's one that the, you know, the auth zen working group members, I think aspire to generally, it's interesting to me because authentication seems to have been readily, somewhat met, readily made into a shared service. Can you talk about the challenges in making authorization into a kind of a shared service? What are the, what are the barriers that we're having to overcome?
So I think one big difference is, as the previous presenter also pointed out, authorization is a data management problem, a distributed data management problem.
You need to have facts to make decisions. This makes it a high transactional distributed problem. That's different than providing a token based on some qualifications that you
Hold onto for a while.
Also, we all speak different languages around here, right? So yeah, Dutch, I mean I myself don't speak Canadian, my language, visual Canadian, these guys have languages, right? Alpha. So how are we gonna interoperate and exchange policies and decisions and things. So some use cases are very graph, some others are more policy. We should enable all of them, not just focus on one of them. So that's definitely a challenge.
So
You were saying that your thing is ancient Egypt and hieroglyphics,
We're talking about modern,
I think, yeah, to, to Kurt's point, sometimes I, I'll compare authorization to like a game of musical chairs and you're not fast enough and you landed in, in between two chairs. And it's very uncomfortable because on the one hand you have the, the identity centric stuff and the identity that can be owned by a central IM team. And it's quite clear and everyone agrees more or less on the schema of, of things in LDAP or S scheme or whatever. But the other chair is the application side, right?
The distributed data problem and and getting app owners to agree to what the model should be and writing policies or writing a graph, you know, configuration, doesn't matter what it is in a consistent way. And that's, that's the heartbeat.
Okay. And there's a couple couple things pointed out there where we've, you know, we've got, you know, higher mountains to climb, but we're climbing them. I think now a lot of people were inspired by Google Zanzibar paper and Google has seen benefits from, you know, a new kind of approach and there's some other kind of SaaS companies.
What are they, how is that affecting the landscape? You know, Zanzibar is just sort of on everybody's lips. I
I'll go first, I'll go first. Sure.
I think, I think it was an eye opener. Like so I'm from, come from the ABAC slash policy background.
So for, you know, between 20 10, 20 20 was like abac, abac, ABAC policy, Mac, Mac, Mac, Mac, Mac. And we kinda forgot DAC and the process. And fortunately Zabar came along and said, well hang on a minute. It's not all about policy and, and mandatory access control. It's also a discretionary access control and access control at scale. So that was an eye-opener and it's certainly changed how I look at authorization.
Yeah. Now Zanzibar is an interesting one in terms of graphs because they use two poles, which is actually a little strings made of three elements.
You know, node one relationship node two, this is strangely reminiscent of a standard that was written back in 1997 called, called RDF, which was meant to describe the worldwide web. Those were called triples back then. And there are triple stores that exist to this day that are defining graphs.
But what I'm talking about myself when I talk about graphs is labeled property graphs, which are quite different and much faster now in a triple store or a triple store like Zzi, bar based stores, if you wanna pass a relationship like say 10 hubs, you have to, you have to do 10 iOS, basically you have to find all these ten two, whereas in my world it's just one io I find a pattern and I match it. And graph databases are very good at that. So that's a very kind of a different thing. So other than that, Zanzibar is kind of logically semantically similar.
It's a graph and you look for a pass essentially. But yeah. But in the backend you're really manipulating two poles
I think from a bit of a meta observation perspective. So Zanzibar, now Cedar, others are starting to prove that the heterogeneity of the environments that we actually manage do require different kinds of approaches. And that some of the things that's really interesting to me is that we see all of this innovation happening in different kinds of parts of the problem space, right? It's not just about the dominance of Zac or lack thereof, right? It's not about singular patterns.
It's saying, Hey, there's a whole robust world around policy problems, governance, management, creation. There's a robust world about different kinds of substrates I wanna manage differently. So the fact that we see things like Zanzibar and Cedar and others and Cape and what have you, is evidence that says this isn't a homogeneous world and that the problem space won't lend itself to a single flavor. And that's actually really exciting.
So, so basically the generativity of this kind of current moment that we're in is exciting 'cause it's solving more, more of the problem space that that maybe was hidden in there.
Well, yes.
Right, because I think what you're pointing out, Zi Bar is a policy as data approach where there is Exec Mo, which started the policy as code approach. OPA is a policy as code approach. We started with OPA, our first observation was when we encountered a real customer is that we need data and you need to bring the data to the enforcement point. And that's how we started marrying both of these systems in AAC and the REBACK system.
And yes, it's very similar to graphs. I don't think that's wrong. Yeah. Right. And it's like, it's a slightly different approach, but it's like, what I found is that from a customer point of view, it's easier to mine their, their mental model from an RAC model to a Reback model. 'cause RAC is really a subset, but it's like it's managing it as data. But then they come to the intersection where it's like they say it's like I still need to make decisions on properties, either environmental or properties on an instance.
So I don't think at the end of the day, and as, as as in said is like there's so many applications and needs that is like, there's no one size fits all.
So spoiler auth Zen has initially at least defined A-P-D-D-P-P-E-P interface.
It's, it's, you know, fairly simple, fairly easy to get your head around. But we've got, we had how many? 14 different implementations?
12.
12, 14 total.
Let's two new
Ones. 12.
We had two after the session.
Oh,
No, no, no. It's the
12 companies did,
I did two. So a total of 14
Implementations.
Oh,
I only
Caught myself the once notice
That authorization is not arithmetic. I'll
Just point that out. Obviously everyone involved one. So obviously each one of those is going to have taken a different approach and provide different kind of pros and cons. So maybe from each of your perspectives, could you sort of describe, okay, you know, interoperability is about strategically commoditizing the thing that isn't providing differentiated value. So share with all of us, you know, what you build sort of on top of that or with, with that kind of standardized interface.
So the first focus is, as I said earlier, is like trying to create our OS two open. Id like moments for authorization, which means standardizing an API of how to make the effectively the decision call, right? I want to delegate you, you make a decision for me, you give me an answer. What is behind that? How the policy is implemented, if that's policy of code, if it's a graph from Alex or it's like any other way, it's like, doesn't really matter in that story, right?
It's, it creates, it unifies how an application talks to the enforcements, right? And that's the first step. Getting to the point where it's like there is homogeneous or U unified policy languages. I think that will be a far way out. And you heard it here first, it's like there's the IDQL is like, it's trying to do magic with regards to transformations and unifying things, but in a real time environment, I think that is not, it's like from a processing point of view, that is valuable, but not at a real time.
Go ahead.
Yeah, I, I totally agree. I like whatever policy language you use, just see the two sides of it. There's the management side and, and it could be policy or it could be gren. Then there's the fuel of the engine. Whatever fuel your engine uses, whether it's rego and open policy agent or Cedar as you, as you said Ian or, or Alpha or zl or, or maybe, you know, y in the case of SBOs, which ist quite an authorization standard but is good enough to configure their engine.
It doesn't really matter as long as you manage your policies in a way that gives you audit access, reviews, visibility, and trans transparency of that configuration. And
That's, that's a huge point, which is in the, we sh the danger we have in identity is often we are obsessed with the how. And so going back to when we were talking about identity relationship management, people got obsessed with the how of implementation and not the outcomes that it was going to lead to.
And so I think by getting a little bit, it's important from a protocol perspective to understand the how and different deployment models have different optimizations for different use cases. Having a clarity around the outcomes is the important point here. And then do we have appropriate coverage and context becomes the sort of next conversation, then we get to a how, but it's often, it's been certainly in this space, like going back to the Zac old days, we like, let's start with the implementation, like let's sharpen those angle brackets and then we get to the outcome.
So we gotta think about that slightly differently.
I want to focus on something that we all assume because we talk about the pep PEP pattern for, and that's what we're standardizing. Just curious in the room, who uses that pattern for authorization right now? Any show of hands? We have see two three. Three people.
4, 5 5
Who, who augments their token when at login time as a pattern? Any show event?
Okay, come on. Be honest.
Come on. Yeah.
Do you, do you guys want to, who has a code in hardcoded code in their apps for authorization? Anyone? Yeah. Okay.
That's the winner.
Who, who
Doesn't do authorization
At all? Yeah, who doesn't do author all your other people.
You need these T-shirts then clearly is there a ven of like
If you, if you haven't raised your hand, you should ask yourself some questions.
Wait, is it allow all that's
Not cool? Yeah, that's not cool. Don't like that.
Oh, so what we're talking about Pep PP is where we would like everybody to go to because you need to authorize every single request in line with zero trust in particular. And the pattern of authorizing at login time is probably not great because whatever your stuff you're token with with might expire anytime soon, which is where cab comes in. But that's kind of like a glue to a problem. So that's kind of interesting. And another work, so this work that we're also doing is define those, define those design patterns and trying to provide some recommendations around those patterns.
So,
So, so we're getting close to the end here and I wanna do a little bit of a lightning round. You know, Ian, you're saying, well don't, you know, over rotate on the how and it really kind of like what's the why?
And I, I'd kind of love to hear from those of you who have, who have implemented au what is kind of like your top benefit or use case that you're seeing out of, out of implementing it.
I think it will aid the move towards externalizing authorization, right? As we see based on the hands, it's the winner still, right? I think that needs to change, right? Nobody's building their own authentication system anymore. They're relying on standards of how to do this. That's where we need to get through. So externalize, manage your policy separately, use a standard API.
Nice.
Yeah, I think on my that and also maybe shift away from just using roles for everything, roles have their place, but maybe we gotta think about 21st century ideas,
Graph roles. Yeah.
Not roles, just graphs, relationships.
So to, to echo what you said and also what you said, Ian. I think two things. If I look at the, the history of authorization, you know, 10, 15 years ago when I was working in authorization, we did not talk to the competition. It was a very, I don't wanna say aggressive, but very cold environment. It wasn't fun. It was the ankle bracket. It was the ankle brackets, definitely.
I, I blame Eve. Good point. But like today, I mean one of the side effects of, of having done Zen is that we talk very openly between, you know, a Certo and Serbo and three edges and xxi and, and many, you know, the, the 12 vendors or the 12 frameworks. It's not all vendors by the way. So that's cool. And then to go back to, to Ian and, and the how and the what the other, like the call to action for us at Zen is to go to non authorization vendors and say, Hey guys, you should implement all Zen and also to go to non identity standards. Go to fire for instance in HL seven.
So healthcare standards or go to open banking and tell them, Hey guys, there's a path to authorization.
And then if you follow that path, I think one of the interesting outcomes is, and this may be just a spicy take on this, is you actually start to set yourself up to actually use generative AI and LLMs for good. Because you can now actually use 'em for translation processes in policy, which you couldn't really do when it was hard coded in the world. And I think there's promise there. I'm not guaranteeing any outcome.
You know, your mileage may vary, consult your lawyer before deploying policy, but it opens up a very interesting kind of world that says, can we have real innovation around policy? But we only get there by going down that path.
Very cool. So I learned that curly braces are friendlier than angle brackets.
One thing, one thing I think we need to share with the audiences, like okay, if they're interested to follow along with us then or join or contribute, how do they do that? Now David, you're one of the, the co-chairs. We have like 17 co-chairs. I dunno how many a lot,
But the graph guy isn't one of them. You should be jokes site.
Yeah, go to openid.net/wg/zen. That's A-U-T-H-Z-E-N or ZEN or there we go. If if you're, say what?
Yeah, so you can spell, if you can spell, if I can
Spell it. Use Z Yeah, yeah. Slash da da.
Thank you. Yep.
So one other plug. So on Friday morning yes. Nine to 11 we're having an interop event, right? Similar than the one that we actually did before.
It'll it'll be one week better than the one at. I be better. You wanna see it?
Demo still works,
Right?
We have time for maybe a question if there's something. Yeah.
Vlad,
A quick question. I know the biggest difference between authentication authorization is that nobody wants to own authentication, but application owners are really, really afraid that you take away their rights to say yes or no.
Okay. The application owner problem. Yeah.
As a human factor guy. Question to you, how you work with that. What
Is the Okay, I have an answer. Thank you. Appreciate it. I spent 10 years in consulting before this and I can tell you that develop my experience anyway, but developers hated doing security stuff.
They just wanted to do their stuff and security was the last thing that they wanted to actually have to work on. So I think they'll be quite happy myself, maybe I'm wrong.
So that's a new insight for me is like, just tell them it's icky security stuff and we're gonna just take care of it.
I mean, so,
So from the ownership point of view, yeah, I think they're actually very happy that they get insight of how permissions are assigned because this, the inverse is also becoming true is that it becomes discoverable, right? Based on the various mechanisms. One of the other things we have on the standards ballots is to be able to search from subjects to objects is like, who does everybody have access to?
Or every, how does this pass go the other way, right? The graph guys are in an advantage there of course, but the NC bar guys are not sitting on their hands.
So,
So, so you know, a thing that you're hearing now is that, you know, it's not just going to this standardized interface for a very simple thing. It's added functionality that they get kind of for free if we do our job right in the working group.
Yeah.
So we're, we're building three APIs, three authorization APIs. The first one is the one we did at the interop last week and, and this Friday, like T said. So it's very much a yes no question. Single yes, no question. The second one we're gonna do very quickly is a batch. Yes.
No, it's pretty much the same thing as the single one. And the third one is gonna be, the most interesting one is gonna be what, what signal and a tool called search, what I call reverse query. What some folks at at OPA call partial evaluation is being able to ask it what can happen or who can get access to Resource X or what can Alice do? Literally
You can make a policy out of what could possibly go wrong and it's great,
It's really powerful To who win, why, where, how, basically.
Yeah, that's much more powerful and it'll be, you know, interesting. And so if you have use cases for that, it's a perfect reason to get involved and contribute those. I'll wrap it up here. Thank you guys. Thank you to the moderators of the track. Thank you. Thank you.