Socialize solution for managing identifier clashes in OSCAL profiles

[david-waltermire]

User Story

As an OSCAL community member, I need to ensure that the solution identified in #1397 meets my needs.

The design needs to be socialized with the community, collecting feedback and adjusting the design accordingly.

This issue will develop consensus around a solution to address the following issues:

• #538 -> PR #1196
• #843
• #1327

Goals

• [ ] Review design approach and examples with the community and develop consensus on the way forward
• [ ] Create issues for any follow-on work
  • [ ] Any required Metaschema modifications based on the design.
  • [ ] Identify what changes need to be made to the profile resolution specification
  • [ ] Determine how and where to publish examples.
  • [ ] Updates to existing XSLT and Java profile resolvers.

Dependencies

None.

Acceptance Criteria

• [ ] Consensus is reached around the solution with the OSCAL community
• [ ] All required follow-on work is identified
• [ ] 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.

[aj-stein-nist]

@Compton-NIST tentatively commits, during interim backlog review, to consider presenting during a Model Review meeting at the end of October, or potentially in November in the subsequent sprint TBD.

[aj-stein-nist]

@Compton-NIST briefed on this issue and status. We need to bring this up in the next Model Engineering Meeting to close this item out. /cc @david-waltermire-nist

[Compton-US]

@aj-stein-nist just a note to add this to our current sprint. I need to read back through the associated changes, but should be able to present on the model meeting next week.

[aj-stein-nist]

@aj-stein-nist just a note to add this to our current sprint. I need to read back through the associated changes, but should be able to present on the model meeting next week.

Sounds good. I will add this to the sprint and you want me to pencil you into the agenda for the next Model Engineering Meeting?

[aj-stein-nist]

@Compton-NIST per your discussion in the weekly status meeting, is this now in progress? If so, let us know.

[Compton-US]

Change Notes

Related Issues

Develop a solution for managing identifier clashes in OSCAL Profiles

• https://github.com/usnistgov/OSCAL/issues/1397

In this first issue, a property was added to OSCAL to retain the original control identifier in the resolved profile. It was implemented as a non-breaking change.

<control class="SP800-53" id="au-6-low">
    <title>Audit Review, Analysis, and Reporting</title>
    <!-- Note the new identifier above. -->

    <prop ns="http://csrc.nist.gov/ns/oscal"
        name="source-identifier" 
        value="au-6"/>
    <!-- The new 'source-identifier' property. -->

    <!-- ... -->  
</control>
<control class="SP800-53" id="au-6">
    <title>Audit Review, Analysis, and Reporting</title>
    <!-- A potentially conflicting control with the original identifier. -->
    
    <!-- ... --> 
</control>

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

• https://github.com/usnistgov/OSCAL/issues/1327

---

Also, For Consideration

• Feedback suggested an alternative name (apply-prefix, apply-suffix)
• SHOULD THIS BE DONE? https://github.com/usnistgov/OSCAL/pull/1424#issuecomment-1235567759

---

In the second issue, support was added for prefixing or suffixing identifiers during profile resolution. This ability is supported in two ways:

1. At the context level, where the contexts are: role, control, group, parameter and part.

<define-assembly name="id-reassignment-context" scope="local">
    <formal-name>Identifier Reassignment Context</formal-name>
    <description>A set of rules for reassigning identifier for a specific type of object.</description>
    <model>
          <field ref="with-prefix"/>
          <field ref="with-suffix"/>
          <define-assembly name="reassignment" max-occurs="unbounded">
                <formal-name>Identifier Reassignment</formal-name>
                <description>A specific rule to reassign the identifier for an object matching the `from` to the new identifier indicated by to the `to`.</description>
                <group-as name="reassignments" in-json="ARRAY"/>
                <define-flag name="from" as-type="token" required="yes">
                      <formal-name>From Identifier</formal-name>
                      <description>The identifier value of an object that is to remapped to a new value.</description>
                </define-flag>
                <define-flag name="to" as-type="token" required="yes">
                      <formal-name>To Identifier</formal-name>
                      <description>A new valid identifier value for an object that is to be remapped.</description>
                </define-flag>
          </define-assembly>
    </model>
</define-assembly>

2. At the identifier-reassignment level, and is applicable to all of the contexts after that level of identifier changes have taken place.

<define-assembly name="identifier-reassignment">
    <formal-name>Mapping</formal-name>
    <description>Maps objects to new ID values</description>
    <model>
          <field ref="with-prefix"/>
          <field ref="with-suffix"/>
          <assembly ref="id-reassignment-context">
                <formal-name>Role Identifier Reassignment Entry</formal-name>
                <description>A set of rules for reassigning role identifiers.</description>
                <use-name>role</use-name>
          </assembly>
          <assembly ref="id-reassignment-context">
                <formal-name>Control Identifier Reassignment Entry</formal-name>
                <description>A set of rules for reassigning control identifiers.</description>
                <use-name>control</use-name>
          </assembly>
          <assembly ref="id-reassignment-context">
                <formal-name>Group Identifier Reassignment Entry</formal-name>
                <description>A set of rules for reassigning group identifiers.</description>
                <use-name>group</use-name>
          </assembly>
          <assembly ref="id-reassignment-context">
                <formal-name>Parameter Identifier Reassignment Entry</formal-name>
                <description>A set of rules for reassigning parameter identifiers.</description>
                <use-name>parameter</use-name>
          </assembly>
          <assembly ref="id-reassignment-context">
                <formal-name>Part Identifier Reassignment Entry</formal-name>
                <description>A set of rules for reassigning part identifiers.</description>
                <use-name>part</use-name>
          </assembly>
    </model>
