Modern Authorization Architectures & AuthZEN

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts.

This is, again, and I say this often, I know this is a special episode because we have an external guest. We want to talk about modern authorization schemes. We want to talk about modern authorization and its standardization. We want to talk about AuthZEN. And for this, I have invited two guests. On the one hand, I have David Brossard. He is a main contributor to the AuthZEN working group. And I have Phillip Messerschmidt. He's also a contributor and an attendee at the working group. And he's a lead analyst at KuppingerCole. Before we go ahead, first of all, welcome, David. Thanks.

Happy to be here. Happy Friday. Happy Friday. So people know already when this has been recorded, but they can see this from our casual look anyways. And welcome, Phillip. Good to have you back.

Hey, all. Hi, Matthias. Nice that I can be here. Right. So this is, again, an international call.

So, David, you're hailing from Stockholm, if I remember correctly. That is correct. Phillip is hailing from the middle of Germany, and I'm from the southwest of Germany. But we make this work, so we are international and long-distance. I don't ask for the weather in Stockholm. I don't ask for the weather at Phillip, because it's raining here and it's really ugly. So let's talk about more interesting things. We want to talk about authorization. And before you just say, oh, authorization is boring, and you leave this or you stop this, you will be interested in what we end up with.

And it's an outlook of how authorization can really improve in the future. We're not replacing everything, but maybe we can make things better. But to understand what better means, let's start with the history. Authorization historically, that was RBAC, that was roles, that was business roles, that was corporate roles. And funnily enough, it's still relevant. RBAC is still around, but it's changing. I don't know whom to start with. Maybe Phillip, your perspective, if we look at authorization today and the history of that, why is RBAC still relevant and why does it need to be still relevant?

So we see that everywhere, basically in every organization. And I think the relevant part of RBAC is what roles do and what roles are designed to do. So the granular access, I think that is the most important part. The challenge that RBAC has and had in the past was the scalability. So providing the access to the people. And RBAC is per definition, a special use case of attribute-based access control. So when we think about business roles that are provided based on your profile, on your job title, this is a special case where people tried to scale roles. So you asked for what is changing.

I think roles and roles itself, the granular access, that is not changing. So this is what is still relevant, which is what is still important. But what is changing right now is the scalability part. So how people get that access, how we scale it, how we use context information to make that more scalable. And this is where RBAC is changing from the classic definition of business roles into roles only focusing on the object itself. So the access and the granular access rather than on the distribution.

And the distribution part, this is where ABAC and PBAC kicks in and what we want to focus on today. Any contradictions, David?

No, no, I agree. I would go even way back in history. I would say it didn't start with RBAC, of course. You know this, right? RBAC was formalized in the 90s. But before that, we had access control lists. We had homegrown ways of tackling authorization. We had group-based access even before RBAC was a formalized concept. But definitely, RBAC was actually created to be a bit more scalable and manageable than access control lists. But in turn, like Philip is pointing out, RBAC doesn't scale to the new world of IT. And what's the difference between, say, the 1990s and today?

And even between five years ago and today, is that the amount of services, the number of services, the amount of data, the number of users, the different types of users. 10 years ago, consumer identity wasn't really a thing.

Today, consumer identity is very much a thing. So it's just, there's so much more of everything. And there's so much more digital transformation, meaning there's many more use cases for authorization, both internal to a company and external to a company, that we need a better way than just roles. But I want to go back also to something, Matthias, that you said. RBAC is not disappearing. We need roles. They're a very sound and healthy foundation for authorization. We do need to put people in buckets, right?

I always mention a banking example, right, where you have a branch manager and you also have, you know, a statewide manager and you have a teller and you have a janitor and you have a customer representative and a wealth management officer and like these many different those, those are not going to disappear, right? But maybe you want to have an authorization policy that says that a customer representative can only view data in the state that they're assigned to, right? So now we're talking about relationships and authorization. That's something that roles don't typically address all that well.

And to go to an example that Philip mentioned, maybe you want to say that a customer representative as a role can only view data between 9 a.m. and 5 p.m., the branch times. Now that's environmental data or contextual data that, again, roles cannot express all that well. So we need to build on top of the foundation that roles have given us and make them better. We're definitely not ripping them away. We're not getting rid of them. They're very good. A lot of governance processes have been built on top of roles and we need to keep those. Right. And you mentioned already parts thereof.

