The year of authorization: lessons learned from Identiverse 2023

Originally published on IDPro.

For the first time ever, Identiverse headed to Vegas for its annual conference. It was a hit, as always, and judging by the agenda, some of the hot topics were passwordless authentication, AI, and last but definitely not least, authorization. My eyes were gleaming! We’re making authorization great again!

Much Ado about Authorization

I was delighted to see so much activity around authorization, both in the standards track, the vendor track, and the keynotes. On the floor, we had a slew of newer vendor booths tackling the authorization challenge, from Aserto to Indykite. All sources of inspiration. There was no shortage of authorization-related talks either:

As You Like It

One of the main challenges with ‘authorization’ is that it is an overloaded term and many struggle to define its boundaries and key attributes. Gartner called it externalized authorization managers; Kuppinger Cole established Dynamic Authorization. To avoid any confusion, I’ll go with the industry-wide NIST-approved term of ABAC (attribute-based access control) although I will concede the term focuses on one aspect only of authorization. Beyond the what, it’s fair to say there are 3 main approaches percolating to the top:

  • The ‘traditional’, policy-driven approach: this is the one advocated by OASIS XACML going all the way back to 2001. It’s also the very same pattern taken by Open Policy Agent and its language, Rego, as well as AWS’s Verified Permissions and Cedar, and last but not least Axiomatics’ ALFA.
  • The graph-based approach: this is the route taken by NIST’s very own NGAC and startups such as 3Edges and Indykite. The graph becomes the policy and the relationships become the conditions.
  • The entitlements-based approach: this is the route taken by followers of Google’s Zanzibar such as Authzed and Auth0’s OpenFGA.

No matter the approach, these models all share the following in common:

  1. They use attributes (of the user, the resource, the context) to drive authorization
  2. They decouple authorization logic from the application/API/service
  3. They allow for reuse and centralization

In addition to these approaches, there is a new standard out there, IDQL, that focuses on the overall governance of authorization. It will be interesting to see how IDQL enables OPA, ALFA, and others.

To Centralize or not to Centralize…

As far as I can remember, authorization vendors and standards have always touted the ability to centralize authorization. But what does centralization mean exactly and what’s in it for the customer? Referring back to the ABAC architecture, we can centralize:

  • Decision making: one central logical policy decision point
  • Enforcement: one global enforcement layer (think web application firewall)
  • Policy authoring: one PAP or policy administration point for the entire enterprise

The reality is a bit more subtle. Firstly, decision-making (the PDP) doesn’t need to be centralized. It could contain a subset of policies, it could be tailored to a specific application, and it could be deployed as a sidecar to the target app or even embedded. Enforcement can happen in multiple places simultaneously. The emergence of CAEP and shared signals is also opening a new avenue for proactive, just-in-time decision-making and enforcement. I, for one, would love to see more interoperability between authorization and these other standards.

Lastly, policy authoring will only scale in the enterprise if we all chip in. Granted, there will be enterprise-wide, potentially compliance-driven, policies that are authored by an IAM team. However most of the policies will be authored by application owners. Rather than providing a centralized authorization solution, we must provide a centralized authorization framework, a set of tooling app developers can subscribe to and utilize to implement their own authorization at their own pace.

… That is the Question

Forget the old mantra “ask for forgiveness, not permission”, it’s “ask for my permission, not forgiveness”.

The Policy Decision Point

The question! Authorization is all about asking. Forget the old mantra “ask for forgiveness, not permission”. Authorization is all about making sure you’re allowed to do what you’re about to do. A few of us, under the helm of my friend and former colleague, Gerry Gebel, got together in what I now call the “Wednesday meeting”. No, the Addams family wasn’t there. We collectively decided to drive a fresh standardization initiative around authorization starting with (a) a standard request/response scheme and (b) policy distribution. With regards to the request/response scheme, it’s all about making sure we’re asking the right question the same way. And when it comes to authorization, there are essentially two types of questions:

  • The direct “binary” approach: can Alice view document #123? This is extremely well-defined in XACML, ALFA, Cedar, and OPA. But all have their subtle differences. It’s time we standardized them all. My peer at SGNL, Atul Tulshibagwale, suggested we should take this initiative and go to COTS/SaaS vendors to encourage them to adopt those interfaces much like they’ve adopted SAML and OAuth/OpenID Connect for authentication.
  • The indirect, open-ended approach: OPA calls it partial evaluation. Axiomatics refers to reverse queries. It boils down to asking open questions such as “What can Alice do?”. The question can be broad (what can happen?) or specific “What can Alice do to document 123 on a Wednesday afternoon from conference room Juniper 1?” Again, it’s time we standardized this interface to promote interoperability and reuse.

If you want to jump on the authorization bandwagon (queue: DALL-E please generate a picture of XACML, ALFA, Cedar, ReBAC, and OPA riding on a wagon), feel free to join us at the policy charter group under the umbrella of the OpenID Foundation.

The Tempest

I would be remiss if I didn’t mention the storm that’s brewing outside. That’s of course AI. A lot of the conversations at Identiverse were around the impact of AI on IAM and in particular on trust (see Andre Durand’s stellar opening keynote for a chilling example).

With regards to authorization, Alex Simons from Microsoft delivered a compelling presentation on Open Standards for the Intelligent Trust Fabric. His closing point, “Authorization Policy”, highlighted the fact ABAC is here to stay and that there are enough policy standards (Rego, ALFA, and Cedar) not to create another. He linked AI with Authorization, suggesting AI could play the role of glue or epoxy tying/translating languages between one another. Perhaps AI could also help mine existing configurations to identify policies that should be defined and enforced. Perhaps AI could help translate from plain old English requirements into the language of your choice.


On the last day, authorization was once again the highlight in the closing panel where Andi Hindle, our host, Allan Foster, the chair of the Policy Charter, Galina Livit, Identity and Access Management Tech specialist at Ford Motor Company, and I exchanged views on the importance of ABAC and what to expect in the next 12 months. I even had the opportunity to murmur both SAML and XACML much to Allan’s awe/dismay. I’ll let the reader be the judge. The recording is now available here.

I firmly believe there’s a bright future for authorization and many opportunities to grow the field – not just through the different approaches but also through interop with other standards such as CAEP as previously mentioned, but also OAuth, Rich Authorization Requests, and OpenID Connect. It’s safe to say I’m authorized to say the future’s bright. My soul is lost forever to authorization!