Check components have a valid 800-60 information type

[aj-stein-gsa]

Constraint Task

As a digital authorization package maintainer,
in order to ensure that I have properly described the components of my system in the SSP and explain how each of those components stores and processes certain types of information that is sufficiently clear for reviewers and prevent an unnecessary pass-back,
I would like a check that ensures that each SSP component declares its information type per the SP 800-60 categorizations required by FedRAMP.

NOTE: this task depends on the completion of #890.

Intended Outcome

Goal

Check the SP 800-60 information types for the different components of a SSP.

Syntax

Update the existing allowed-values constraint to check for components have a prop[@name="information-type"] with the appropriate SP 800-63 values in information-type-800-60-v2r1.

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

//component[@type='system' or @type='service' or (@type='software' and ./prop[@asset-type='cli'])]/prop[@name='information-type'][@ns='http://fedramp.gov/ns/oscal']

Purpose of the OSCAL Content

No response

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

Updated issue dependency.

[aj-stein-gsa]

@brian-ruf, a few things.

1. Given I quickly looked and cannot find in the FedRAMP Extensions model/data find a pre-existing prop[@name="data-type"], can we rename it prop[@name="information-type"] to align with relevant model data upstream in OSCAL 1.1.2?
2. Can we double-check the Metapath recommendation above? The prop[@asset-type="cli"] I am less sure about, so I will not move this one to ready.

[aj-stein-gsa]

@brian-ruf I assigned to you for now so we can further refine this requirements and make sure this issue is ready to work?

[aj-stein-gsa]

Also for consideration, do we want to cross-reference information-type by UUID? Two community members brought this up with a feedback issue in #576. It may be worth considering and reviewing and revising the requirements for this constraint.

[aj-stein-gsa]

This appears to be a duplicate of #898 that will be resolved by #911. Closing it because I realized quick refinement that it is a duple.