Cleanup ID to UUID Transition

[brian-ruf]

User Story:

After performing the transition from ID to UUID, a few details require additional attention. For example, the prop field and part and annotation assemblies still have ID flags instead of UUID flags; however, these are unusual cases where we deliberately want ID flags for control details in a catalog, yet may need to use these in other models where UUID is more appropriate.

There are also ID references that may not have been converted to UUID as intended. For example, in the SSP model the inventory-item/implemented-component still has a component-id flag instead of a component-uuid flag.

Goals:

Ensure the application of UUID is consistent and complete across all models.

Dependencies:

None; however, this relates to the following issues:

• Update IDs in backmatter references to use UUID #682, Milestone 3 Metaschema enhancements: uuid datatype; validation at root #678, Adding 'uuid' flag to objects in addition to 'id' flag? #676

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[brian-ruf]

I just noticed in the SSP model that leveraged-authorization still has an id instead of a uuid flag.

[brian-ruf]

prop, part, and annotation have id instead of uuid.
We need to decide whether we want to convert any or all of these to UUID.

part is the tricky one of the three since it is used in catalogs for control statement IDs, which we want to remain canonical.

I am unaware of any such conflict with prop and annotation; however, the ID field is currently optional and typically not used with prop and annotation. We previously established that anything with a UUID will require the UUID flag to always be present. I don't think that would be a bad thing, just an aspect we should consider when reaching a decision.

[brian-ruf]

In the SSP model, component had @id converted to @uuid; however, under /*/control-implementation/implemented-requirement/by-component, the @component-id flag did not get changed to @component-uuid.

[brian-ruf]

In a discussion with @david-waltermire-nist, we discussed that part would keep the optional @id flag in the catalog and profile layers, but receive the required @uuid flag in the assessment layers.

[brian-ruf]

In a discussion with @david-waltermire-nist and @wendellpiez, we have decided to change @id to @uuid for prop and annotation, but continue to allow that flag to be optional. This enables backward compatibility with existing files (where @id is typically not used), while bringing the addressability of these fields into alignment with all other non-canonical fields.

[brian-ruf]

Within the SSP model, the information-type assembly still has @id instead of @uuid. This assembly contains a separate information-type-id field with canonical references to specific information types, thus the above @id should be changed to @uuid.

[brian-ruf]

Within the SSP model, the component/responsible-role assembly has a party-uuid field with the JSON group-as name still set to party-ids instead of party-uuids.

[david-waltermire]

I am using the following XPATH to find potential issues:

//*[(@name='id' or ends-with(@name,'-id')) and not(@name=('role-id','control-id','statement-id'))]

Some issues might remain. @brianrufgsa I need your input on the results.