Component types in presentation of leveraged authorization do not exist in standards enumerated list of component types

[gregelin]

Describe the bug

A NIST presentation on component types includes SSP code examples that show component type as "leveraged-system" and other types that do not exist in the OSCAL 1.0.0 standard enumerated list of accepted values for component types.

Who is the bug affecting?

This bug effects all developers working with OSCAL, particularly vendors working to implement the code.

What is affected by this bug?

Contradictory examples between presentation/documentation and standard creates great confusion in organizations seeking to adopt OSCAL.

How do we replicate the issue?

Just cross reference the pages. See images below.

From code example on GitHub demonstrating leveraged authorizations.

OSCAL 1.0.0 list of component types

Acceptance Criteria

• Modify examples, specifically this one and others to use the correct component/@type.
• Update the presentation if applicable.
• If assigned developer(s) decide to, clarify wording in the documentation string for the model around "other side of interconnection"

[aj-stein-nist]

Good catch! FYI, the way the words are written in the constraint spec are determined by the Metaschema definition, and that references a shared entity that gets rendered into the form you show in the later screenshot and is de-referenced here for the final product with allow-other="yes". That means the list enumeration is not strict, and you are not limited to only things in that list. You can put other things too.

Doesn't mean adding it back isn't helpful, but not a major issue.

[david-waltermire]

We need to figure out which component types to add to the OSCAL component definition and SSP metaschemas. We can then make any updates to the related slides and examples.

[aj-stein-nist]

I am not sure I can track down which presentation it was/is (unless @gregelin wants to follow up in a comment), but for now we should at the very least change the example.

[gregelin]

@aj-stein-nist May have been one of these two presentations:

• https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf
• https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v2.pdf

[iMichaela]

@aj-stein-nist and @gregelin - the specification indicates the component type for a leveraged-authorization should be system. The simplest way to fix it, would be to update the presentation. But I wonder if you, @gregelin , see a need for a specific type leveraged-authorization vs the type system which would be an interconnected system in the security assessment automation process (for leveraging system, the ATO depends on the ATO of the leveraged system - see FedRAMP market place; for the interconnected system the control provided is deficient if the ATO of the interconnected system is not in good standing).
Also - where and how will the CRM/SSRM be used ? Will the SSRM be a SSRM component or it will simply be a leveraged-authorization component and the chosen solution here will fit the CRM/SSRM too? (food for thoughts, for @Compton-NIST and @nbg84 )

[aj-stein-nist]

The simplest way to fix it, would be to update the presentation.

That and aligning the examples. I can add updating the presentation to the AC. The other questions and comments are meaningful, they are just beyond the scope of this fix, right?

[gregelin]

@aj-stein-nist @iMichaela The simplest clarifying change that can be made to bring all content into alignment for the primary use case is seems the right choice. (I've been adopting a "Take the win," approach to things lately.)

FedRAMP Data Bites (Volpes) gave a presentation recently on leveraging systems and availability of leveraged SSP. Probably wise to confirm that OSCAL and FedRAMP presentations and materials are also well-aligned on the type. Important for closing this issue to not create new divergence.

I think additional types of leveraging is suitable for additional issue tickets and discussions. It is interesting to think about other configurations as per @vmangat observation in #1729. And I think the larger topic of CRM is a separate issue relating to complexity concerns that I mentioned in #1729. Important topics for separate research and discussion.

[aj-stein-nist]

This issue should be completed once the team reviews and the two connected PRs are merged. Setting this issue to "under review."