Required 'asset-id' prop under inventory-items>implemented-components

Telos-sa commented 2 months ago

User Story

The oscal-cli requires there be a prop under inventory-items>implemented-components with name="asset-id". This is not outlined anywhere in the schema or the outline of the SSP.

Goals

Reflect in the schema and outline that the 'props' array is required and that one matching name="asset-id" is necessary.

Alternatively, "asset-id" could be changed into an actual (required) schema element under implemented-components rather than being represented as a prop.

Dependencies

No response

Acceptance Criteria

[X] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
[ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
[ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

iMichaela commented 2 months ago

@Telos-sa - OSCAL schema never had an inventory-item/implemented-components/asset-id please check with all released versions. Please provide the oscal-cli version .

I am guessing you are using the oscal-cli released/used by FedRAMP and not NIST which most likely was generated not from NIST OSCAL metaschema definitions.

If such assembly is needed by others as well, we need to work it with the community, BUT it cannot be mandated since it will cause backward incompatibility.

Telos-sa commented 2 months ago

I am using oscal-cli version v1.0.3 from https://github.com/usnistgov/oscal-cli.

The error log is suggesting that inventory-items>implemented-components requires a prop with name="asset-id". There is no implemented-components>asset-id element.

The issue I see with this, is that there is nothing in the v1.1.2 metaschema that indicates that props is a required element for implemented-components, and also nothing indicating that a prop with name="asset-id" is required.

iMichaela commented 2 months ago

I am using oscal-cli version v1.0.3 from https://github.com/usnistgov/oscal-cli.

The error log is suggesting that inventory-items>implemented-components requires a prop with name="asset-id". There is no implemented-components>asset-id element.

The issue I see with this, is that there is nothing in the v1.1.2 metaschema that indicates that props is a required element for implemented-components, and also nothing indicating that a prop with name="asset-id" is required.

I am sorry for misunderstanding your note above. This is a constraint documented with all OSCAL constraints in the References. For this particular constraint, please see: https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/system-security-plan/json-reference/#/system-security-plan/system-implementation/inventory-items

The cardinality is documented in References under the implemented-component: https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/system-security-plan/json-reference/#/system-security-plan/system-implementation/inventory-items/implemented-components , see:

HAS CARDINALITY:  for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='asset-id'] the cardinality of prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='asset-id'] is constrained: 1; maximum unbounded.

This information (the documentation) is automatically generated front eh OSCAL metaschema definition. I can provide details (where to find it ) , if interest exists.

iMichaela commented 2 months ago

If no additional information is needed under this issue, I recommend we close it.

Telos-sa commented 2 months ago

What is the user story for this constraint? This section already requires a component-uuid, so is it requiring the id of the asset as well? In most cases the uuid is adequate for establishing a reference point.

And also recommending that this constraint is removed, and if it can't be removed, at least make this 'props' sub-element required (as it is required by the validator).

iMichaela commented 2 months ago

What is the user story for this constraint? This section already requires a component-uuid, so is it requiring the id of the asset as well? In most cases the uuid is adequate for establishing a reference point.

A system's component is not always identical with a system's asset, especially when such component is "this system" aka the entire system. From the analyzed data when we developed OSCAL (SSP model) we found that organizations have specific identifiers that are used to uniquely identify a logical or tangible item (e.g. Router S/N or P/N #) and sometimes asset tags.

And also recommending that this constraint is removed, and if it can't be removed, at least make this 'props' sub-element required (as it is required by the validator).

The oscal-cli is checking artifacts for correctness against the schema PLUS the constraints defined (cardinality included). This particular cardinality constraint makes the prop mandatory BUT only under the OSCAL namespace.

Making the prop mandatory will not be the same with enforcing the cardinality for this @name="asset-id", not to mention that it will break the backward compatibility, so such change is not possible to consider until OSCAL v2.0.

Reducing the number of constraints is something that I am open to do as long as it is not affecting tools' ability of understanding the data or degrades OSCAL's ability of representing high-quality data in support of automation.

Obtaining community's support for this request is also expected.

brian-ruf commented 3 weeks ago

We have just encountered this as well and I was about to open a new issue for it, but found this one.

The constraint is currently being enforced here: https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_implementation-common_metaschema.xml#L530

It really shouldn't be in the OSCAL metaschema constraints at all as it was a FedRAMP-specific requirement. Further, if it continues to stay in the OSCAL metaschema constraints, it should be placed as an immediate child to inventory-item.

In any case, it does not make sense under inventory-item/implemented-component.

@iMichaela if you agree with its removal, I am happy to submit a PR for it. If you feel strongly that it should stay, I am happy to submit a PR to move it to the correct location..

usnistgov / OSCAL