But one point that you mentioned both earlier was scalability and just adopting to the size. And why is ABAC and policy-based access actually providing some improvement and adding to the benefits of roles? Where is the additional benefit from PBAC and ABAC? Maybe continue with you, David. Sure.

I mean, it's the fact that if you wanted to express everything as roles, you have to start doing this exercise called role engineering. And when you do role engineering, you end up with role explosion, typically, where you might have an organization with a thousand or ten thousand employees and it's not uncommon to realize you have ten times as many roles. And then add to that the fact that typically, historically, and this will be a very nice tie other than later, historically, authorization has been tackled as silos.

What that means is that you as a company, if you buy an SAP system, you get the roles from the SAP system. If you buy an Oracle database, you're going to get the roles from the Oracle database. If you buy a CRM, a Salesforce, you get the roles from Salesforce.

So now, Philip, who happens to be a manufacturing manager at a car company, switching from banking now suddenly, just to not be consistent, he ends up having at least three different roles because there's the manager underscore SAP, the manager underscore Salesforce, and the manager underscore Oracle database. From a business standpoint, they should be the same role.

But because you have authorization in silos with role-based access control and with let's call it embedded authorization as opposed to externalized, and we'll get to that later, I'm assuming, then you have that role explosion and you also have lack of understanding and visibility around are these three roles the same thing, really? And then Philip's manager has to whether he does really need access to SAP and whatever does Philip do inside of SAP? Should he? Or I don't remember, I'll just let him have the role anyway.

This is the issue, right, with just purely speaking role-based access control. Using ABAC and using PBAC, so attributes on the one hand and policy on the other, helps bring better visibility to the authorization challenge, express authorization in plain old English.

And again, we'll get to that later. I'm assuming externalized authorization from those authorization silos does not depend on the applications themselves. Philip? Now that you've obviously changed position, what does that mean for the three roles that you have in these different systems? How does policy-based and attribute-based access management actually change the way you are assigned with access?

I mean, this example, I think that's not even the critical case. This is three roles and this is okay for me. When I think about more dynamic applications, think about Teams, adding in your Teams room. This Teams room is divided into 20 sub-folders and you try to manage access for all these sub-folders. This is where the role explosion really hits hard. I can assure you, the usual organization will quickly lose control of something like Teams, like SharePoint and so on, if they don't use policies or rules to a certain degree.

We learned that with data classification and you put in internal, external and secret as classification marks and then mark that as the secret is only accessible by internals or something. Because otherwise, you would have thousands of roles for Teams, just for Teams.

Sure, David, your example is also okay, but Teams and more dynamic applications, I mean, you were talking about the sales manager before that should have access to a certain degree or to a certain area and data in a certain area only. This is really the dynamic application that becomes unmanageable with the classic RBAC approach. This is where we can use ABAC and PBAC to make it easier for everyone to control it.

Because as long as you can describe, hey, this person should have access to a certain data because he is in a certain area or because he is working in a certain time zone or in his working hours or whatever you can describe based on an attribute basis. That's good. That's fine. And this is how ABAC and PBAC can support us. But there are challenges around. Yeah. And it's funny, Philip, sorry, Matthias, before you jump back in, the way you described it, you're kind of hinting at actually two types of policies. I went straight for runtime authorization and externalize.

And I'm thinking about Zen in the distance. But you actually hinted at there can be provisioning policies and there can be runtime access control policies. The provisioning policy is still good, right? It's just a way to simplify. You're still doing RBAC, but you're acknowledging the fact that you have to have a policy that describes how to automatically assign the right roles. And it could be artificial roles to the right people in a join and move or leave a process. And the whole category of governance products, the sell points of this world, they've addressed this really well.

And there's still newer products in the governance category that still try to make this even better. Now, the runtime access control policies is what, of course, we at Zen believe is the future.

But again, they're not contradicting. I think we're going to have to have a mix of both. Right. But we all can agree that authorization changes from this more or less from the static model that we described earlier. You've mentioned provisioning. Yes. But nobody wants to provide these millions of roles to the systems. It would work. That would be a mechanism that could work if the systems were as performant enough to do this. But this is a different problem.

