Certification Scenario Batch cases 6.2.1 and 6.2.6: may the harness check the fixture decision they contain?

Open
  • Is something wrong?
#773 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@alexolivier is already working on this.

Since Oct 29, 2026.

  • #793 by @alexolivier — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
testing

Research direction

Read the scenario text in Sections 4.4, 4.6, 6.2.1, 6.2.6, and 7.1.1, then inspect the two corresponding harness modules mentioned in the issue. Compare their decision assertions with the fixture rules and batch defaults. Done means resolving the stated interpretation and updating the relevant scenario wording or harness checks consistently.

Written by the indexing model from the issue text.

Description

authorization-api certification

This case validates response structure only: the harness asserts that evaluations is an array of two objects, each containing a decision boolean. It does not assert the decision values. The first evaluation (alice/read/record-1) corresponds to fixture rule 1 (Section 4.4) and the second (alice/read/record-2) is unspecified by the fixture and therefore implementer-defined. (scenario §6.2.1)

Expected: HTTP 200 with two evaluations. The harness validates that the request is accepted; the decision values are not validated (not fixture rules). (scenario §6.2.6)

For subject alice performing action read on resource record-1: the decision MUST be true. […] These eight decisions are the only decision values the harness validates. (scenario §4.4)

Both cases send a top-level subject and action, and evaluations that name only their resource. The first evaluation in each is alice reading record-1, which fixture rule 1 decides. §6.2.6 calls its decisions "not fixture rules", although its first evaluation is rule 1, and §4.6 says context does not change fixture decisions.

Suite today. Both modules require the first decision to be true and accept either value for the second. Rule 1 fixes that decision whatever the batch shape or context, and it is the only Core batch check that the PDP applied the top-level subject and action (spec §7.1.1): cases 6.2.2 and 6.2.5 send fully specified evaluations. A PDP that ignores the top-level defaults, and answers false or an error for each item, would otherwise pass the Core batch plan.

Questions.

  1. May the harness validate a rule-1 decision wherever a request contains one, as §4.4 reads, or only in the cases that say they validate decisions?
  2. If it may, could §6.2.1 and §6.2.6 say so, for example "validates the response structure, and the rule-1 decision of the first evaluation"?
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.