Check that all parties have names

[aj-stein-gsa]

Constraint Task

As a digital authorization package maintainer, to know that I have identified all parties with a name that documents and automation can refer to in reporting, I need a check that any party has a name.

Intended Outcome

Goal

In core OSCAL, the party name is optional, but we will want parties to have a name defined for reporting in platform automation.

Syntax

Create an expect that a party/@name is defined for a given party with an expect constraint (id="party-name" and level="ERROR")

Syntax Type

This is required core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

/(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)/metadata/party/name

Purpose of the OSCAL Content

Automation will need the name in many cases to report information, warnings, or errors in place of UUID.

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

[aj-stein-gsa]

@wandmagic, I reviewed the referenced documentation on the website, the docs don't explicitly say party/name is required. Can you PR and update that please so we can move to "ready to ship"?

[aj-stein-gsa]

#112 was not reviewed and merged, so this issue is technically not ready to ship yet.