But we are really changing the way authorization is done based on attributes, based on context data, based on signals that are coming from somewhere. How does that change decision making at runtime? How does this actually happen? Is it moving away? Where does the application do it? Where does it happen? Yeah. So first of all, just to add to what you were saying, we need to make the decision making more contextual. Why?

Well, because there's the business need, of course, but also because there's actually legislation. There's no shortage of legislation, either national legislation, European level, international legislation, that dictate what should or should not happen. It could be things like a customer representative should not be looking at data of a customer that happens to be a family member. Or it could be that we all have sensitive individuals, it could be a member of government, they need to be treated separately from a regular customer. So there's a lot of contextual information.

It could also be in the geopolitical context, we should deny access from certain states, certain regions, because we don't want to do But the biggest difference is now we're going to do authorization instead of doing it at what I call it admin time is when you have the role and you have your birthrights. And so you log in, so it's session time, I guess you could say, you log in, your roles give you a certain set of entitlements, and then you're good to go, you're good to do whatever you want to do within the app.

Instead, you're going to do runtime continuous enforcement. This is what ABAC and PBAC, the architecture, they preach, right? You have the concept of a PEP disenforcement layer, a policy enforcement point, calling out to PDP, a policy decision point. And although it's called a policy decision point, of course, it doesn't have to be technically a policy. From an abstract standpoint, it could be a policy, but you know, saying hi to my friend Alex, who loves graphs so much, it could be a graph, not just a policy. I know you know who I mean, right? But so this is going to be runtime authorization.

It is actually, if you look at Zero Trust, if you look at NIST 800-207, but also DoD material on Zero Trust, this is what they recommend, right? It's one of the tenets of Zero Trust is runtime continuous enforcement.

Now, not all apps are built with this in mind. A homegrown app that you control, sure, you can retrofit or build with that in mind.

APIs, they're built with that in mind. AI and MCP in particular, they're built with that in mind. It's a really good fit. But COTS and SAS, they're not necessarily built with that runtime model in mind. So how do you go back and retrofit a Salesforce that has been in existence for the past 20 years, you know, 25 years nearly now? How do you make that compatible with the runtime authorization model is the next big Right. And as you hinted at, we are really moving authorization closer to the application, maybe even into the application, which is not the best choice.

So because then you have to do it over and over again. So you have, I think, co-locate something that understands all types of applications and speaks with them. So does this lead to the need for standardization, Philip? I think so.

I mean, we have seen that in the past, and this is more retrospective perspective when we check the last 20 years and think about the static access. So going a little bit back into history and the IGA tools out there, how much effort is it to implement all these interfaces to applications for externalizing the access decisions? And when we think about the step now that we do away from static access, from roles, from provisioning rules towards a modern, more dynamic approach, real-time access.

I mean, imagine what would happen if we do that now again in each and every application. And in 10 years, we say, oh, that becomes unmanageable when we have that decentralized in the silos.

Hey, I have an idea. And that's completely new. We create a central point for policies.

Well, we see that scenario coming. We have hopefully learned from it. We have learned from the IGAs out there from the static access. And now we can do that better. And I think that's we are heading right now. We are moving towards a new era, the dynamic access. We are partially moving away from the static access, but I think we will need some time to do that because there's that much stuff out there, so many application systems and so on that still rely on this way of access.

And that's why we cannot get rid completely of roles, of static access, of provisioning policies and move everything to zero trust ready, real-time access and authorization. But what we can do is definitely learn from the mistakes of the past to say, hey, now we start in a central way. We don't move everything to the applications. We don't move everything to the we can do it better this time. And this is what we are trying to do here. And this is what David also already hinted at. So the elephant in the room, you've mentioned it twice. It's not me. It's not Philip. It's not David. It's Ofsen.

So what is Ofsen concretely? What actually does it mean? How is it organized? And how can we experience it in the real life? Before we go there, Matthias, I just want to add on to what Philip, what you said. It's really interesting because historically, we've pitted authorization as a security thing. We've sold customers on buying authorization because if you don't, you're in trouble. You're going to be breached or you're going to be whatever. But actually, authorization is also a business opportunity.

