[ARAP] Broad-scope approval matching is deployment-defined. It breaks the primary AI agent use case across vendors.

[vatsalgupta]

The spec's primary motivation is AI agents that discover
resources mid-task. The scenario is: an agent is running a task,
hits a resource it was never pre-authorized for, gets denied,
requests access, someone approves, and the agent proceeds.

The problem is what that approval actually covers.

Say the agent is building a renewal report and needs to read 50
CRM records. Each one is a separate resource. Under the
exact-match baseline, the approval for crm-record-001 covers
only crm-record-001. The agent has to go through the full
deny/request/approve cycle 50 times, once per record.

The spec acknowledges this and says broad-scope approvals fix it.
Approve "this agent can read all CRM records for 7 days" and the
agent is unblocked for the whole class. That is the value
proposition.

But then the spec says:

"Broader approvals... are where the broad-approval benefit
lives, but their matching is not portable across policy
engines."

This means two AuthZEN implementations decide for themselves
what "all CRM records" means, how it is represented on the wire,
and how the PDP checks whether a given evaluation falls within
it. If you build a PEP against one AuthZEN PDP and swap in a
different PDP from another vendor, broad-scope approvals stop
working.

This is especially a problem for independent PDP and ARS
deployments, which the spec explicitly supports. The ARS
approves a broad scope and encodes it in approval.state. With
no standard representation, a PDP from one vendor cannot
interpret an approval granted by an ARS from another.

[mcguinness]

You have put your finger on a real and deliberate limitation, and the renewal-report example is the right way to make it concrete. Two clarifications change the shape of it, and the second is where the actionable work is.

Broad approvals work two ways, and only one has the portability gap.

1. Entitlement / lookup (portable today). The spec's primary answer to the 50-records problem is not scope-matching: an approval can grant "an entitlement, role, scope, or other persistent state," and later evaluations matching that state succeed without new Access Requests. Approve "this agent can read CRM records for 7 days," provision it as an entitlement, and any PDP wired to that attribute source honors it on re-evaluation, the way RBAC is portable across vendors. This is already the common pattern in IGA and just-in-time (JIT) access solutions: approval provisions a grant (a role, group, or time-bounded entitlement) in the backing system, and enforcement points read it as normal state. The broadening lives at the attribute layer, which AuthZEN already treats as PDP input, so no shared scope grammar is needed.

2. Bound-reference / by-value (the real gap). When there is no shared backing state and the broadened scope is carried inside approval.state, a vendor-B PDP cannot interpret what a vendor-A ARS encoded as "all CRM records." That is exactly your case, and the spec's "not portable across policy engines" line is about this configuration specifically.

So the gap is narrower than "broad-scope stops working across vendors": it is "broad-scope carried by value, with no shared entitlement state." For fully independent PDP and ARS with no common attribute source, that is the configuration you cited, so the concern stands, just localized.

Why it was deferred. A portable representation of "all CRM records where region is EU and amount is under 10k" is a resource-set plus constraint-matching language, which is a policy language. AuthZEN is deliberately policy-language-agnostic, so the WG set the interoperable floor at exact-match and pushed broader matching to deployments or downstream profiles.

The tractable middle. We do not have to choose between exact-match and a full constraint language. Raise the floor one notch with an engine-neutral tier: define an optional collection/type scope that matches when the evaluation's resource type (plus action and the bound Context member set) equals the approved scope, ignoring resource.id, bounded by approved_until; carry it as a standard claim alongside binding_context_members in approval.state. That collapses the 50-record cycle to one approval, is trivially checkable by any PDP, and needs no policy language. Attribute predicates (region, amount) stay deployment-defined, because that is where the policy-language problem actually lives.

This could land as a normative "broadened-scope baseline" subsection or a short downstream profile, and I am happy to draft it. The question for the WG: is type/collection-level matching enough of the real need to standardize as the next tier, or do most deployments need attribute constraints, in which case the honest answer is the entitlement/lookup model and we should document that pattern more prominently rather than grow the wire format?