Spec-Conformant Profile Resolution Tools Should Use Patch OSCAL Version, not Only Minor

[aj-stein-nist]

Describe the bug

As an OSCAL tool developer implementing a profile resolution tool, in order to make the most usable tool for industry adoption, I want to conform with the profile resolution standard with minimal effort and use the explicitly set OSCAL version number in the profile(s) (patch version), and not have to process OSCAL version further to determine and emit the minor version in the resolved catalog.

Who is the bug affecting?

OSCAL tool developers writing OSCAL profile resolver tools.

What is affected by this bug?

Profile resolution that conforms to the current draft specification.

When does this occur?

Consistently when interpreting and implementing against the current specification.

How do we replicate the issue?

1. Review the profile resolution spec.
2. Implement code to match.

Expected behavior (i.e. solution)

The current draft of the profile resolution spec states resolution MUST process files and use the minor version.

The value of metadata:oscal-version in the target MUST be set with a string that identifies the version of OSCAL used by this tool to resolve the profile (ex. 1.0.0). This value MUST be determined by compiling the oscal-versions from each imported document and the source profile, and taking the most recent minor version. If this version is more recent than what the resolution tool is using, then the value of oscal-version MUST be the version that the tool used internally. If any of the above OSCAL versions (imported document versions, source profile version, tool version) are of a different major version (the first digit differs), the tool SHOULD provide an error and cease processing.

Per discussion with @david-waltermire-nist, the specification ought to require the patch version from documents and not parse it.

Other Comments

N/A

[wendellpiez]

Our current profile resolver (in develop) punts on this, writing out "TODO: Not implemented yet".

We need clarification of the requirements here so we can implement the correct handling.

cc @david-waltermire-nist @aj-stein-nist @galtm

[david-waltermire]

Parsing versions is going to be difficult for tools to do, even if OSCAL uses semantic versions.

Perhaps a safe way to handle this is to:

1. Require that the profile's oscal-version is always used as the resolved catalog's oscal-version
2. Optionally, allow tools to verify that imported resolved catalogs have a version that is less than or equal to the value from 1, and report a fatal processing error when this is not the case.

Is this reasonable?

[wendellpiez]

👍 Let's unit test as well.

[wendellpiez]

Suggest replacing the problematic text (cited above) with the following:

The value of metadata:oscal-version in the target MUST be set to the value of the corresponding object (oscal-version) in the immediate (top-level) profile source.

If, in processing, a resolver encounters a source profile or catalog whose stated oscal-version denotes a version after the oscal-version of the catalog, the resolver MAY report a fatal processing error and stop processing (or fail to deliver outputs). "After" is defined according to the rules of Semantic Versioning 2.0, in which 1.0.1 is after 1.0.1-draft.

Question: should the MAY behavior in the second line be the normative default behavior, or simply an option? (Presumably, emitting a warning is also an option.) Comments @david-waltermire-nist @aj-stein-nist @galtm ?

[david-waltermire]

@galtm Can you work on implementing the behavior above in the XSLT profile resolver?

@wendellpiez will create a top-level test for this.

[galtm]

@galtm Can you work on implementing the behavior above in the XSLT profile resolver?

@david-waltermire-nist : Yes. Feel free to create an issue and assign it to me.

[galtm]

@galtm Can you work on implementing the behavior above in the XSLT profile resolver?

Please see #1420

[wendellpiez]

We have code to merge but we have to circle back to complete work on unit tests (for this, and merging altogether).

See #1313.