[jzelinskie]

This project looks like a very nice lightweight way to implement policy in a Rust application; I really like the ergonomics of the builder. Despite being very different systems, the core permissions check being the same signature as a call to SpiceDB[0] (e.g. the subject, action, resource, and context) shows the beauty of the authorization problem-domain regardless of the implementation.

I would like to add some color that a policy engine is not all you need to implement authorization for your applications. Without data, there's nothing for a policy engine to execute a policy against and not all data is going to be conveniently in the request context to pass along. I'd like to see more policy engines take stances on how their users should get that data to their applications to improve the DX. Without doing so, you get the OPA[1] ecosystem where there are bunch of implementations filling the gap as an afterthought, which is great, but doesn't give a first-class experience.

[0] https://spicedb.io

[1] https://openpolicyagent.org

[gneray]

Agreed! But you're glossing over the Zanzibar point of view on this topic, which falls back to dual-writes. That approach has a lot of downsides: "Unfortunately, when making writes to multiple systems, there are no easy answers."[0]

Having spoken with the actual creators of Zanzibar, they lament the massive challenge this design presents and the heroics they undertook over 7+ years at Google to overcome them.

By contrast, we're seeing lots of the best tech companies opt for approaches that let them leave the data in their source database wherever and as much as possible [1]

[0] https://authzed.com/blog/the-dual-write-problem

[1] https://www.osohq.com/post/local-authorization

I'm founder of Oso btw.

[hardbyte]

Yeah a big motivation for us was avoiding the need to keep another system up to date. Gatehouse basically sits at the execute policy layer, and we let the application code decide how to unify the data (or not).

Oso local authorization looks like a fantastic solution.

[jzelinskie]

Thanks for the response. In my opinion, oso does the best of job of any policy engine at prescribing how input data to their system is fed (and your linked blog demonstrates it well!).

I do think you might have pivoted the conversation, though. My post was purely about federation strategies and policy engines, but you appear to discussing consistency and Zanzibar, which is only tangentially related. Federation and consistency aren't necessarily coupled. Oso also would require a complex scheme for achieving strict serializability, but it instead chooses to trade-off consistency of the centralized data in favor for the local data.