ARAP: what Context the PEP sends at re-evaluation

Open
  • Is something wrong?
#783 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Domain
authorization, documentation, security

Research direction

Start with the ARAP binding fixture linked in the issue and the PEP Processing Rules governing re-evaluation. Trace the referenced binding_context_members, binding_token, and examples that send only time and approval. Done means the specification clearly requires preserving operation inputs during re-evaluation and requires comparing every bound member without treating absent members as matching, with examples and fixture behavior aligned.

Written by the indexing model from the issue text.

Description

access-requests

Split out of #663, problem 1.

Problem

Exact-match approval scope compares the authorization-relevant Context against the bound values, but no rule tells the PEP to resend the original evaluation's Context, and the PEP cannot compute the authorization-relevant set: the PDP fixes it in binding_context_members or in shared state, and the PEP carries binding_token unchanged without interpreting it. The examples send only time and approval, so a PEP that follows them is denied out_of_scope whenever the original evaluation had authorization-relevant Context. Two conformant implementations fail on the first re-evaluation.

The failure is reproduced, not hypothetical. @aeoess's A10 fixture sends the original region: us-east request, then re-evaluates with only the approval and the time, and gets out_of_scope: https://github.com/Agent-Authority-Conformance/aps-conformance-suite/tree/fec93192e844e6b94aec01cd4de579e65bec8bab/fixtures/arap-binding

The same gap appears in the other direction. PEP Processing Rules already require the PEP to "preserve the Resource, Action, and authorization-relevant Context of the denied evaluation", which names a set the PEP has no way to determine. It is satisfiable by preserving the whole original Context, and the following paragraph's "MUST NOT change or remove authorization-relevant context" implies that is the intent.

Recommendation

Context construction. The PEP builds re-evaluation Context by its ordinary evaluation rules, and presenting an approval MUST NOT remove inputs. Current observations are refreshed; operation inputs keep their meaning. Correct the examples to match.

Whole-subset comparison. The PDP MUST compare every bound member and MUST NOT treat an absent one as matching, which makes explicit an obligation structural comparison already implies.

The alternative, having the PDP compare only members present in both, is weaker: it lets a PEP silently narrow the compared set.

Cost

Deployments must preserve or recover the operation inputs for as long as they support resuming the operation, which can extend past submission and across processes. A missing bound input makes the approval inapplicable, and nothing identifies which member, since out_of_scope carries no detail.

Status

#745, three commits on main, six keywords added. It should go first: it is the only one of the three PRs fixing a reproduced failure. It holds whichever way the bound-set question goes, since it governs what the PEP sends rather than what the PDP binds.

Dominant language
TypeScript
Stars
170
Forks
46
Avg merge
18h 5m
Merged PRs (30d)
43

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openid/authzen

All issues in openid/authzen

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.