If you, going to Philip's example, if you build a set of apps and then you rebuild them 10 years from now, if you are, let's just say, a banking company, let's just stick to my banking example from earlier. Define your information model. You have accounts, credit cards, wealth funds, whatever it may be. And then you could actually start defining authorization policies on top of that. And you could build apps, lightweight apps that expose the data to people. And as your use cases evolve, you can actually change the policy.

So it may very well be that 10 years ago, only the owner of the account could view the account. But now it might actually be that you want to do some form of delegation.

Maybe, Philip, you have a child who's in age of having a bank account and you want to be able to control their accounts so they don't spend too much money on candy. Well, with the policies of 10 years ago, that was impossible. But now you can change the policy to let your kids spend 10 euros a month on candy. So it's a business opportunity and it's all about digital transformation. So it's a positive thing. It's not just a fear thing. It's not just a security thing. And Matthias, now we can talk about OpenID of Zen.

Finally, we've made it a long way. Yeah.

So yeah, OpenID of Zen, we got together in the summer, I think, of 2023 in Vegas, which is probably why I don't remember that it was in the summer of 2023. And we all agreed, more or less, that authentication had sort of been solved. I'm sure that my authentication friends are laughing right now. But to a large degree, user management, at least in the workforce and authentication has been solved.

Today, if you as a company, you're going to go buy a COTS or a SAS, one of the very first things you'll have as a requirement is must be able to plug into my federation product over SAML, or maybe even not mention SAML, just mention straight up OpenID Connect, right? And OAuth 2.1. And so there is no way in this world that you would ever buy a product that does not support this externalized authentication protocol.

Well, we think we should be able to do the exact same thing with authorization, that tomorrow, if you buy an off-the-shelf product or a SAS, or if you build your own product, you should be able to say, I need to be able to delegate the decision-making to an external central policy management tool, the way you put it, Philip. It's very much about central policy management. It's not about central decision-making. The decision-making can happen wherever.

What really matters is the management, the governance, the lifecycle of the authorization policy, and then focuses on the ability to plug the COTS and the SAS and the frameworks and so on and so forth with a PDP of your choice over a standard protocol that allows you to send authorization requests and get responses back. We're moving away from the unique selling proposition of individual vendors. We are moving towards standardization and towards a common language, a common understanding of what authorization actually means.

And if I think back, the establishment of reliable authentication mechanisms, that was a tough ride. Doing this for authorization sounds to me like a challenge to solve and to get the right people on board to drive this, right? The way we did it is that we, in our Zen, we clearly said we do not want to be in the business of defining or standardizing how PDP works. So whether you use graphs or ACLs or ZACWL or Alpha or CERBOS or Cedar or OSO or Rego, that is up to the PDP. And it's to a large degree, whatever the customer wants to use or prefers.

But what we want to standardize is how you ask a question and how you get an answer back. Hopefully you don't get a question from a question. What is 42? I don't know. What is 42? In our Zen 1.0, which came out in January, we defined three authorization APIs. One is a binary authorization API. What can Matthias, I'm sorry, can Matthias view record one, two, three? One is a batch authorization API. Can Matthias view item one, two, three and item one, two, four? And then you get two decisions back.

And then the third one is the open-ended search API, which is, oh, tell me which items Matthias can view. And of course, in the search API, you can focus on the user, you can focus on the resource. So instead of asking, tell me which records or which documents Matthias can view, you could have said, this is document one, two, three, who can view document one, two, three? And the answer might be Matthias, Philipp and David. Anything to add from your side, Philipp, first of all?

No, we are deep in the specifications. Yeah, okay. Then a question from my side. We have reliable, abstract, opaque policy definitions that are valid for many types of transport mechanism, as you described them. And you don't say anything where the authorization actually takes place. Then the banking department comes around or your banking example comes around and says, okay, there's somebody, something doing an access decision somewhere. How is this documented? How is this audited?

How can I, as a bank, reliably document that this component, based on this policy, made this access decision? Is this in scope of what you do as well?

So, sort of. I would say it's in scope right now, at least as a side effect. I believe we talked about it for the future of Zen as well, at least writing maybe a profile for SIEM tooling, to be more specific.

