Hi Mohamad, I appreciate your point that the draft makes the verifiability gap visible rather than hiding it. Your reading of Sections 9.2, 3.3, 7.2, and 9.7 is accurate. The requirement you state, "can the enforced decision, and the presence and identity of the party it was enforced for, be verified independently of the enforcement point," points to a concrete extension of draft-liu-oauth-authorization-evidence: https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence-01 <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence-01 >. The current mechanism uses a detached JWS signed by the AS over confirmation fields, providing signature independence as a foundation. Extending it to include policy evaluation verification is a natural next step. The evidence record could be extended to include: the complete evaluation input, the policy language type, and the specific policy that was evaluated. With these fields, a third-party auditor could re-evaluate policy(input) and verify the recorded decision matches the expected output. This enables verification of decision correctness and policy logic adherence, not just authorization attestation. That said, this extension still trusts the RS to assemble the correct input. The input integrity gap can be partially mitigated: policies can declare required input fields, input sources can sign their contributions, and RS can commit to the input before evaluation. The design needs to balance verifiability against engineering complexity. As I mentioned in my reply to Yaron, tradeoffs can be addressed at the profile level. Both axes are independent design constraints. The core binding mechanism provides the foundation, while profiles can specify requirements based on their target use cases. Happy to discuss this further in Vienna if you're interested. Thanks, Dapeng Liu ------------------------------------------------------------------ 发件人：Mohamad Khalil-Yossif <[email protected]> 发送时间：2026年6月15日(周一) 14:53 收件人：Yaron Sheffer<[email protected]>; oauth<[email protected]> 主 题：[OAUTH-WG] Re: Standardizing a policy language 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]
