Clarify match behavior for array fragments in security filter logic

[Martin187187]

Summary

The current security filter logic does not clearly specify how field paths ending in [] should be evaluated when they are used inside a filter condition.

This affects filters that target array-valued fragments, for example:

$aasdesc#specificAssetIds[]
$sm#semanticId.keys[]

The missing clarification makes it unclear whether a condition should be evaluated against the full array, or whether each array element should be matched individually against the corresponding fragment context.

Problem Statement

When a filter references a fragment path ending in [], there are at least two possible interpretations:

1. Whole-list interpretation
   The condition is evaluated against the entire list. The filter decides whether the full list matches the condition.

2. Element-match interpretation
   The fragment path defines an array element context. If the condition also references paths below that same array fragment, the condition is evaluated per array element. The filter matches if at least one element satisfies the condition.

The specification currently does not make this behavior explicit. As a result, implementations may interpret the same rule differently.

Example

The following rule is intended to evaluate specificAssetIds[] entries and allow access when the external subject ID contains either the requesting BPN claim or the special value PUBLIC_READABLE.

{
  "FRAGMENT": "$aasdesc#specificAssetIds[]",
  "CONDITION": {
    "$or": [
      {
        "$eq": [
          { "$attribute": { "CLAIM": "Edc-Bpn" } },
          { "$field": "$aasdesc#specificAssetIds[].externalSubjectId.keys[].value" }
        ]
      },
      {
        "$eq": [
          { "$strVal": "PUBLIC_READABLE" },
          { "$field": "$aasdesc#specificAssetIds[].externalSubjectId.keys[].value" }
        ]
      }
    ]
  }
}

Ambiguity in the Example

The example above can be interpreted in different ways:

Interpretation A: Evaluate the Complete specificAssetIds[] List

The condition is evaluated against the complete specificAssetIds array. In this case, the entire list is filtered if condition is false.

Interpretation B: Evaluate Each specificAssetIds[] Element Separately

The FRAGMENT path defines the matching scope. For each element of $aasdesc#specificAssetIds[], the condition is evaluated only against fields inside that specific element.

In this interpretation, the rule behaves similarly to a match expression:

• Iterate over each specificAssetIds[] element
• For the current element, evaluate the condition against its nested externalSubjectId.keys[] values
• If at least one element satisfies the condition, the fragment matches

Proposed Solution

Introduce and clarify the semantics of the optional MATCH parameter:

• MATCH: false (default)

  • The condition is evaluated against the full fragment (whole-list interpretation)
  • No implicit iteration over array elements is performed

• MATCH: true

  • Enables element-wise matching semantics
  • The fragment path ending with [] defines an iteration scope
  • The condition is evaluated independently for each element within that scope
  • The fragment matches if at least one element satisfies the condition

This makes the behavior explicit and avoids implicit or ambiguous interpretation of array paths.

Why This Matters

Without a defined behavior, different implementations may produce different authorization decisions for the same access rule.

This is especially relevant for claims or identifiers stored in arrays, such as:

• specificAssetIds[]
• semanticId.keys[]
• externalSubjectId.keys[]
• other nested identifier/key structures

For security-relevant filter logic, inconsistent interpretation can lead to either overly restrictive behavior or unintended access.

Expected Outcome

The specification should clarify the semantics of array fragments and matching behavior in filter conditions.

Ideally, it should include:

• A statement that element-wise matching is not the default behavior
• A clear definition of the MATCH parameter and its effect
• At least one example similar to the specificAssetIds[] case above