Profile parameter interpretation

[anweiss]

Currently, "Profile" parameter values are completely ambiguous. The schema also only allows simple text values (value = element value { text }). As such, it is left up to "Implementation" to interpret, parse and implement these parameter values. I'm curious if there's a way we can mitigate the level of effort that a system "Implementer" would have to put in to interpret these values by also allowing numeric types. This would simplify parsing of param values that can be easily represented numerically.

@wendellpiez, thoughts?

[anweiss]

Another scenario that comes to mind is when a "Profile" parameter augmentation references another "Profile" parameter as a comparison. For example, in the FedRAMP Moderate "profile", the parameter for subcontrol ID "ac.2.5" references control ID "ac.12" in that the value for "ac.2.5" must be a shorter timeframe than the parameter for "ac.12". In this case, it would be great if we could allow for a numeric condition here using some syntax that we define ... something like, # < ac.12 ... where the # represents the current control param value must be less-than the param value of ac.12.

[wendellpiez]

We have talked about wiring data typing constraints into the declarations model; presumably that could serve parameter values as well as property values. In the XML stack, we get some data types for free, such as strings, integers, URIs and (ISO-formatted) dates. We have also talked about constraints such as "the value must be an integer between 0 and 10 inclusive". So yes, there are definitely ways we could mitigate these issues for implementers - assuming that validation of lexical forms against these types can be performed before processing (and that there is handling defined for invalid data). However, we also know that in the real world, these guys can be peculiar and complicated, and while XSD has a "duration" data type, it doesn't have (for example) frequency or range of frequencies, such as "at least every six months". (And then there's the notation question.)

The second note describes co-occurrence constraints on the values of parameters assigned in the same profile (albeit conceivably in different 'import hierarchies' of the same profile). This is interesting. Making these work implies data typing (so we can deterministically compare values, for example), but also more.

The cheap/easy way to do either of these in XML is with a layer on top, for example a Schematron or XSLT that would perform the test and flag an error. However, that is effectively an implementation-level solution, which is what @anweiss is saying it would be nice not to need. I concur, if there's a 20% solution for 80% of the problem here, it might belong lower in the OSCAL stack. (Not that I'm against layering.) It might well be to support simple numbers, but not (yet) durations or frequencies.

FWIW, at present OSCAL declarations apply to (and work well with) OSCAL catalogs and with catalog-like artifacts (such as my "worksheets"), but not -- yet -- profiles. We will have to think about that too.

[anweiss]

Awesome! Yea, I'm less concerned about the type constraints we can implement and that are available in XSD/JSON schema and more interested in co-occurrence constraints on the parameter values where applicable.

[david-waltermire]

We will address this in the Implementation layer work (#92). Changes to the Catalog and Profile models will be needed at that time.,

[gregelin]

I very much agree with @anweiss statements. The current vagueness of parameters in 800-53 are obstacles to improved workflows. I also agree with @wendellpiez noteworthiness of "co-occurrence constraints on the values of parameters assigned in the same profile."

The 20% solution that provides 80% of the value could be an improved naming schema for the parameters. I've noted a need for unique naming of parameters as an additional acceptance criteria in #66

Since 800-53 catalog does not provide a machine-usable parameter naming schema, OSCAL needs a format for a "parameter key definition and translation index" which provides a common format for a rossetta stone for translating the the catalog's parameters up to a common structure and values back down again.

We can't control the quality of catalog's parameter structure. But we can always create a table that equates some path description to a parameter (e.g., AU-3>b>Selection) to an agreed upon key (e.g., AU-3.b.Selection).

If the protocol/structure for indexing the keys is part of the implementation standard, the following benefits follow:

• profiles can contain parameter values
• vendors and enterprises can programmatically maintain parameters across different catalogs and profiles from a single source
• recommended implementers need to only 1 interpreter for consuming parameters
• parameter type definition and rules like the ones @anweiss and @wendellpiez discuss can be maintained at both the profile and implementation layer without having to change the catalog.

[wendellpiez]

NB: currently, the models do not provide for parameters to have "names" (unique or otherwise) although we have elements for their "description", "label" and "value" (for setting a value or a default value for a calling profile), none of which must be unique to that parameter. To address parameters, we use their @id attributes, which must be unique (within document scope) to be valid to ID constraints declared in the schema. That is, they can be trusted to be unique and useful for addressing (since any element with ID 'x' will be the only such element), but not guaranteed to be "meaningful" in any way: in the current design these IDs could be opaque UUIDs, as long as they don't repeat in the document.

The same thing is incidentally true of other ID-carrying elements including controls and subcontrols -- or not incidentally, since those cases also show there is another approach, inasmuch as there, we have properties and the declarations model available to permit controsl (and subcontrols and parts) to be assigned "name" properties which indeed (via a validation against appropriate declarations) may have many or all of the characteristics described here for parameter names -- and which are orthogonal to the (guaranteed unique but potentially opaque) ID value (the control/@id in the XML). So we see

<control id="ac.1" ...>
  <prop class="name">AC-1</prop>

etc. This semantic overloading is useful since it gives us multiple ways to address these elements (by ID, by name property, by brute-force XPath etc) as well as the ability to cross-check them against each other. Yet at the same time, the responsibility for designing and enforcing such a constraint (in its particulars -- here, for example, we expect to see a clean mapping between the values) goes to the catalog designers/publishers, not the standard. While OSCAL provides a mechanism to support making (and enforcing) such declarations, in other words, it doesn't mandate any particular declarations for this purpose.

Among other things this makes me wonder whether the requirements stipulated here must really be addressed in the design of the SP800-53 catalogs (and presumably of other catalogs to come), and not of OSCAL -- irrespective of whether/how it applies to either/both @id values (whether/how normalized and schematic, i.e. not only unique but meaningful), and arbitrary properties.

At the same time, it would also be relatively easy/painless to add prop to the model for param, so parameters could have their own properties. Presumably we then also add @class to param to be able to expose these properties to validation (of cardinality, values assignment etc.) against declarations (but OSCAL declarations not schema or other hard-wired declarations). This would provide another easy approach both to exposing (addressing) the parameters themselves, and to constraining them (or confirming such constraints are met). param already permits the link element, since extant usage suggests show us that whenever a parameter is set, a link or two is sure to come with it.

Note that we might wish to permit the above while also constraining @id values (or anything else) in the way @gregelin describes. But I still think it's a problem that might belong to the particular catalog and its user community, not to the OSCAL format.

[anweiss]

On the JSON side of things, something that might help and that we can already take advantage of today with JSON schema draft-07 is that of conditional schema evaluation provided by the if, then and else keywords. Here's an example (courtesy of https://stackoverflow.com/a/38781027):

{
  "type": "object",
  "properties": {
    "foo": { "type": "string" },
    "bar": { "type": "string" }
  },
  "if": {
    "properties": {
      "foo": { "enum": ["bar"] }
    }
  },
  "then": { "required": ["bar"] }
}

In the example above, if the value of thefoo property equals bar, then the bar property is required.

Granted, this only applies to conditional requirements of properties and not conditions expressed as relationships among properties. Support for the latter won't be made available until draft-09 of JSON schema which is due in November.

[david-waltermire]

These requirements should be considered as part of #474. Closing this issue in favor of the new issue.