ARAP: which Context members a PDP binds to an approval

Open
#787 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
32/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active

Research direction

Start by reviewing the Authorization-Relevant Context and Approval Scope Extensions requirements in the profile, then read the unresolved discussion in #663 and the scope distinction in #745. The work requires a working group decision before guidance can be drafted, so no implementation entry point is identified. Done means the profile clearly states which Context members a PDP may bind to an approval and how volatility affects approval reuse.

Written by the indexing model from the issue text.

Description

access-requests

Raised on #663, and the one question there that no PR answers.

Problem

Exact matching over the Authorization-Relevant Context is the interop baseline: "two independently implemented PDP and Access Request Service pairs MUST interoperate on it." Approval Scope Extensions already lets a deployment record a broader or narrower scope, so the default is defeasible, and broader matching sits outside the base guarantee unless another profile defines one.

So the question is not whether to keep the baseline. It is what guidance governs which members a PDP puts in the bound set. A member included because it is security-relevant should make an approval inapplicable when it changes. A member excluded to make approvals reusable is acceptable only where that preserves the intended scope. The profile has guidance against binding volatile members and nothing beyond it.

Recommendation

A working group decision, and then guidance in the profile. #745 holds either way, 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.