Add responsible-party-is-person constraint

[Rene2mt]

Committer Notes

This PR adds responsible-party-is-person constraint, which checks that responsible-party assemblies with role-id set to certain values (e.g., "system-owner", "authorizing-official", "authorizing-official-poc", "system-poc-management", "system-poc-technical", "system-poc-other", and "information-system-security-officer") must reference a party of type "person".

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Have you added an explanation of what your changes do and why you'd like us to include them?
• If applicable, have all FedRAMP Documents Related to OSCAL Adoption affected by the changes in this issue have been updated?
• If applicable, does this PR reference the issue it addresses and explain how it addresses the issue?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

[Rene2mt]

Added issue GSA/automate.fedramp.gov#57 for required documentation updates.

[aj-stein-gsa]

Will possibly approve after rebase and merge once documentation for the referenced doc PR is complete.

In the meantime, rebase, please and thank you. 🙏

[Rene2mt]

Hey @aj-stein-gsa once I rebased, some of the validations were no longer passing due to modifications I had made to the ssp-all-INVALID.xml test content, so the latest commit rolled those changes back and created a separate test SSP for this new responsible-party-is-person constraint.

[aj-stein-gsa]

Minor, non-blocking: all good changes but should we show example content even in a negative test for roles we recently confirm should not be included in FR requirements?

Suggested change

	<responsible-party role-id="system-poc-management">
	<party-uuid>11111111-0000-4000-9000-000000000001</party-uuid>
	</responsible-party>
	<responsible-party role-id="system-poc-technical">
	<party-uuid>11111111-0000-4000-9000-000000000001</party-uuid>
	</responsible-party>
	<responsible-party role-id="system-poc-other">
	<party-uuid>11111111-0000-4000-9000-000000000001</party-uuid>
	</responsible-party>
	<responsible-party role-id="information-system-security-officer">
	<party-uuid>11111111-0000-4000-9000-000000000001</party-uuid>
	</responsible-party>

[Rene2mt]

Here's how interpreted the role requirements:

The following roles must be defined, and must have responsible-party with a party of type "person":

• system-owner
• authorizing-official-poc
• information-system-security-officer

The following roles are not required (are optional). But if they are specified, they should have responsible-party with a party of type "person":

• system-poc-management
• system-poc-technical
• system-poc-other

Note the 3 system-poc-* roles are considered optional (for now) because that information seems to have been removed from the latest legacy SSP template, however, this is very useful information.

[aj-stein-gsa]

Up to you, so you are saying you want to keep them?

[aj-stein-gsa]

If so we add the prop and end it?

[Rene2mt]

yep, lets keep the roles for now. will update this PR the constraint help prop today