Incorrect Index Enforcement of "provided-by" link rel in Components

[brian-ruf]

Describe the bug

When attempting to relate a "service" component to a "system" component using the using the //component[@type='service']/link[@rel='provided-by']/@href] field, the oscal-cli returns an error, even though the "system" component's UUID is referenced properly.

The UUID value is valid as confirmed by:
//component[@type='system' and @uuid=//component[@type='service']/link[@rel='provided-by']/@href]

OSCAL CLI to validate the following code snippet ...

      <component uuid="11111111-2222-4000-8000-009000100001" type="system">
         <title>Awesome Cloud PaaS</title>
         <description><p></p></description>
         <status state="operational"/>
      </component>

      <component uuid="11111111-2222-4000-8000-009000500001" type="service">
         <title>Authorized Service Provided by Leveraged System</title>
         <description><p></p></description>
         <link href="11111111-2222-4000-8000-009000100001" rel="provided-by"/>
         <status state="operational"/>
      </component>

the oscal-cli produces the following error ...

[ERROR] [/system-security-plan/system-implementation[1]/component[3]/link[1]] Key reference [11111111-2222-4000-8000-009000100001] not found in index 'index-system-implementation-component-uuid-software' for item at path '/system-security-plan/system-implementation[1]/component[3]/link[1]'

Who is the bug affecting

SSP Authors who are trying to link "service" components to the "system" component that provides those services.

What is affected by this bug

OSCAL Content, Documentation, Metaschema

How do we replicate this issue

Run the latest OSCAL cli against this file:
valid-SSP.zip

using:
oscal-cli validate valid-SSP.xml

Observe error pasted above

Edit the file to pre-pend a hashtag (#) to the UUID value in the link/@href and re-run the OSCAL CLI.
Observe the same error.

Expected behavior (i.e. solution)

No error - valid content.

Other comments

NOTE 1: This appears to be caused by an incorrect index as defined in the OSCAL SSP Metaschema.
https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_ssp_metaschema.xml#L640-L642

NOTE 2: The documentation is unclear as to whether this value should include a leading hashtag (#) in //component[@type='service']/link[@rel='provided-by']/@href.

The documentation and metaschema definition seem to suggest the hashtag should not be present; however, when observing a similar use case in the NIST SP 800-53 catalog, the hashtag is present when a link/@href is used to relate one control to another control in the same file. Also a leading hashtag is consistent with a URI fragment.

Revisions

No response

[aj-stein-gsa]

Just a heads up from knowledge and experience, the @href is a uri-reference datatype points to the "relative reference" where that hints at anchor. e95e0bca-b70c-42be-865d-9e0fcbb64691 is like have an unqualified host/filename (it is ambiguous) where as a relative reference is #e95e0bca-b70c-42be-865d-9e0fcbb64691.

[aj-stein-gsa]

Also, I will draft a PR for this, per discussion yesterday that led to @brian-ruf drafting this issue in the first place. This appears to be FedRAMP-specific logic in the index and index enforcement. So for the time being, I will propose deleting it to resolve this bug and FedRAMP can handle it via externalized constraints. This will not overly constraint generic use cases, NIST RMF or otherwise, that do not apply outside the scope of FedRAMP use.

[brian-ruf]

This may be the same root cause as the issue Telos raised in #2064. I missed that issue when I opened this, and it may be that this issue should be merged with that one.

[aj-stein-gsa]

This may be the same root cause as the issue Telos raised in #2064. I missed that issue when I opened this, and it may be that this issue should be merged with that one.

Well the related PR (#2075) has been merged and may be released today, so does this point mean the NIST OSCAL Team can hopefully close both?

[brian-ruf]

Upon review, it appears PR #2075 will resolve this issue.