</define-assembly>

Example 1: Everything, All at Once

 
{
    "imports": [
        {
            "href": "#FedRAMP_rev4_MODERATE-baseline_profile.json",
            "include-controls": [
            {
                "with-ids": [
                "ac-6.9",
                "ac-6.10",
                "ac-7",
                "ac-8"
                ]
            }
            ],
            "identifier-reassignment": {
                // Final "All Contexts" Result:
                // ac-6.9 -> ALLPRE-prectl-ac-6.9-new-sufctl-ALLSUF
                // ac-6.10 -> ALLPRE-prectl-ac-6.10-sufctl-ALLSUF
                // ac-7 -> ALLPRE-prectl-ac-7-sufctl-ALLSUF
                // ac-8 -> ALLPRE-prectl-ac-8-sufctl-ALLSUF
                "with-prefix": "ALLPRE-",
                "with-suffix": "-ALLSUF",
                
                "controls": {
                    // Intermediate "Single Context" Result:
                    // ac-6.9 -> prectl-ac-6.9-new-sufctl
                    // ac-6.10 -> prectl-ac-6.10-sufctl
                    // ac-7 -> prectl-ac-7-sufctl
                    // ac-8 -> prectl-ac-8-sufctl
                    "with-prefix": "prectl-",
                    "with-suffix": "-sufctl",
                    
                    "reassignments": [
                        {
                            "from": "ac-6.9",
                            "to": "ac-6.9-new"
                        }
                    ]
                }
                
            }
        }
    ]
}

Example 2: Simplified Profile and Catalog Result

Profile Sample with a Suffix for Controls

 
{
    "imports": [
        {
            "href": "#FedRAMP_rev4_MODERATE-baseline_profile.json",
            "include-controls": [
            {
                "with-ids": [
                "ac-6.9",
                "ac-6.10",
                "ac-7",
                "ac-8"
                ]
            }
            ],
            "identifier-reassignment": {
                "controls": {
                    "with-suffix": "-Moderate",
                }
                
            }
        }
    ]
}

// Result:
// ac-6.9 -> ac-6.9-Moderate
// ac-6.10 -> ac-6.10-Moderate
// ac-7 -> ac-7-Moderate
// ac-8 -> ac-8-Moderate

Catalog Control Identifier Sample

<control class="SP800-53" id="ac-6.9-Moderate">
    <title>Audit Review, Analysis, and Reporting</title>
    <!-- Note the new identifier above. -->

    <prop ns="http://csrc.nist.gov/ns/oscal"
        name="source-identifier" 
        value="ac-6.9"/>
    <!-- The new 'source-identifier' property. -->

    <!-- ... -->  
</control>

[aj-stein-nist]

@Compton-NIST thanks for the update. I presume we will talk about aligning the status update with completed steps in the goals and AC, and then plan work intended for Sprint 64?

[aj-stein-nist]

Well, we already have a full on sprint and I am not sure we can reach AC and goals for this in the context of Sprint 64 anyway. Thanks for your work on this in Sprint 63, I will remove the follow on work for Sprint 65 at least to discuss in sprint planning, then we decide to include or exclude.

[aj-stein-nist]

There was some confusion about Model Engineering Meeting and whether that is happening on the 9th when I am out on leave. Need to confirm that. This may potentially move back into Sprint 64 tomorrow.

[Compton-US]

Presented today at Model Engineering Meeting. Attaching the slides relevant to this ticket. There was some debate from the community around this, and I encouraged feedback on this issue. Recommend leaving open until the end of the sprint (at least), in case anyone would like to add comments.

1398 Slides from March 9 Model Engineering.pdf

[aj-stein-nist]

Presented today at Model Engineering Meeting. Attaching the slides relevant to this ticket. There was some debate from the community around this, and I encouraged feedback on this issue. Recommend leaving open until the end of the sprint (at least), in case anyone would like to add comments.

1398 Slides from March 9 Model Engineering.pdf

Thanks for the update, @Compton-NIST. Barring any feedback tomorrow (the next sprint begins on Thursday), I will review with you and the team and move to make a decision on merging the work or leaving as-is in a feature branch during sprint review and/or sprint planning for Sprint 65. Thanks.

[aj-stein-nist]

@Compton-NIST, I am going to rebase the feature branch and check for what's in the branch now and get an accurate delta before we weigh in on next steps, thanks for your brief during today's sprint review.

[aj-stein-nist]

@Compton-NIST, I did a quick rebase later in the afternoon and there and I can only see in this PR, modulo what is already in develop and some other cruft slimmed down, the changes for identifier clash handling.

https://github.com/usnistgov/OSCAL/compare/develop...feature-profile-import-identifier-handling-backup?expand=1

Having reviewed that and my review of the prior model engineering meeting session's notes, I am ok keeping the feature branch as-is based on community feedback, not merging it into develop, and interpreting the consensus as "it sounds interesting, but we in the community do not want it to be a mandatory feature we must integrate to be minimally conformant with an soon-to-be enhanced draft profile resolution standard" position.

If you feel similarly, I will close this out for this sprint, leave the branch as-is and we can choose to revive it based when there is more community demand with a real-world business case for it. (I did reach out to community members I had believed were originally in need of this feature, and apologies, it does seem I was mistaken and that is not the case.)

Let me know what you think and I will move accordingly.

[Compton-US]

@aj-stein-nist Close it. I've seen no feedback supporting it at this time. If there is community feedback at a later date, we can revisit.