And so, when I say it's in scope as a side effect, what I mean is that because you've now externalized authorization to an external PDP, and it doesn't matter what language the PDP speaks from policy, graph, whatever, you still get that same Zen request that you send, and you still get that same Zen response that you get back, right? So, that can be sent to your SIEM tool, your Splunk, your Elastic, whatever, and that can be used for log analysis.

So, your banking compliance manager, they can now go to the SIEM and they can see that Alice accessed their bank account three times in the last 10 minutes, that sort of information, because it's in audit logs, right? And if you wanted to go beyond that, if you wanted to do deeper forensics, if you wanted to ask things like, well, hang on a minute, so Alice got access to her account at 3 a.m.

from, I don't know, Switzerland. Why? Then now you have to look at the specifics of how the PDP has been configured. Most PDP implementations, open source of vendors out there, they provide tooling around their policy language, their graph, to be able to actually find that information. This is such an improvement over baked-in authorization.

I had a meeting with Wealth Management Bank, I don't know, 10, 15 years ago now in New York City, and they were doing some degree of externalized authorization, except that the authorization was still baked into a developer framework and it was written in Python. And so, I asked, well, when the compliance manager comes along and wants to verify that the right authorizations are being put in place, I think it was around trading the use case and being able to trade stuff you're allowed to trade up to the just give the compliance team the Python code.

To which I replied, well, do they understand Python? No, but we don't care. We just did our job. We provided them with the algorithm and the implementation of the algorithm. Our job's done.

And so, this is kind of a CYA-type compliance check, where you provided the mechanism, whether anyone understands it is irrelevant. You just did your part.

Now, with properly externalized authorization, generally, if we look at the frameworks that have implemented all the Xen, I want to say, Philip, keep me honest, but 80% are policy-based and 20% are graph-based or tuple-based. We all have some mechanism that, yes, is specific to how the PDPs have been implemented, but we have some mechanism to provide the visibility to the compliance manager as to why a decision was produced. Right.

And you went very briefly and very quickly over this, but just briefly a few weeks ago, you announced the version 1.0 as a proper standard, which is available and which can be used and implemented and is handed over to the public, to the vendors, to the users. First of all, this is a huge success to have this out and up and running. First of all, congratulations. And the question is, A, how do you continue pushing that into the ears and minds of those who make decisions? And maybe more importantly, we're getting already close to the end of this episode.

I would love to stay for one more hour or so, but it's Friday, as you've real-life IAM architects expect for the future. So first of all, how do you push it? How do we drive it? We are talking about that to drive it. That's why we're here. And one other goal is in the back of my mind, but I mentioned that later. And the second is what happens next? Yeah. So first of all, we've been extremely grateful to have a lot of support from you, the analyst community, both Kupringer Kohl and Gartner. You've been tremendous. We've been single AIC for the past three years.

You've given us room to actually do demos and workshops and working sessions. So thanks a lot. And also thanks to your competitor, Gartner, who've been playing along as well. This is tremendous because it is raising the awareness. That's the number one thing. And the people attending your events, your webinars, your conferences, they get to know Aubsen thanks to you. You're making it a reality. And of course, in the case of Aubsen, we've had directly involved in the working group, which is fantastic. That's one thing.

The second thing is, in 2026, we have quite a few things on the roadmap for Aubsen. We actually have a new set of co-chairs. We're now five co-chairs from a broad range of the industry, including non-authorization companies, which is great. You don't want to be just a one-sided chair. I do want to say thanks, by the way, to both Jerry and Omri, who were my co-chairs in the past. We've done a tremendous job of getting us to 1.0. Now for 2026, we're building profiles.

We're thinking about building a profile for MCP, and we're trying to get involved with the MCP working group, so model context protocol. There's a pretty good fit there, of course. One of our members actually built an integration with Apache 6, I think it's called, to provide Aubsen-based authorization in that product. By pure chance, yesterday I stumbled across a product called Mattermost, which is an open-source Slack-like competitor. They're thinking about doing Aubsen. It's popping up little by little, left and right.

