Modify the component-type Allowed Values List

[brian-ruf]

Constraint Task

Core OSCAL allows additional values beyond those defined by NIST for //component/@type. The FedRAMP PMO wanted to limit the list to only those values and implemented the component-type constraint.

In the course of analysis and re-modeling, at least two new component types have been introduced:

• external-client representing external workstations or servers acting as an API client, interacting with an API service offered by the SSP subject system.
• connection representing an internal connection between two or more components, such as an encrypted connection that must be documented in the Appendix Q, Cryptographic Modules, Data In Transit (DIT) Table.

The constraint must be expanded to allow these values.

Intended Outcome

• Allow "external-client" and "connection" component types.

Syntax Type

This is a mix of required, optional, and/or extended syntax.

Allowed Values

FedRAMP allowed values must be defined or verified.

Metapath(s) to Content

//component/@type

Purpose of the OSCAL Content

To allow component types that are required for proper modeling of a deployed system.

Dependencies

No response

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response