docs(access-rules): add normative Evaluation Semantics clause - #79
Draft
aorzelskiGH wants to merge 2 commits into
Draft
docs(access-rules): add normative Evaluation Semantics clause#79aorzelskiGH wants to merge 2 commits into
aorzelskiGH wants to merge 2 commits into
Conversation
Specify how the Access Rule Model MUST be evaluated so that
implementations behave deterministically:
- Rule combination
permit-overrides; DISABLED rules are ignored at enforcement;
applicability requires OBJECT/RIGHT/field resolution plus a
FORMULA evaluating to true; no applicable ALLOW => deny.
- Error handling
missing CLAIM, failing cast, or Descriptor-based FieldIdentifier
in a non-Registry profile => rule is "not applicable" (neither
grants nor denies, MUST NOT fail evaluation);
unresolvable FieldIdentifier inside a comparison => false;
unresolved USEACL/USEOBJECTS/USEFORMULA/USEATTRIBUTES or
schema-invalid document => reject at load time.
- Filter combination
FILTERs on the same FRAGMENT across applicable ALLOW rules are
OR-combined; FILTERs on different FRAGMENTs are applied
independently; empty FILTERLIST is equivalent to no filter;
absence of FILTER/FILTERLIST exposes the full matched object.
- Interaction with the Query Language
fixed order (parse -> candidate set -> apply rules -> apply
FILTER/FILTERLIST); implementations may optimise as long as the
observable outcome is preserved.
Refs: Review Finding T-15
Made-with: Cursor
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Martin187187
requested changes
Jun 8, 2026
|
|
||
| === Filter Combination | ||
|
|
||
| * If several applicable ALLOW rules define a `FILTER` on the same `FRAGMENT`, the individual `CONDITION`s are combined with logical OR: the union of matching fragments is exposed. |
Collaborator
There was a problem hiding this comment.
This is only the case when implementaion supports combined access rules handling. make this more clear
Collaborator
There was a problem hiding this comment.
Also explain that multiple filters within a single access rule are handled as a logical AND. Correlating filters across multiple rules are handled as a logical OR.
| The following situations MUST NOT cause evaluation to fail; instead the referencing rule is classified as *inapplicable* and does not contribute to the ALLOW set: | ||
|
|
||
| * a required CLAIM is not present in the access token; | ||
| * a cast produces an invalid value (e.g. `dateTime("abc")`); |
Collaborator
There was a problem hiding this comment.
This is probably too strict. Incorrect casts on FieldIdentifier should not cause the operation to fail. Instead, only the casts that are valid should be applied, and the others should be ignored.
|
|
||
| When access rules restrict the result set of a query (see IDTA-01002 `query-language.adoc`), the following order MUST be observed: | ||
|
|
||
| 1. The query is parsed and validated. |
Martin187187
approved these changes
Jun 29, 2026
Martin187187
marked this pull request as draft
June 29, 2026 12:07
| * a required CLAIM is not present in the access token; | ||
| * a Descriptor-based FieldIdentifier is used in a non-Registry profile where descriptors are not available. | ||
|
|
||
| The following situations MUST produce a *comparison result of `false`*, so the containing formula continues to evaluate normally: |
Collaborator
There was a problem hiding this comment.
so the containing formula continues to evaluate normally
-> is self explainory
| * a cast cannot produce any valid value for the containing comparison, e.g. all values of a FieldIdentifier fail `dateTime(...)` conversion; | ||
| * a list-valued FieldIdentifier is evaluated against a comparison operator whose right-hand side is a scalar and no element matches. | ||
|
|
||
| The following situations MUST cause the access rule set to be *rejected at load time*; evaluation MUST NOT begin: |
BirgitBoss
changed the base branch from
IDTA-01004-3-1_Working
to
IDTA-01004-3-2_Working
August 4, 2026 09:45
Martin187187
requested changes
Aug 24, 2026
Martin187187
left a comment
Martin187187
left a comment
Collaborator
There was a problem hiding this comment.
this has to be inspected in detail
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a normative
Evaluation Semanticsclause toaccess-rule-model.adocso that rule combination, error cases and filter combination behave deterministically across implementations.Problem
The current specification describes the syntax of access rules in detail, but leaves several evaluation questions implicit:
CLAIMis missing, a cast fails, or a FieldIdentifier does not resolve on the target?FILTER/FILTERLISTbe combined across matching rules?Without normative rules, implementations diverge (fail-open vs. fail-closed vs. error), blocking conformance testing.
Solution
Introduce
Evaluation Semantics (normative)covering:FORMULA=true.false; unresolved USEACL/USEOBJECTS/USEFORMULA/USEATTRIBUTES or schema-invalid document => reject at load time.Affected files
documentation/IDTA-01004/modules/ROOT/pages/access-rule-model.adocReview notes
admin-shell-io/aas-specs-api#585adds the matchingQuery Evaluation Semanticsclause.Descriptor FieldIdentifier Applicability(docs(access-rules): clarify Descriptor FieldIdentifier applicability #78) andXOR/Mix(PR fix(schema): use anyOf where BNF allows mixed inline and named groups #75).Refs: Review Finding T-15