# Schema-friendly AuthZEN payloads

This document lists some possible refinements in the AuthZEN `evaluation` request payload to make it easier to:
1. Write a protobuf definition -> gRPC binding
2. Write a JSON-schema
3. Write an OpenAPI definition with effective type-checking

## Issues

1. `subject` and `resource` include mandatory fields but are also completely open-ended.
2. `subject.id` and `resource.id` can be strings OR arbitrary JSON objects.

## Observations

### Complex `id` fields and RFC 9493
The TraT spec, which inspired us to list RFC 9493 as an "optional" way to describe subject IDs, has since then DROPPED the reference to RFC 9493 altogether. They represent subjects as (namespaced) strings.

Atul and George believe that we should be able to do the same thing with AuthZEN.

### gRPC bindings
Cerbos, Topaz / Aserto, and SGNL all have protobuf descriptions that generate gRPC contracts and REST bindings. So do OpenFGA and SpiceDB. Currently there is no way to map the REST definitions we created to gRPC.

Atul mentions that many IETF WGs are contending with this issue. He and George feel like since we don't have any dependency on JWE or JWS (which are arbitrary JSON), we can "do this right" from the start.

gRPC-friendly request payloads would also be much easier to write JSON-schemas for.

## Request payload example

{
  "subject": {
    "type": "mandatory - string",
    "id": "mandatory - string",
    "properties": {
      "arbitrary": "JSON",
      "can": {
        "be": "entered",
        "here": [1, 2, 3]
      }
    }
  },
  "action": {
    "name": "mandatory - string",
    "properties": {
      "arbitrary": "JSON"
    }
  },
  "resource": {
    "type": "mandatory - string",
    "id": "mandatory - string",
    "properties": {
      "arbitrary": "JSON",
      "can": {
        "be": "entered",
        "here": [1, 2, 3]
      }
    }
  },
  "context": {
    "arbitrary": "JSON",
    "can": {
      "be": "entered",
      "here": [1, 2, 3]
    }
  }
}