Is there guidance for extension handling?

[bradh]

This is a generalization of a question from gitter, where there was some discussion on the use of ns for prop values.

My concern is how domain-specific extensions (of which prop is an example) get handled, and how consumers can know that ignoring an extension isn't going to break things.

As an example, consider <prop name="ControlShouldBeLeftOut" value="true" ns="http://example.com"/>

If I'm a consumer that is aware of all extensions, and the semantics associated with them, then I could do the right thing in every case. However that seems a lot to ask without at least some kind of policy on publishing them, and a standard way to interpret the (machine-readable?) policy.

Perhaps it would be better to publish some guidance on what extensions can (and can not) do?

Possibly there should be some metadata flag that says "to interpret this catalog, consumers need to understand the following extensions: X, Y, Z"? That could also drive to more modular / re-usable extension mechanisms / policies.

[bradh]

I thought about this a bit. There are probably (at least) two parts:

• a configuration management / publishing / process part
• a technical / schema part

The technical part of an extension is really about saying what we mean in a machine readable way.

That is a bit difficult, because OSCAL is a producer standard (or spec): it says how to make OSCAL documents, not how to process them.

So one approach is to say "if you don't understand my extension (and maybe version), you can't process my document - just stop now". A less strict approach is to allow extensions to flag if the extension needs to be understood, or is just supplemental data.

If we're going to allow supplemental data, then consumers / processors need to know what to do with it - just pass it through or drop it are probably the reasonable options.

First cut extension mechanism:

1. Declare the extension (early) in the metadata, using a new extension element.

<extension mustUnderstand="true" extension_ns="urn:uuid:...." displayname="Security Markings"/>
<extension mustUnderstand="false" extension_ns="urn:uuid:...." displayname="Controls Have First Created Date" defaultaction="copy"/>
<extension mustUnderstand="false" extension_ns="urn:uuid:...." displayname="Controls Have Last Modified Date" defaultaction="drop"/>

2. Then any use of a "extension" value (outside of those listed in the spec"), eg. in a prop name value needs to have an ns entry that matches something in an extension element declared (or its not valid OSCAL).

That allows to to handle cases like:
<prop name="marking" ns="fedramp">UNCLAS</prop>

Obviously it is limiting in that it doesn't provide ability to do something like a prop embedded in an attribute. So you can't say:
<call control-id="ac-1" classification="UNCLAS"/>
However that is a function of the schema limitations, which is related to, but distinct from, extension handling.

[david-waltermire]

This question will be addressed by #857.

[ohsh6o]

@david-waltermire-nist I know #825 was closed and it is only one extension mechanism in OSCAL, but is it something I should declare and reframe as an issue for consideration the OSCAL 1.1.0 Milestone?

[david-waltermire]

Yes. Please do.