add example access rules for expressing "Append"

[BirgitBoss]

In some applications users are not allowed to change anything but only to add data. this is especially true for SubmodelElementLists or optional fields.

This is for example true for DPP applications.

Proposed Solution:

https://industrialdigitaltwin.io/aas-specifications/IDTA-01004/v3.0.1/access-rule-model.html#bnf-grammar

<Right> ::=
    "CREATE" | "READ" | "UPDATE" | "DELETE" | "EXECUTE" | "VIEW" | "ALL" | "TREE"

Mit

<Right> ::=
    "CREATE" | "READ" | "UPDATE" | “AMEND” | "DELETE" | "EXECUTE" | "VIEW" | "ALL" | "TREE"

instead of "AMEND" also "APPEND" migth be useful.

Semantics:

• for SubmodelElementList: only adding new elements is allowed, no removal, no replacing
• for other SubmodelElements: only adding if not yet existing, no removal, no replacing (only possible for optional fields)

Add Example to Annex https://industrialdigitaltwin.io/aas-specifications/IDTA-01004/v3.0.1/annex/text-access-rule-examples.html

Example:

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ APPEND
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(SubmodelElementList)https://submodel1.company1.com/CertificateSet"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest"

Similar for optional attribute that can be added

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ APPEND
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(AssetAdministrationShell)[https://submodel1.company1.com/Shell"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest"

Background:

The JSON Patch Operation allows both: replacing and adding new elements
The RFC 6902 "add" operation also allows to replace existing elements

[BirgitBoss]

TF Security 2025-09-09

It is already possible to express the requirement "AMEND" or "APPEND" with RIGHTS "CREATE"

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ CREATE
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(SubmodelElementList)https://submodel1.company1.com/CertificateSet"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest"

does not mean that the Role is allowed to create the CertificateSet but to create elements within the CertificateSet.

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ CREATE
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(Submodel)https://submodel1.company1.com"
  FORMULA:
    (CLAIM("Role") $eq "person with legitimate interest" AND idShort $eq "CertificateSet")

would mean that the role is allowed to create the CertificateSet itself

EXAMPLE with ROUTE with this kind of wildcard (*) that is not supported:

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  ROUTE: /submodels/*/CertificateSet
  RIGHTS: READ CREATE
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(SubmodelElementList)https://submodel1.company1.com/CertificateSet"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest"

not allowed "/submodels/*/CertificateSet but only "/submodels/124/*"

Example for the optional elements not yet existing

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ CREATE
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(Submodel)(https://submodel1.company1.com)"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest"

would allow to create new submodel element. But it is not allowed to overwrite an existing SubmodelElement, e.g. Property of kind=Instance etc. Mandatory submodel elements conformant to Submodel Template should be already provided when creating the Submodel Instance. It also not not allow to create the submodel itself

for "all" DPPs, not only for specific ones

User is only allowed to add elements to the CertificateSet in any Submodel

NOTE: simplified notion for semanticId (any SME in Submodel)

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("Role")
  RIGHTS: READ CREATE
  ACCESS: ALLOW
  OBJECTS:
    REFERABLE "(Submodel)*"
  FORMULA:
    CLAIM("Role") $eq "person with legitimate interest" AND $sme#semanticId = "CertificateSet"

Proposal:
add example to Appendix of Security spec.