This is quite interesting, although I'm worried about the policies being tied to the underlying programming language. While this does allow for additional flexibility, it makes them hard to share in a polyglot shop.
The whole point is to have language agnostic policy definitions. You write policies in the custom policy language, and every application that needs to do permission checks goes through the provided policy engine.
The programming language specific code just is some plumbing for accessing the policy agent.
So policies are inherently shareable.
> The programming language specific code just is some plumbing for accessing the policy agent.
If you want to make policy decisions over your application data you still need to work out a way to move it into the OPA service, or send it as part of the policy request.
You can make oso policies language agnostic if you take a similar approach and have a small number of shim rules that handle the application-specific parts.
You're right, and this is something we've discussed a bunch. Our current view is that:
1. Allowing teams to standarise on an _approach_ and a library in the first place is a huge step up from individual ad hoc implementations.
2. If you have shared logic between applications, you can still write language-agnostic policies and share those between them. If there are parts that are specific to an application/language, its easy enough to pull these into separate rules and add shims.
3. We intentionally wanted to keep the language lean to lower the learning curve. But we're considering adding a standard library in the future, powered by the Rust core, to provide common functionality. The nice thing is that you're not limited by how fast we add those.
We're interested in hearing from folks who are working in those environments to hear what would make the most sense for them.