> However, [policy as graph systems] do come with drawbacks. Compared to policy-as-code, graph-based systems exhibit lower performance and are practically unfea

> However, [policy as graph systems] do come with drawbacks. Compared to policy-as-code, graph-based systems exhibit lower performance and are practically unfeasible to run at the edge due to their size. They also come with higher latency, owing to their non-local nature, and are limited to simple ReBAC policies (even SpiceDB Caveats you end up with a limited form of ABAC, crippled even further with loading dynamic data). You can use a bit of code atop what TFA calls ReBAC to get ABAC. Suppose your ReBAC check primitive is `check(subject, verb, label)`, and you want to have subject attributes like "DID_2FA", "DID_MFA", "IS_INSIDE_PERIMETER", etc., and grant/label attributes like "REQUIRES_2FA", etc, you might implement `check_prime()` like: check_prime(s, v, l): if !check(s, v, l): return false if l.wants_2fa() and !s.did_2fa: return false ... Where grant/label attributes are singletons that imply one subject singleton attribute is required then this can be simplified and made more extensible. In other words: start with ReBAC and add the ABAC bits you want. I.e., cross the two schemes.