Profile Resolution: Support control identifier prefix/suffix when importing catalog controls.

[Compton-US]

User Story:

As an OSCAL implementer, during Profile Resolution, I would like to optionally concatenate a prefix or suffix to all IDs that are imported from a catalog/profile. This would be useful when control IDs are known to collide, or in cases where bulk imports of controls could result in unintended collisions.

Goals:

In the OSCAL draft specification (d2e438), under Mapping Controls, the following mapping option appears to be supported:

        {
          "href": "#FedRAMP_rev4_MODERATE-baseline_profile.json",
          "include-controls": [
            {
              "with-ids": [
                "ac-6.9",
                "ac-6.10",
                "ac-7",
                "ac-8"
              ]
            }
          ],
          "mapping": {
            "controls": [
              {
                "from": "ac-6.9",
                "to": "fedramp-ac-6.9"
              },
              {
                "from": "ac-6.10",
                "to": "fedramp-ac-6.10"
              },
              {
                "from": "ac-7",
                "to": "fedramp-ac-7"
              },
              {
                "from": "ac-8",
                "to": "fedramp-ac-8"
              }
            ] 
          }
        }

Supporting a prefix or suffix mapping directive would allow for a string to be applied to all imported control identifiers, and simplify the import. It might look similar to:

        {
          "href": "#FedRAMP_rev4_MODERATE-baseline_profile.json",
          "include-controls": [
            {
              "with-ids": [
                "ac-6.9",
                "ac-6.10",
                "ac-7",
                "ac-8"
              ]
            }
          ],
          "mapping": {
            "with-prefix": "fedramp-" 
          }
        }

Additionally, a with-suffix property could support adding the string at the end of identifiers depending on the needs of the user.

This capability would be particularly useful for include-all and pattern matched controls, since explicitly defining from and to for each identifier would no longer be required.

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.

[david-waltermire]

This relates to issues https://github.com/usnistgov/OSCAL/issues/538 https://github.com/usnistgov/OSCAL/issues/843 https://github.com/usnistgov/OSCAL/discussions/1115. This also relates to PR #1196. Perhaps this could be added to that PR?

[Compton-US]

Concept after working with @david-waltermire-nist :

                {
                    "imports": [
                        {
                            "href": "#FedRAMP_rev4_MODERATE-baseline_profile.json",
                            "include-controls": [
                            {
                                "with-ids": [
                                "ac-6.9",
                                "ac-6.10",
                                "ac-7",
                                "ac-8"
                                ]
                            }
                            ],
                            "identifier-reassignment": {
                                "with-prefix": "prefixA-",
                                "with-suffix": "-suffixA",
                                "controls": {
                                    "with-prefix": "prefixB-",
                                    "with-suffix": "-suffixB",
                                    "reassignments": [
                                        {
                                            "from": "ac-6.9",
                                            "to": "ac-6.9-new"
                                        }
                                    ]
                                }
                                // ac-6.9 -> prefixA-prefixB-ac-6.9-new-suffixB-suffixA
                                // ac-6.10 -> prefixA-prefixB-ac-6.10-suffixB-suffixA
                                // ac-7 -> prefixA-prefixB-ac-7-suffixB-suffixA
                                // ac-8 -> prefixA-prefixB-ac-8-suffixB-suffixA
                            }
                        },