For those architects and practitioners who want to follow best practices in terms of IAM, they need to tell their teams running RFPs to buy a CRM, to buy an ERP, to buy whatever, to now include Aubsen as a requirement, much like OpenID Connect is table stakes, really, for any product that you buy. Looking at Philipp, is this a requirement that we see as advisors already? Do people get the message that things are changing, that we're getting to externalized, dynamic decision-making, rather than the traditional roles?

We made the role fanatics happy at the beginning of this episode, but I want to have this more modern, more agile, more dynamic people also on board. Do we see that already, or is this not yet there?

I mean, you definitely need to extend your tooling in terms of you need to be able to do ABAC, to do real-time in the future. What I can recommend and what customers are already asking for is this piece, this real-time piece. They are even asking for us then, so the awareness is there, it's improving, and then this is our job to improve it, also bring it to their tables. What I can recommend for those people, for CISOs, for architects, ask your vendors if they have it, because we are trying to establish that as a standard.

If you want to help us, support us, then ask for it actively, because I believe, and I think a lot of other people agree with me, that you will need it in the future. If you want to build a future landscape, auth then will be a part of it.

Right, and if you look at this bigger picture that we always mention when it makes sense, the identity fabric, I think having an authorization component that speaks of SEM on one end and is able to communicate via API, via anything, with an existing or a new IGA solution, a new way of providing policies, policy orchestration, I think that is where things make actually sense, so you don't have to rip and replace your full IGA solution just to have auth SEM, just add it as an augmentation to what you already have, and these products are around, right, David?

Yeah, absolutely, and it's one of the, we've been running interop scenarios over the course of the past, you know, 18 months or 20 months. One of them that we did, I think six months ago, was around, I'm sorry, IDP integration, meaning having an Okta or a Ping or a Microsoft Antra or a Glue call out to a policy decision point using auth SEM. What's in it for them?

Well, they don't have to rewrite the integration if they want to switch from one vendor to another vendor or one open source framework to another open source framework. It's auth SEM, and it's plug and play, and it works. In that case, what was interesting was that why would you want to integrate with an IDP? What if the app you're dealing with is, let's call it a legacy app that has not been retrofitted to be able to use auth SEM?

Well, you could actually use a token issued by the IDP to carry some information, so what happens is the IDP talks to the auth SEM enabled PDP, and using the search API in this particular example, the PDP returns a list of claims, dynamically generated claims or claims that doesn't matter. It kind of depends on how the PDP was built or configured, but it's through auth SEM, so it's standardized. Those claims get injected into the identity token or the access token that your Okta, your Ping is creating, and then that is passed through the application.

So that's one way to actually get apps to move towards finer grained authorization without necessarily first having to deal with auth SEM at all because it happens through the IDP. And then I see that on the far left of the IAM landscape, the user management identity side, and then on the far right is where you have the governance tooling, where you can also have the governance and the JML provisioning processes leveraged on Zen, either to decide whether to issue individuals entitlements or maybe it's for policy provisioning, as you mentioned, Matthias, there's a lot of use cases there as well.

But yes, definitely using a standard is simplifying the integration. And it's definitely speaking to the identity fabric that I think Martin showed that as one of his last slides at the closing keynote. It was 2025 or 2024. And definitely all the Zen is helping in that fabric. And we will talk about the fabric, of course, as well at EIC. And this is the other thing that I had in the back of my mind. So what are the milestones that we expect in the next month? You told us about the auth SEM milestones, and there will be a lot.

And I'm really hyped to see a standardized, decentralized authorization scheme actually now out there and ready to test and use it. And this is really what I'm looking forward to. And you will present and auth SEM will present that at EIC again.

EIC, this is the road to EIC podcast episode. It's somewhere hidden. There should be an icon or something like that, that we are really getting closer to EIC. And we will give you the opportunity also to showcase and to demonstrate and to really tell people about it, that it's finally there. And I think that that is an important part.

Of course, we are looking forward to EIC anyways, identity fabric workshop will be there. But having the message out that auth SEM is ready for showtime. I think that is really one of the most important messages. So may Berlin Alexanderplatz be there. That was the commercial break. But before we close down, any final words, first, David, that you want to share looking at auth SEM, at the changes at EIC, at whatever you want to mention for the really closer future and maybe what CISOs, what architects should prepare for?

