Describe the bug

Profile resolution offers no directive for handling group ID collision and the specification is silent on this issue. This is relevant when the merge directive is as-is, where the Profile Resolution Specification states:

Note that "as-is" also requires implementations to replicate any use of the group element.

Profile syntax offers directives for handling control ID collision, but no syntax nor specification guidance for how to handle groups from two or more catalogs that use the same ID.

Currently the specification requires that both groups are brought into the resulting resolved profile catalog when the as-is directive is used in order to ensure the controls from those groups in each catalog are included. This produces two different groups with different controls, but the same group ID, which makes the resulting catalog invalid due to the uniqueness constraint on group IDs.

Who is the bug affecting

Anyone who needs to handle catalogs from two or more sources that use the same group ID for different control groups.

What is affected by this bug

Metaschema

How do we replicate this issue

1. Create two catalogs with different controls and control groupings, but use the same group ID in both catalogs.
2. Create a profile that imports both catalogs, include all controls, and use the as-is merge directive.
3. Use the OSCAL-CLI or other profile resolution tool to produce a resolved profile catalog.
4. Validate the resolved profile catalog and note the duplicate group ID error.

Expected behavior (i.e. solution)

• Minimally, the specification should be explicit about the correct processing of profiles when duplicate groups are discovered.
• Profile merge syntax should be re-evaluated to determine if it is suitable for handling conflicts beyond just control IDs.

Other comments

No response

Revisions

No response