Leading zero's not consistent throught the OSCAL catalog

[Telos-sa]

Describe the bug

The introduction of padding zero's to match 5.1.1 has not been implemented in the following:

catalog[group][control][@id]
catalog[group][control][parameter][@id]
catalog[group][control][part][@id]

Who is the bug affecting?

Customers that are wishing to convert to OSCAL, customers still working through conversion from rev 4 to rev 5, GRC tools that create control catalogs for users are impacted by this change.

What is affected by this bug?

Change in how to programmatically map the rev 4 content to Rev 5. Inconsistent messaging between the OSCAL Catalog, the CPRT, and Control Catalog excel https://csrc.nist.gov/files/pubs/sp/800/53/r5/upd1/final/docs/sp800-53r5-control-catalog.xlsx
are creating confusion for which is the source of truth, what the structure should be, and how we should be developing our content.

When does this occur?

With the introduction of 5.1.1

How do we replicate the issue?

Review content from OSCAL elements path outlined above, to the CPRT, to the Control catalog.

CPRT (With leading Zero's)

OSCAL Catalog (No Leading Zero's)

XLSX Catalog (No leading Zero's)

Expected behavior (i.e. solution)

Consistent and clear messaging from OSCAL, to CPRT, to xlsx Catalog.

[iMichaela]

@Telos-sa - You are absolutely right, to avoid implementation issues for the implementers of OSCAL. The team discussed this issue at length, and concluded that the @id are just IDs, not capitalized either and not aiming to reflect the CPRT Control ID. The catalog had even before a prop/@name="labels" and prop/@value=[the CPTR Control ID]. Please see

 <prop name="label" class="sp800-53a" value="AC-01"/>

If the community considers the @id updates a positive improvement for them with no support issues, we can add those through a patch release.
@Telos-sa - please work with the community members to provide their feedback her. We are open to this alignment but had the community's interest at heart.

[Arminta-Jenkins-NIST]

At the 12/7 Triage Meeting: The team is concerned that changing the IDs to include leading 0s could break the implementation of current adopters, in particular FedRAMP that provides templates . We are seeking feedback from the community on replacing the labels of structure:

<prop name="label" value="IA-9"/>
<prop name="label" class="sp800-53a" value="IA-09"/>

with

<prop name="alt-identifier" class="sp800-53a" value="IA-09"/>
<prop name="alt-identifier" class="sp800-53a" value="IA-09"/>

Please provide feedback on the proposed approach no later than 12/08, EOB since the patch release with the bug fixed and official control identifier captured correctly is urgent.

[iMichaela]

the OSCAL IDs cannot be zero-padded due to backwards compatibility issues. PR #228 addressed it by adding prop/name="alt-identifier" to reflect the 800-53 v5.1.1 zero-padded IDs.