Profile: identifier specificity when multiple catalogs are imported

[GaryGapinski]

(Edited to correct errors and deficiencies.)

The <set-parameter> element of a Profile <modify> has a param-id attribute which presumably has as its target a Catalog <control> <param> id attribute.

(Profiles can also import Profiles but such imported Profiles would lack actual <param> targets making <set-parameter> targeting left to choose between <control> <param> id and <set-parameter>s as targets. Targeting parameters in imported Profiles appears to have some ambiguity.)

How would duplicate parameter IDs in multiple imported Catalogs be differentiated? The other <set-parameter> attributes and subordinate elements do not appear to support such distinction.

Consider as an example a Profile which imports two Catalogs, each of which has controls with a single parameter each and the two Catalog authors chose to use a simple naming schema which included the control id suffix with a simple "-p". Or perhaps a simple "C#p#" scheme using control ordinal number and parameter ordinal number in document order. Or perhaps a Profile combining (importing) the best or worst of SP 800-53r4 and SP 800-53r5 Catalogs.

(I presume, perhaps wrongly, that there was an intent to keep all id attributes with a Catalog document to be unique regardless of parent element type. The schema does not appear to require this. The same identifier qualification nature uncertainty arises in other OSCAL venues whenever inter-document references are involved. They ("id" attributes) are NCNames but not xs:ID or xs:IDREF. Additionally, it is not possible to extend the constraint of IDREF any farther than within a single document. Such constraints could be levied using Schematron if and when the constraints were agreed upon.)

The Catalog schema asserts that a parameter id is "A unique identifier for a specific parameter instance. This identifier's uniqueness is document scoped and is intended to be consistent for the same parameter across minor revisions of the document." and uses the type xs:NCName. Document scope is no guarantee of uniqueness among documents.

Perhaps a <set-parameter> should identify the target imported document in order to

• distinguish among parameters with identical identifiers
• avoid awkward levies on identifier syntax hoping to compel cosmic singularity

but that might be quite tedious when numerous parameters are targets of modification. The same would be necessary for <alter>.

An alternative would make <modify> a child of <import> making the modification reference unambiguous and obviating the need to additionally qualify the target of a <set-parameter>. The cardinality of <modify> would no longer be {0,1} but that cardinality seems a tad arbitrary in any case.

Making <modify> a child of <import> appears to be a desirable alteration as the alteration target would be unambiguous.

Related, I have just read https://pages.nist.gov/OSCAL/documentation/processing/profile-resolution/ and it may or may not address the previous observations. It does seem to rely on (elaborate) procedural rather than functional definition. The latter would be preferable.

[iMichaela]

@GaryGapinski In your proposed solution of making a child of , how would you then resolve a situation when Control C1 of Catalog K-A is almost identical to Control Cx of catalog K-B, and the profile's author decides to create Profile P-AB with a control C1x that combines C1 and Cx. It is doable by (ing) first C1 from K-A and manually (ing) C1 to make it C1x and then not Cx when (ing) K-B. The author will get the desired result but it will not preserve the dual traceability. The fact the C1x cannot be traced to K-B even though C1x is derived from Cx as well as much as it is derived from C1. Profile resolution approach aims to address such situations by allowing the author to have in C1x to both. Maybe you have a solution I do not see.

[GaryGapinski]

@iMichaela I have not yet progressed to a point at which I can understand your example of control synthesis (one control manufactured from two accompanied by control provenance). I will try to get to that point at some time over the next week or so. An example with XML for K-A, K-B, and P-AB would help.

What I observe at this time is that

• A Catalog can have only a single <metadata> element and thus multiple-Catalog import provenance and the related metadata seems a difficult fit unless one adorns imported (and possibly modified) <control>s with provenance information.
• <set-parameter> lacks specificity when multiple-Catalog imports occur.

Were <modify> to be a child of <import>, would that in some way compromise or diminish what is currently intended as <modify> capabilities?

Here is an example of identifier collision (both control and param). Maintaining <set-parameter> and <alter> relative to <import> would allow them to be specific to an import; however, the resolution must still contend with identifier collisions. Only alteration of identifiers can remedy such collisions when the result of a resolution is eventually subject to inter-document references (such as being cast as an XML document).

