Some UUIDs are not required where they should be

[david-waltermire]

Describe the bug

This issue was brought up on the OSCAL community Gitter.

After reviewing the associated Metaschema files, the following objects do not require a UUID be provided. This list includes only objects where a UUID is declared and excludes entries that reference a UUID declared elsewhere. The catalog and profile models were also excluded from this list, since changing these will break a good deal of existing content.

All of these objects probably should have had a required UUID in the 1.0 release.

• /component-definition/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /system-security-plan/system-implementation/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /system-security-plan/system-characteristics/system-information/information-types/uuid - Information Type Universally Unique Identifier
• /assessment-plan/terms-and-conditions/parts/uuid - Part Identifier
• /assessment-plan/local-definitions/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /assessment-plan/assessment-assets/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /assessment-results/results/attestations/parts/uuid - Part Identifier
• /assessment-results/results/local-definitions/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /assessment-results/results/local-definitions/assessment-assets/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /plan-of-action-and-milestones/local-definitions/components/protocols/uuid - Service Protocol Information Universally Unique Identifier
• /plan-of-action-and-milestones/poam-items/uuid - POA&M Item Universally Unique Identifier
• All property instances

Question: Which of these should be required? Is it worth making a compatibility-breaking bug fix to update these?

Who is the bug affecting?

Tools and users producing OSCAL assessment plan, assessment results, and plan of action and milestone models.

What is affected by this bug?

Uses of the OSCAL assessment plan, assessment results, and plan of action and milestone models where there is a need to reference the associated concept by UUID.

Expected behavior (i.e. solution)

These fields could be updated to require a UUID. There would need to be community consensus that this is a bug, since this would result in backwards compatibility breaking changes. More discussion is needed before moving forward with including this in the OSCAL 1.0.1 or later patch release.

[david-waltermire]

This issue was discussed on the 10/21/2020 Lunch with the Devs. We explored the possibility of doing one of the following:

1. Update a subset of these to make the UUID required as part of a patch release (i.e., 1.0.1). This would be a backwards compatibility breaking change that would be made to correct this defect. It was suggested that the following might be considered for updating in this way:
   • /assessment-plan/terms-and-conditions/parts/uuid - Part Identifier
   • /assessment-results/results/attestations/parts/uuid - Part Identifier
   • /plan-of-action-and-milestones/poam-items/uuid - POA&M Item Universally Unique Identifier
2. Defer these changes to an OSCAL 2.0 release, where a backwards compatibility breaking change is expected. In the interim, a constraint with a warning that a UUID should be provided for all of these. Adding a constraint to 1.x would not break backwards compatibility and could be deployed in either a patch or minor release.

The discussion was split with between both solutions. There was concerns raised about the impact of option 1 to early adopters, which lead to a slight leaning towards option 2.

This issue will be kept open for a few days to allow community members to weigh in. If no new information is brought forward, then the intent is to pursue option 2.