First of all, I want to say that auth SEM is obviously a live working group. We're always looking for new members. We're maybe a dozen right now working on the future of auth SEM. Heavily biased on the side of authorization vendors and identity vendors, but we welcome people from a broader range of the industry.

The more, the merrier. We meet weekly on Thursdays. I think it's 9pm European time, noon Pacific. To be a member, you have to be a member of the Open Society Foundation. As an individual, I think it's only $50 a year to be a member. So it's very easy to get involved. There's a lot of ways you can actually help out. Then you're asking, between now and EIC in May, at the end of May, we're going to work on an MCP profile. We're going to work on something called partial evaluation. We're going to work on A to A authorization as well, agent to agent authorization.

I know that we also want to look at something called obligations and advice, which are a way to convey additional information in addition to a decision. So, you know, X is denied, Y is X is denied, providing some of that information back. I'm working on, you're going to laugh, it's going to date me. I'm working on a ZACWOL to AuthZen mapping to make ZACWOL-based products compatible. Could be worse. No judgment. No judgment, please.

You know, there's a lot of cool things. And please, please, you know, if you're, if you're an architect, if you're an IAM practitioner in your industry, one of the industry-specific profiles, what does it mean to use AuthZen in the medical world, in the banking world, in the manufacturing world? Do we want to work with open banking?

You know, that would make a lot of sense. Do we want to work with HL7 in the healthcare industry? These are the other things that we want to tackle, right? The business vertical side of things.

Sorry, that was probably more than you asked for. Yeah, it's a lot of work coming up.

So, you need partners in crime, I think. Your final words, Philipp, before we close down, EIC, AuthZen, MEI, Berlin, what are your thoughts? My thoughts.

So, I think the authorization space is very interesting at the time, at the moment. So, there is a lot of stuff changing and the strategic advisor in my body is saying it is a completely insane topic because we are shifting from static, from admin time, to a dynamic world, a real-time authorization world. And AuthZen is actively supporting that.

So, it's in the middle of this trend and enabling the organizations, making it much easier to do that shift, which is important when we think about CISOs, IAM architects, enterprise architects. They will have to heavily rely on AuthZen and the idea that AuthZen is pushing to make that move towards zero trust, to real-time authorizations. And that is interesting. It's exciting. And we managed to get through this podcast without, okay, we said MCP, but we did not say NIHI, as far as I remember.

So, and how this plays well together, that is a completely separate topic because this will be, in my opinion, the key enabler of making control and access management, especially for agentic AI, actually possible because you have the decisions where they need to be. You brought up NIHI, Matthias. I've got to build on this in the last couple of seconds we have. I think NIHI is going to be a much bigger identity problem, not so much an authorization problem. It creates different kinds of authorization challenges that AuthZen is well-suited to address because it's relatively agnostic, right?

So, you're going to have access delegation questions, consent management questions, but they don't really deal with the actual runtime authorization. So, AuthZen can already address those. But definitely figuring out the identity piece is going to be, and conveying, you know, both who the agent is and who the agent is acting on behalf of and using that as input into a decision-making process. AuthZen is already, it's just waiting for the identity folks to catch up. Right.

From really the trust anchor to intent and to really put this and bake this into the identity and then allow for the proper authorization, that will be a really important part. There will be good reasons to have an EIC also in 2027, I'm quite sure. But first of all, we are looking at 2026 and the EIC there. We are looking at a finalized standard 1.0 with three protocols that represent AuthZen and its first incarnation in real life. Thank you very much, David, for being with us today. That was really great.

Thank you, Philipp, for being with me here today as well. So, that was a great conversation. I'm really looking forward to seeing more of AuthZen in Berlin and beyond. And up until then, we will have more episodes on this podcast around the road to EIC. If you have any questions for David, for Philipp, for myself, if you have suggestions what to cover in this road to EIC podcast, leave a comment on YouTube in the comment section and please let us know.

And I think all of us are ready and available for answering questions when it comes to the nitty-gritty details that we could not cover in a 40-minute podcast episode. Thanks again, David. Thanks again, Philipp. See you in Berlin. See you in Berlin. Thank you. See you in Berlin.