Current Resolved Catalogs for SP 800-53B Rev5 Baselines Missing alt-identier props after Resolution

[aj-stein-nist]

Describe the bug

The FedRAMP Automation Team reported to us that the resolved catalogs based on the Low, Moderate, and High profiles to create NIST 800-53B Rev5 baselines made in the pipeline at commit 9abf4f1 following the merge of #90 do not include the alt-identifier, such these in the catalog with pre-800-53A content inclusion in the full catalog.

FedRAMP and others can and do rely on the cross-reference props to find the previous param names and use the resolved catalogs to derive their own Low/Moderate/High baselines.

It appears this has been "fixed" in the current develop branch as of usnistgov/OSCAL@ed1150a the alt-identifier props do get added, but that is not used for these releases yet. We can do RCA and figure if the fix is cherry-pickable or defer it to a release.

/cc @Rene2mt @volpet2014 @wendellpiez

Who is the bug affecting?

Developers generating derivative resolved catalogs from 800-53B Low/Moderate/High resolved catalogs.

What is affected by this bug?

Resulting resolved catalogs with proper control identifier data with parameter identifiers from 800-53 and 800-53A assessment parameter data.

When does this occur?

Consistently when using the current oscal-profile-RESOLVE.xsl in the main branch. The bug does not occur with oscal-profile-RESOLVE.xsl in the develop branch.

How do we replicate the issue?

See above in the previous section.

Expected behavior (i.e. solution)

The relevant props are included.

[aj-stein-nist]

Per discussion with @wendellpiez, the particular fix in develop that is already merged is usnistgov/OSCAL#1321 (specifically this change to props handling in the modify step of the XSLT resolver). We can decide to cherry pick or leave it for now, but FYI/FYE reporters of the original issue.

[aj-stein-nist]

This will get resolved when develop is merged to main and the next release of oscal-content and this will get unblocked, so I will mark this as "assigned to milestone."

[aj-stein-nist]

This is blocked by another issue, but AJ has decided to mark it urgent for Sprint 63.

[aj-stein-nist]

Those working on this ought need to collaborate with the team member(s) owning and working usnistgov/OSCAL#1434.

[aj-stein-nist]

Up for discussion: we need to make CI/CD more informative with error conditions. If not within scope of this issue, be sure to immediately create another issue and prioritize it.

[aj-stein-nist]

AJ will set aside time to work on this next week.

[aj-stein-nist]

AJ did not make time last week, @nikitawootten-nist and @wendellpiez and I need to discuss this early next week after I continue and finally resolve the CI/CD weirdness I am tracking from oscal-content->OSCAL->metaschema code processing issues in #116.