Hi Yaron,
I agree the useful move is properties before language. Analyzability is one
axis worth naming explicitly. I'd put a second one next to it, orthogonal to
the first, and I think this draft argues for it on its own.
Analyzability is a static property of the policy: ahead of time, can we tell
what it permits, where it conflicts, what a change to it does. It says nothing
about what was actually enforced, for whom, or whether the party that acted was
the one the policy was written for. A policy can be perfectly analyzable and
still be evaluated against an input the enforcement point assembled itself, on
behalf of a caller no one can later prove was present or authentic. For
delegated and agent workloads, those are not the same question.
The draft makes this visible rather than hiding it. The agent proposes its own
constraint contract, and Section 9.2 grants that a malicious agent can write a
policy that reads as restrictive while being subtly permissive. The RS builds
the evaluation input (Sections 3.3 and 7.2). The compliance story is RS-written
audit logs (Section 9.7). So the record of what was authorized and executed is
produced by the same component that made the decision, over an input that
component constructed. That is a workable engineering baseline. It is not
evidence that a regulator, or a second party relying on the decision, can
verify independently of the component that produced it.
So next to "can we analyze the policy," I'd state a second requirement: can the
enforced decision, and the presence and identity of the party it was enforced
for, be verified independently of the enforcement point. That is a runtime
property, distinct from analyzability, and a complete agent-authorization story
needs both. Stating it as a requirement keeps it separate from the mechanism
that satisfies it, which is where I'd agree the language question sits as well:
later, and downstream of the requirements.
Best,
Mohamad Khalil Yossif
On 14/06/2026 14:31:52, Yaron Sheffer <[email protected]> wrote:
Hi,
I came across the recently published draft-liu-oauth-rego-policy-00 [0].
First, apologies to the authors for commenting before they have had a chance to
present the draft on this list.
For many years, the OAuth community kept authorization policy languages out of
scope. I agree with the authors that it may be time to revisit that position,
particularly given the increased focus on workload authorization and AI agents
operating as workloads.
However, once we go there, we should also discuss what properties we need from
such languages. As input to that discussion, I would point to a recent AWS blog
post [1] explaining why Amazon chose Cedar for agentic workload authorization.
Granted that AWS is not a neutral party, but the post highlights an important
consideration: the ability to perform automated analysis of policies.
Rego is more expressive and more widely deployed than Cedar. On the other hand,
Cedar was designed to support reasoning about questions such as:
*
Whether policies are unintentionally over-permissive or over-restrictive.
*
Whether policies overlap or conflict.
*
The impact of a policy change on authorization outcomes.
It is far too early to discuss any specific language choice, but it would be
useful to discuss the requirements, including the tradeoff between
expressiveness and analyzability.
Thanks,
Yaron
[0] https://www.ietf.org/archive/id/draft-liu-oauth-rego-policy-00.html
[https://www.ietf.org/archive/id/draft-liu-oauth-rego-policy-00.html]
[1]
https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/
[https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/]
(discussion on Analyzability is in the second half of the post)
_______________________________________________ OAuth mailing list --
[email protected] To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
