# Todo interop evolution

July 7, 2024

## Abstract

We need to bring the current interop scenario defined by AuthZEN working group up to speed with the latest draft of the spec. This document lists the challenges and lays out a set of potential options for how to proceed.

## Introduction

The AuthZEN interop scenario is a todo application. It is currently oriented around a stateless, attribute-centric approach.

In particular, for the `can_update_todo` and `can_delete_todo` operations, the caller (PEP) sends the `ownerID` of a Todo item as the resource to update or delete, and the PDP compares this value to the `identity` of the subject, allowing the operation if they are equal (or if the subject is in a privileged role, such as an `admin` or `evil_genius`).

To make this more concrete, expressing the `can_update_todo` policy in Rego:

package todoApp.can_update_todo

import input.resource
import input.user

default allowed = false

allowed {
  user.properties.roles[_] == "editor"
  user.id == resource.ownerID
}

allowed {
  user.properties.roles[_] == "evil_genius"
}

Note that this is a stateless model: the PDP is not required to hold on to any state associated with an individual Todo. Instead, the caller (PEP) passes all the information that's required to make a decision - specifically the subject's identity and the resource's ownerID.

## AuthZEN 1.0 alignment

The latest [AuthZEN spec](https://openid.github.io/authzen/) (July 3 2024) requires the following fields as mandatory in each request payload:

* subject type and ID
* action name
* resource type and ID

Comparing this to the current payload structure of the Todo sample:

* subject type and ID: the current [payloads](https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA?view#Requests-and-payloads) pass in a single property in the subject field - `identity`. This can easily be transformed into a `{ "type": "user", "id": "<content_of_identity>" }`. *No issues here*.
* action name: the current payloads pass the permission as `action.name`. *No issues here.*
* resource type and ID: the current [payloads](https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA?view#Requests-and-payloads) consistently pass in `resource.type` as `todo` or `user`. This is compliant. **However**, instead of an `resource.id`, the current payloads specify an `ownerID` of the todo.

The trivial "fix" would be to (also) send the Todo's ID as `resource.id`, and we can certainly do that. However, this glosses over the big reason why we made the 5-tuple *(subject type, subject id, action name, resource type, resource id)* mandatory in the first place: to allow stateful PDPs to join the party.

## Stateful PDPs

For ReBAC or Graph-oriented PDPs, the natural way to express the authorization model is to define `todo` as an object type, with an `owner` relationship to a `user`.

In Topaz, for example, this would be expressed like this:

types:
  user: {}
  todo:
    relations:
      owner: user
    permissions:
      can_update_todo: owner
      can_delete_todo: owner

As a Todo is added to the list, the PDP would track the owner of that todo by creating a relationship between the todo and the owner. In Zanzibar notation, this would be denoted as adding the `todo:123#owner@user:[e-mail]` tuple, which means "Todo 123's owner is User [e-mail]".

Note that a stateless PDP could still rely on the `ownerID` attribute passed in as part of the resource context, but to "do this right", a stateful PDP would want to implement the authorization policy as a `check("user:[e-mail]", "can_update_todo", "todo:123")`.

## The challenge

However, this would require the Todo app to inform the PDP to create a relation (tuple) between a user and a newly created Todo, and to delete that relation when the Todo is deleted. The message exchange patterns for creating and deleting relations (tuples) is outside the current scope of the AuthZEN specification. In other words, we don't have a vendor-neutral way of doing this.

## Options

There are a few options we could consider for how to move forward:

### 1. Stable IDs for Todos

The current Todo app is dynamic - any user that has the right permissions can add, update, and remove Todos.

In order to accommodate stateful PDPs, we could define a static list of Todos with stable IDs and specific owners, and enhance the resource context for each test case in the test suite with the right IDs.

For example:

{
  "request": {
    "subject": {
      "type": "user",
      "id": "CiRmZDQ2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs"
    },
    "action": {
      "name": "can_delete_todo"
    },
    "resource": {
      "type": "todo",
      "id": "rick-todo-1",
      "ownerID": "[e-mail]"
    }
  },
  "expected": true
}

This would require the stateful PDPs to load a static list of tuples that define relations between todo ID's and their owner users.

The downside to this approach is that the Todo application itself (with the React front-end) wouldn't work with the stateful PDPs, since those PDPs would not know about these dynamically added todos.

### 2. Add "create tuple" / "delete tuple" endpoints

In order to overcome the problem above, the Todo backend could optionally accept two additional endpoints - one for adding a tuple, and one for deleting a tuple.

Stateful PDPs could supply these endpoints (just like they supply the `/access/v1/evaluation` endpoint), and the Todo app would call these endpoints when adding or removing a Todo.

The drawback for this approach is that each stateful PDP could have a different message exchange pattern, and this would significantly complicate the design of the Todo app.

### 2.a. Do the above but in an API Gateway

A variation of (2) is to add vendor-specific code in an API gateway, so we wouldn't have to change the Todo app.

A response filter could pick up the Todo ID from a POST request to create a Todo, and call the stateful PDP endpoint to create the relationship. Same with a DELETE request.

Each stateful PDP could add a response filter to the POST and DELETE operations.

The drawback is that this only shifts the problem, and arguably makes it harder for implementers / readers of the interop scenario to understand what is going on, because the gateway code is opaque to them.

### 3. Send an SSF event for added/removed Todos

A stateful PDP registers for an event using the shared signals framework, and the Todo app becomes a SSF event source.

This feels like the right long-term design.

The drawback for this approach is that this brings into scope another specification, thereby increases the complexity and amount of time it takes for an implementation to be compatible with what was supposed to be a simple Todo interop scenario.

### 4. "Half-step" towards stateful PDPs

Speaking to Andres (OpenFGA), a ReBAC implementation could be constructed in the following way:

Types:
* `todo_list` - relations called `admin`, `editor`, `evil_genius` to specific users
* `todo` - relation back to the todo_list, and an `owner` relation to the user

Actions:
* `can_create_todos` and `can_read_todos` are actions on a `todo_list` instance, not a `todo`
* `can_read_user` is an action on a `user`
* `can_update_todo` and `can_delete_todo` are actions on a `todo` instance

For the interop scenario, we would define a stable identifier for the singleton instance of a `todo_list` (e.g. the ID would be `todo-list-1`).

The payloads for the `can_create_todos` and `can_read_todos` would look like this:

{
  "subject": {
    "type": "user",
    "id": "[e-mail]"
  },
  "action": {
    "name": "can_create_todos"
  },
  "resource": {
    "type": "todo-list",
    "id": "todo-list-1"
  }
}

The payloads for the `can_update_todo` and `can_delete_todo` would look like this:

{
  "subject": {
    "type": "user",
    "id": "[e-mail]"
  },
  "action": {
    "name": "can_delete_todo"
  },
  "resource": {
    "type": "todo",
    "id": "guid",
    "owner": {
      "type": "user",
      "id": "[e-mail]"
    }
  }
}

The ReBAC implementation would treat the `resource.owner` as a contextual tuple that indicates that the owner of the todo is Rick.

Instead of tracking the todo ownership in the stateful PDP, the ReBAC model simply relies on the owner attribute attached in the resource context.

The key advantage is that this is a relatively small step for the Todo app, and doesn't require additional interop surface area (such as events using SSF) or defining how to interact with a stateful PDP.

This is the option I would recommend moving forward with.

### 5. Others?

Discussion!