docs(profiles): add FieldIdentifier applicability table per profile#584
Open
aorzelskiGH wants to merge 1 commit into
Open
docs(profiles): add FieldIdentifier applicability table per profile#584aorzelskiGH wants to merge 1 commit into
aorzelskiGH wants to merge 1 commit into
Conversation
Add a normative summary of which Query / Access-Rule FieldIdentifier prefix is meaningful per service specification family (Repository vs. Registry vs. AAS/Submodel service). The table makes it explicit that - $aasdesc / $smdesc are only applicable in Registry deployments; - $cd is only applicable in the ConceptDescriptionRepository family; - queries / access rules referencing a non-applicable prefix in the chosen profile are treated as "not applicable" rather than as evaluation errors. Refs: Review Finding T-07 Made-with: Cursor
aorzelskiGH
requested review from
BirgitBoss,
alexgordtop,
danielporta,
g1zzm0,
mjacoby,
sebbader-sap,
waltersve and
zrgt
as code owners
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| [#fieldidentifier-applicability] | ||
| === FieldIdentifier Applicability per Profile | ||
|
|
||
| The AAS Query Language (see xref:query-language.adoc[]) and the Security Access Rule Model (see the Security specification, IDTA-01004) use a set of FieldIdentifier prefixes (`$aas`, `$sm`, `$sme`, `$cd`, `$aasdesc`, `$smdesc`). Not every prefix is meaningful in every profile, because the underlying data is only exposed by specific service specifications. |
|
|
||
| [cols="3,1,1,1,1,1,1",options="header"] | ||
| |=== | ||
| | Service Specification (family) | $aas | $sm | $sme | $cd | $aasdesc | $smdesc |
|
|
||
| [cols="3,1,1,1,1,1,1",options="header"] | ||
| |=== | ||
| | Service Specification (family) | $aas | $sm | $sme | $cd | $aasdesc | $smdesc |
|
|
||
| Queries and access rules that reference a prefix marked with "—" for the chosen profile are treated as *not applicable* in that profile: they MUST NOT cause a parse or evaluation error, they simply do not match any object in the deployment. Implementations SHOULD clearly indicate in their deployment documentation which profiles they expose so that operators can scope their rules accordingly. | ||
|
|
||
| This table is referenced by IDTA-01004 § "Descriptor FieldIdentifier Applicability". |
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 "FieldIdentifier Applicability per Profile" section to IDTA-01002 service specifications and profiles. The section states which Query / Access-Rule FieldIdentifier prefixes (
$aas,$sm,$sme,$cd,$aasdesc,$smdesc) are meaningful in which service specification family, and how non-applicable rules MUST be handled.Problem
The Query Language and the Security Access Rule Model (IDTA-01004) use the same FieldIdentifier prefixes but the underlying data is only exposed by specific profiles. For example,
$aasdesconly makes sense in Registry deployments; in a pure Repository deployment there is no descriptor data to evaluate against. The specification currently does not say what should happen when such a rule or query is formulated against a profile that cannot provide the data, and implementations disagree.Solution
Add a table to
service-specifications-and-profiles.adoclisting the applicable prefixes per service specification family and specify that non-applicable rules/queries MUST be treated as "not applicable" (no match, no error).Affected files
documentation/IDTA-01002-3/modules/ROOT/pages/http-rest-api/service-specifications-and-profiles.adocReview notes
aas-specs-security(IDTA-01004) that references this section from the Descriptor applicability paragraph in the Access Rule Model.Refs: Review Finding T-07