Hi Yaron, Thanks for raising this. I agree with your point that "it may be time to revisit that position, particularly given the increased focus on workload authorization and AI agents operating as workloads." The agent workload context makes policy standardization more urgent. To clarify the draft's design intent: we use Rego as a concrete example, making policy-as-code a first-class authorization object in the OAuth flow. The RAR type defines how a policy is proposed, validated, bound to a token, and evaluated at the RS, with reverse-guided authorization enabling autonomous recovery. Tradeoffs like analyzability vs. expressiveness can be addressed at the profile level. I've been thinking about the right scope for OAuth. Perhaps the goal should not be "standardize a policy language" but "standardize how policies are bound to OAuth tokens." The language itself can be standardized as profiles or remain an implementation choice, while OAuth defines the binding mechanism (RAR type, metadata, evaluation hints etc.). This would keep the scope focused on OAuth's core mission while enabling policy-as-code as a first-class authorization object. I'd be happy to organize an offline discussion in Vienna to continue this conversation. The current draft can serve as a strawman, and I'm open to evolving it based on the WG's consensus. Thanks, Dapeng Liu ------------------------------------------------------------------ 发件人：Yaron Sheffer <[email protected]> 发送时间：2026年6月14日(周日) 19:32 收件人：oauth<[email protected]> 主 题：[OAUTH-WG] Standardizing a policy language 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]