catalog-1.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://raw.githubusercontent.com/usnistgov/OSCAL/master/xml/schema/oscal_catalog_schema.xsd" schematypens="http://www.w3.org/2001/XMLSchema" title="OSCAL Catalog schema"?>
<catalog xmlns="http://csrc.nist.gov/ns/oscal/1.0" uuid="fafe5776-b69f-41ea-a5cf-2192bdc4242b">
    <metadata>
        <title>catalog 1</title>
        <last-modified>2021-03-09T13:25:13Z</last-modified>
        <version>one</version>
        <oscal-version>1.0.0-rc1</oscal-version>
    </metadata>
    <control id="control-1">
        <title>Control one</title>
        <param id="param-1">
            <label>organization-defined time</label>
        </param>
        <part name="statement" id="statement-1">
            <p>Open the perimeter gate <insert param-id="param-1"/>:</p>
        </part>
    </control>
</catalog>

catalog-2.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://raw.githubusercontent.com/usnistgov/OSCAL/master/xml/schema/oscal_catalog_schema.xsd" schematypens="http://www.w3.org/2001/XMLSchema" title="OSCAL Catalog schema"?>
<catalog xmlns="http://csrc.nist.gov/ns/oscal/1.0" uuid="02f25130-874b-4200-ab6c-eafa7c2a8b2d">
    <metadata>
        <title>Catalog 2</title>
        <last-modified>2021-03-09T14:22:54Z</last-modified>
        <version>one</version>
        <oscal-version>1.0.0-rc1</oscal-version>
    </metadata>
    <control id="control-1">
        <title>Control one</title>
        <param id="param-1">
            <label>organization-defined time</label>
        </param>
        <part name="statement" id="statement-1">
            <p>Close the perimeter gate <insert param-id="param-1"/>:</p>
        </part>
    </control>
</catalog>

profile-1.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://raw.githubusercontent.com/usnistgov/OSCAL/master/xml/schema/oscal_profile_schema.xsd" schematypens="http://www.w3.org/2001/XMLSchema" title="OSCAL Profile schema"?>
<profile xmlns="http://csrc.nist.gov/ns/oscal/1.0" uuid="ee0d257c-a1c8-4dc2-8ac1-be25c466b4d5">
    <metadata>
        <title>Profile 1</title>
        <last-modified>2021-03-09T14:38:01Z</last-modified>
        <version>test</version>
        <oscal-version>1.0.0-rc1</oscal-version>
    </metadata>
    <import href="catalog-1.xml">
        <include>
            <all/>
        </include>
    </import>
    <import href="catalog-2.xml">
        <include>
            <all/>
        </include>
    </import>
    <modify>
        <set-parameter param-id="param-1">
            <!-- This parameter setting should target catalog-1 control-1 param-1 -->
            <value>at 0600 local time</value>
        </set-parameter>
        <set-parameter param-id="param-1">
            <!-- This parameter setting should target catalog-2 control-1 param-1 -->
            <value>at 2200 local time</value>
        </set-parameter>
    </modify>
</profile>

[david-waltermire]

I believe this relates to #538.

[david-waltermire]

Like issue #538, addressing this will involve adding new features to the profile model. Given that we are freezing new features in preparation of the 1.0.0 release, we should address this in OSCAL 1.1.

One way of addressing this is to support control and parameter identifier remapping within the context of a given import. This could be handled through a mapping declaration in the import statement. This could drive remapping of the ids and any references to these ids in the resulting resolved profile.

[fkautz]

Would it be possible to perhaps add some form of identifier that the profile creator can set?

    <import href="catalog-1.xml" name="cat-1">
        <include>
            <all/>
        </include>
    </import>
    <import href="catalog-2.xml" name="cat-2">
        <include>
            <all/>
        </include>
    </import>

    <modify>
        <set-parameter param-id="cat-1.param-1">
            <!-- This parameter setting should target catalog-1 control-1 param-1 -->
            <value>at 0600 local time</value>
        </set-parameter>
        <set-parameter param-id="cat-2.param-1">
            <!-- This parameter setting should target catalog-2 control-1 param-1 -->
            <value>at 2200 local time</value>
        </set-parameter>
    </modify>

The above approach would also allow for nesting and referencing in documents that consume the profile.

e.g. prof-3.cat-2.param-1

[wendellpiez]

@GaryGapinski The problem of clashing or conflicting parameters by ID is real (related to good-old #538) but the example given here doesn't do it justice. Assuming that both upstream parameters (that is, from both catalog sources) would be propagated into the result then the resolution result would be invalid by virtue of their ID clash. This is actually a good thing and way better than throwing them away but doesn't speak to your actual concern, namely clarification in the spec as to proper and correct behavior.

In any case I think there is enough complexity here that we probably need unit tests to untie it all (see #1087). It is reasonable to think there are several kinds of overloading/clashing/ambiguity that we can detect and help avoid, including this one.

wrt above, @fkautz interesting idea. Thanks for contributing to the discussion (while we ponder the options).

Let's work out expectations and unit test under #1087.