[ARAP] evaluation_id-only binding path contradicts stateless PDP design goal

[vatsalgupta]

The spec states as a design goal:

[ARAP] evaluation_id-only binding path contradicts stateless PDP design goal "Preserve the AuthZEN Authorization API's stateless evaluation

model: the PDP retains no decision state between the denial and
the re-evaluation, and the durable request and approval state
lives in the Access Request Service role."

But the Access Request Service processing rules say:

"the service MUST resolve or validate denial.evaluation_id,
retrieve the Subject, Resource, Action, authorization-relevant
Context, and expires_at the PDP recorded for that
evaluation"

For the ARS to retrieve what the PDP recorded, that data has to
be stored somewhere. A stateless PDP stores nothing. An
independent ARS has no access to it and there is no defined API
to fetch it.

This came up in a WG call (Omri flagged it) but there is no
issue tracking it yet.

The binding_token path does not have this problem. The PDP
signs and forgets. The ARS verifies the signature. No stored
state needed. But binding_token is OPTIONAL, and the spec
treats the evaluation_id-only path as equally valid. That only
works when the PDP and ARS share state, which is not the
independent ARS topology the spec is trying to enable.

Options

Option A: Require binding_token when the ARS is
independent of the PDP. The evaluation_id-only path becomes
limited to same-service or shared-state deployments. No protocol
changes needed, just a clarification of when each path applies.

Option B: Define a mechanism for the PDP to push evaluation
records to the ARS at denial time. This preserves the
evaluation_id-only path for independent deployments but adds
a new API surface.

Option C: Drop the stateless design goal as it applies to
the evaluation_id path and explicitly document the state
requirements. Honest but weakens the spec's alignment with
base AuthZEN.

Option A seems like the right call. The binding_token path
already solves the stateless case cleanly.

[mcguinness]

Agreed, and this is a real gap. Option A was the intent: binding_token is the by-value path for an independent ARS, and evaluation_id was only ever meant for same-service or shared-state deployments where the ARS can actually resolve the recorded denial. I did not formalize that deployment model or make it a requirement, so the spec currently presents the two as co-equal alternatives and the ARS rule even says "retrieve ... the expires_at the PDP recorded for that evaluation," which implies PDP-side storage and contradicts the stateless goal. That wording is the bug.

The resolution is also just the missing mirror of a rule the spec already has. On re-evaluation, when the PDP cannot resolve approval.id from state shared with or delegated by the ARS, approval.state (by value) is required. The denial side needs the inverse: when the ARS cannot resolve evaluation_id from state shared with or delegated by the PDP, binding_token is required. Today that inverse is absent, which is exactly why the independent-ARS case falls through.

So I would resolve it as Option A, a clarification rather than a protocol change:

1. State the deployment model explicitly: evaluation_id-only binding applies to same-service or shared-state PDP/ARS deployments; independent deployments use binding_token.
2. Add the normative requirement: when the ARS does not share state with the PDP, the denial MUST carry binding_token.
3. Fix the "the PDP recorded" wording so the binding record is attributed to ARS-held or shared state, consistent with the stateless goal.

Before I draft these edits, does the WG agree this is the right resolution, in particular requiring binding_token for the independent topology and keeping evaluation_id-only as the shared-state path?