In October 2023, the OpenID Foundation board chartered the AuthZEN working group to develop and promote interoperability standards for modern authorization.

At Aserto, we've been involved with AuthZEN since its inception, as a co-chair of the WG, editor of the spec, and author of the interop scenario and test suite.

We've been able to accomplish a great deal as a working group over the last year. This post reflects on all the progress, and describes the lessons we learned along the way.

Charter

Simply put, AuthZEN's focus is to establish externalized authorization as the dominant pattern for implementing access control in applications.

Terminology

Over the last 25 years, the authorization world has settled on terminology describing its various moving parts, commonly referred to as the "P*P architecture":

• Policy Enforcement Point (PEP) - typically the application or an intermediary which asks the PDP for a decision, and enforces its outcome.
• Policy Decision Point (PDP) - the externalized authorization engine which evaluates an authorization policy given a set of inputs, and renders an access decision.
• Policy Information Point (PIP) - provider of data that contributes to the authorization decision.
• Policy Administration Point (PAP) - management plane for creating and administering authorization policies.

Initial focus

We decided to focus on the PEP-PDP API as a first target for our work. There were a few reasons for this:

• There is immediate value for authorization consumers (PEPs) such as applications or API gateways, in that they can target a single protocol and interoperate with every PDP that implements that protocol.
• There is immediate value for authorization providers (PDPs), in that they don't have to invest in custom integrations with a wide variety of PEPs; any AuthZEN-enabled PEP is a possible "socket" that the PDP can cover.
• The protocol for communicating with each PDP isn't seen as a source of competitive differentiation, so the advantages of embracing AuthZEN outweigh any potential value erosion for the vendor.
• This seemed like "low-hanging fruit" - every PDP implementation we know about takes roughly the same inputs and produces the same outputs. We could get to a standard relatively quickly and "notch a win", facilitating continued interest in further work.

Once we're done with the PEP-PEP leg of the tetrahedron, we can focus on the data flow between authorization data sources (PIPs) and the PDP, and the flow of policies between administration points (PAPs) and the PDP.

Minimum Viable Spec

We made a deliberate decision to focus our initial deliverable on the smallest possible increment of value - specifying the request/response payloads for a single authorization request, answering the question "can this subject perform this action on this resource".

{
  "subject": {
  },
  "action": {
  },
  "resource": {
  }
}

Milestones

We've had a few major milestones in 2024.

Identiverse

The working group targeted Identiverse in May 2024 for its first interoperability event, which meant we needed to get a first draft of the PEP-PDP spec done a couple of months prior to the conference. We agreed on the general shape of the spec by March, and defined an interop scenario in the form of a simple Todo application.

Specs live or die by their interop scenario and validation suite, so the Aserto team decided to lead this effort and created both the application (front-end React app / back-end node.js app), as well as the test harness for validating whether a PDP is compliant.

To make it easy for PDPs to participate, we allowed vendors to either provide a proxy that implements the spec which can then translate requests into their native format, or implement a "native" AuthZEN endpoint.

We used Identiverse as a forcing function and tested a grand total of 12 interoperable implementations. Aserto provided three of these, including a hosted Aserto implementation, a version that targets the open-source Topaz engine, and one that uses "plain-old" OPA.

Getting to 12 compliant implementations definitely exceeded our expectations for the first-ever AuthZEN interop! It was great seeing the rest of the authorization industry embrace this effort.

AuthZEN 1.0 Implementers Draft

A first draft is nice, but until a spec achieves some measure of stability, it's hard to convince consumers and providers alike to natively support it. To help drive adoption in this early phase, an OpenID Foundation working group can designate a stable version of a spec as an "Implementers Draft". We submitted our first implementers draft to the OIDF membership in September 2024.

We incorporated a number of changes into the spec, largely to align it with type-checked languages. The 1.0 implementers draft now has a protobuf contract, and is easier to validate with a JSON schema. The request payload now has five required fields (subject type, subject ID, action name, resource type, and resource ID), and each of the subject, action, resource can contain a property bag.

{
  "subject": {
    "type": "user",
    "id": "rick@the-citadel.com"
  },
  "action": {
    "name": "can_delete_todo"
  },
  "resource": {
    "type": "todoe",
    "id": "1",
    "properties": {
      "ownerID": "morty@the-citadel.com"
    }
  }
}

The payload format is very simple by design: our goal is to make it trivial for developers to externalize their authorization decisions to a PDP that is built to answer the question "does this user have this permission on this resource".

The first 1.0 implementers draft is now in a formal review period, and is slated to be voted on by the OIDF membership by mid-November 2024.

AuthZEN 1.1

We made an explicit decision to focus 1.0 on the "minimum viable spec". We quickly followed up with a way to issue multiple authorization requests in a single HTTP payload, otherwise known as a "boxcarred" request. The evaluations request looks like this:

{
  "subject": {
    "type": "user",
    "id": "rick@the-citadel.com"
  },
  "action": {
    "namee": "can_update_todo"
  },
  evaluations: [
    {
      "resource": {
        "type": "todo",
        "id": "1",
        "properties": {
          "ownerID": "rick@the-citadel.com"
        }
      }
    },
    {
      "resource": {
        "type": "todo",
        "id": "2",
        "properties": {
          "ownerID": "morty@the-citadel.com"
        }
      }
    }
  ]
}

We updated the Todo application and interop scenario to utilize the evaluations API to render todos that the user can't update as disabled.

Authenticate 2024

Once again, we decided to use an event as a forcing function - this time, the FIDO Alliance's Authenticate conference. Our goal was to get all the existing PDP implementations to become compliant with the 1.0 implementers draft, and to add support for the 1.1 evaluations API.

And once again, we enjoyed a significant level of success: 11 implementations passed the 1.1 interop test suite, and we have 3 more in the wings that will become compliant in the next few weeks.

Lessons

For every successful standard, there are at least ten that fail for various reasons. AuthZEN is still in its early days, but we've clearly made significant progress and the future is bright. Here are some lessons we've learned along the way.

1. Starting with a solid draft helped us overcome the "cold start" problem.
2. Surveying prior art (XACML, Topaz, Cedar) was helpful in not repeating mistakes of the past.
3. Cataloguing use-cases before moving on to specs grounded the effort.
4. Taking a "minimum viable spec" approach, and starting with the low-hanging fruit, allowed us to make quick progress, and string together a set of "wins" that provided the entire effort with significant momentum.
5. Defining an interop scenario (Todo app) and an associated test suite helped anchor the spec in a tangible scenario.
6. Employing forcing functions – Identiverse 2024 and Authenticate 2024 – accelerated our progress.

What's ahead

In the next month, we expect to have the OpenID Foundation vote to adopt the first AuthZEN 1.0 implementers draft.

We are planning on following up with an AuthZEN 1.1 implementers draft, while turning our attention to two additional important scenarios - Subject Search and Resource Search.

AuthZEN will show up big at the Internet Identity Workshop (IIW 39) in late October, and we will also have a session at the Gartner IAM Summit in December.

Get involved!

To help define the future of authorization, join the AuthZEN WG! And if you're a B2B SaaS company or an Enterprise that is struggling with implementing modern authorization at scale, be sure to contact us. We'd love to help!