Clarification of link semantics in SSP model

[wendellpiez]

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/provided and export/responsibility expected 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.

[aj-stein-nist]

I know Brian and Rene are more knowledgeable here, but re "same SSP" for thing like role and @id, Same SSP might not work across the board because of leveraged authorizations, no? In the updated presentation around them, you might need to cross-reference the leveraged system like slides 9-13 suggests.

That's off the top of my head, @wendellpiez, but I am sure there are other bits I have not thought deeply about. :-)

[wendellpiez]

Indeed, where it says "same SSP" is probably where the table has it most often wrong at present.

At this point I think we know the boundary is not the document; effectively this seeks clarification on what else is inside the boundary and how we find it (what mechanisms besides import are we using). In some places we may (also) wish to leave it up to an application to determine (but that should be explicit).

[wendellpiez]

@aj-stein-nist it occurs to me to add that to the extent the specs here are still soft or missing, the issue also dovetails with larger questions we have also been looking at. For example, whatever mechanism for linking among documents is provided for, it must be robust in the face of problems like an XML representation of a profile making reference to a catalog in JSON, because it was produced from a JSON profile and retained its link. (Yes! your friend the resource mapping problem.) This may be obvious but I note it for the sake of the record (and there are other examples and potential requirements I could add).

Partly with this in view, the goal for this issue is not actually to solve the larger problems, but just to capture the intended semantics of the v1 SSP object types such that things make sense and hang together, before we open up the next set of questions at the more general level. Fortunately since there are already techs that support resource mapping (such as OASIS XML Catalog or heck old W3C XLink) for us to emulate, borrow from or use, we shouldn't have to start from zero when we get to that point.

This is part of the reason why I frame the exercise as "let's complete and correct this table" first, because I know there are sleeping dogs underneath it.

[aj-stein-nist]

@aj-stein-nist it occurs to me to add that to the extent the specs here are still soft or missing, the issue also dovetails with larger questions we have also been looking at. For example, whatever mechanism for linking among documents is provided for, it must be robust in the face of problems like an XML representation of a profile making reference to a catalog in JSON, because it was produced from a JSON profile and retained its link. (Yes! your friend the resource mapping problem.) This may be obvious but I note it for the sake of the record (and there are other examples and potential requirements I could add).

Sure thing, I totally sympathize with that point. I only pointed it out re the "target scope" column which explain this in terms of one OSCAL model and its document instance (not JSON/YAML/XML), and in some cases it can be more more than one instance of a particular model.

I want to stay on topic. :-)

Partly with this in view, the goal for this issue is not actually to solve the larger problems, but just to capture the intended semantics of the v1 SSP object types such that things make sense and hang together, before we open up the next set of questions at the more general level. Fortunately since there are already techs that support resource mapping (such as OASIS XML Catalog or heck old W3C XLink) for us to emulate, borrow from or use, we shouldn't have to start from zero when we get to that point.

This is part of the reason why I frame the exercise as "let's complete and correct this table" first, because I know there are sleeping dogs underneath it.

Sure, understood. I am not sure I can help quite like Brian or Rene, but I happened to work alongside them with similar data (pre-OSCAL). If you do not hear back from them, let me know and I will pitch in how I can.

I am talking about the table for now, not much more complex stuff. I pointed leveraged authorizations (you already hint components) because document instances of those models can exist outside the same document in some or all cases, and very frustrating to deal with.

During previous work, in terms of components and things like attachments, I remember this came with attachment ID cross-refs (in 18F/fedramp-automation#106, see comments in code review here). @GaryGapinski will remember other ambiguities there too, it led me to reprioritize a bunch of work due to complexity around this. It is worth focusing and can become challenging, hence I volunteer to pitch in as needed later. Let me know.

[Rene2mt]

Here's a review of the SSP's identifier references and proposed constraints (see https://hackmd.io/@UE-2CUI2SlGqZQtexK6f3A/r1gsBPfl9 )

[rgauss]

Is this the appropriate issue to also clarify how SSPs can reference components in OSCAL Component Definitions?

(I didn't see that in the SSP Model Link Semantics page)

[david-waltermire]

@Rene2mt Love the work in the hackmd. Perhaps we can add this content to the SSP concepts page? Would you please submit a PR with the changes to this page against the release-1-0 branch?

[david-waltermire]

Is this the appropriate issue to also clarify how SSPs can reference components in OSCAL Component Definitions?

(I didn't see that in the SSP Model Link Semantics page)

I believe your question is related to #1078. Yes, the title on this issue is a bit misleading.