Why ReBAC
Why roles and scopes do not describe agent access, and what changes when access is a relation.
The most common way to control access is to give roles to people and check the role: if user.hasRole("ADMIN"). For agents, this model breaks in three places.
The first is granularity. A role says what someone can do in general, not on which object. "Can open issues" applies to every repository. To say "can open issues in acme/payments", you need one role per repository, then one per combination of repository, team and environment. That is role explosion, and with it nobody can answer who has access to what anymore.
The second is time. When roles go in the token, access is frozen at issuance. A revocation waits for the token to expire, and the token grows with every new role.
The third is the agent itself. A role is given to someone. An agent acts for someone. The question "can this agent, for this person?" involves two identities and the relation between them, and a role has nowhere to store that.
Access as a relation
In ReBAC (Relationship-Based Access Control), access is a set of relations between objects, and a decision is the question "does this relation exist?". The model comes from Zanzibar, Google's authorization system, and OpenFGA is the open implementation that Xokepoint uses.
With relations, "the support agent can open an issue in acme/payments for alice" becomes three simple questions, each with an independent answer. Revoking one does not touch the others. And because relations are queried at call time, a revocation applies on the next call.
ReBAC does not cover everything. "Only refunds below USD 100" is not a relation, it is a condition on an argument. Xokepoint evaluates these conditions in CEL, in the PDP (Conditions).