SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions.

SpiceDB

if it is on the same machine, most of the penalty would be around the actual checks

well it'd be deployed in our k8s cluster so we'd set it up to be on the same node whenever possible

<@444996680530657281> continuing my thinking from before... tell me if this seems insane, but I was think our authz proxy keeps a record of `serviceaccount` and `prefix` objects, and binds service accounts to be readers/writers on prefixes. Does this seem a sensible way of authorising the proxying

So I want to effectively "delegate" management of a subset of the authz system, so svc A can update everything under its own prefix

And svc A needs to go through the proxy to update its authz records

In order to authorise that, I need to identify the service, hence a service account (not k8s specific, that's just an authN concern)

you're basically trading a known secret for a prefix in the proxy

another option would be to have the caller hold a signed version of the prefix

but then revocation becomes a possible issue

Right yeah, and the prefix would have to be checked at issue-time anyway, which should come from the authz layer itself, at which point it's not adding much value having it in the token I guess, if everything goes through the proxy anyway

is there a way to constrict assignment via a relation? For example:

```
type user {}
type district {
    relation admin: user
}
type site {
    relation district
    relation site_admin: user // <- is it possible to limit this down to a user must be an admin of district?
}
```

you'd usually use an intersection for that

```
definition user {}

definition district {
  relation admin: user
}

definition site {
  relation district: district
  relation site_admin: user
  permission can_view_site = site_admin & district->admin
}
```

it was just a contrived example but they wouldn't be in what I'm modeling

or `permission can_view_site = district->admin`

the docs don't cover querying permissions for a definition so I'm guessing that's still a work in progress. I'm trying to model it so that if certain relations are revoked, cascading permissions are reduced.