Clarification of link semantics in SSP model #1062
Description
In working on SSP display logic the question of link semantics comes up.
More specifically it would be nice to have the following grid populated, corrected where wrong or incomplete, and validated against real-world requirements and feasibility. (XPath notation is used assuming the OSCAL SSP XML model as context.)
| reference | target element type | target ID type | target scope | referential constraint |
|---|---|---|---|---|
set-parameter/@param-id |
param |
id |
Baseline (imported) | a single target param must be found in the baseline |
implemented-requirement/@control-id |
control |
id |
Baseline (imported) | a single target control must be found in the baseline |
statement/@statement-id |
control//part |
id |
Baseline (imported) | a single target part must be found in the baseline |
user/role-id |
role |
id |
Same SSP (only?) | a single target role must be found (in the same SSP?) |
responsible-party/@role-id |
role |
id |
Same SSP (only?) | a single target role must be found (in the same SSP?) |
responsible-role/@role-id |
role |
id |
Same SSP (only?) | a single target role must be found (in the same SSP?) |
responsible-party/party-uuid |
party |
uuid |
Same SSP (only?) | a single target party must be found (in the same SSP?) |
leveraged-authorization/party-uuid |
party |
uuid |
Same SSP (only?) | a single target party must be found (in the same SSP?) |
responsible-role/party-uuid |
party |
uuid |
Same SSP (only?) | a single target party must be found (in the same SSP?) |
implemented-component/@component-uuid |
component |
uuid |
Same SSP (or imported?) | a single target component must be found (where?) |
by-component/@component-uuid |
component |
uuid |
Same SSP (or imported?) | a single target component must be found (where?) |
responsibility/@provided-uuid |
provided | responsibility? |
uuid |
? | |
inherited/@provided-uuid |
provided | responsibility? |
uuid |
? | |
satisfied/@responsibility-uuid |
provided | responsibility? |
uuid |
? |
(Note: some of this is currently guesswork.)
This is in anticipation of being able to implement checks on these constraints using features of our tooling, but also to clarify the relations to support the definition of processing requirements (link traversal, dynamic transclusion etc.).
By "baseline" is meant either a catalog or a profile tailoring one or more catalogs (by way of profile resolution). An SSP permits a single baseline to be imported for reference. A "referential constraint" is a constraint ensuring unbroken, unambiguous referencing or linking, over and above other applicable constraints such as lexical form (of UUID values etc.).
By "Same SSP" is meant the SSP instance as a parsed object, presuming a valid system-security-plan root.
Implicit or follow-on questions include
- how are components referenced, and specifically components described in other OSCAL resources not the SSP instance itself?
- more generally, what does the document space (across which links are expected to traverse) consist of and how is it determined?
- how exactly are
export/providedandexport/responsibilityexpected to work?
@brian-ruf may be able to provide insight or useful background on the relations intended.
Also, this information should feed into tutorials (attn @Rene2mt).
Sample documents with illustrations would ideally follow. But we can start by aligning the docs and tools to actually test and implement these relations.