POAM > Observations > Origins > Actor > Actor-UUID

[rachkim00]

User Story

As an OSCAL POAM documenter/ CSP, I need to be able to:
reference uuid from components or party in the actor field, instead of creating new actor UUID.

This may requires schema/name/guidance update in the actor-uuid field.

Goals

To be able to use already existing UUID (from system component) in the actor uuid section

OSCAL POAM schema defines actor-uuid, which sounds like a unique actor UUID should be separately defined. However, often times (especially in FedRAMP context), these actors are scanning tools (components) or 3PAO/CSP (parties) that we already define somewhere else.

Instead of defining another UUID for actor (which could lead duplicate of data, since one system component can have two UUIDs for component and actor), I suggest this field should be flexible to allow uuid-ref.

This is how FedRAMP is also guiding in their OSCAL POAM guide.

Dependencies

No response

Acceptance Criteria

• 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

[nikitawootten-nist]

A simple way we could solve this is to refactor the origin-actor assembly to be an array of choice objects, between an actor and a field such as "actor-uuid".

[aj-stein-nist]

We check and in current develop and release OSCAL models, this is currently only a flag with a UUID type, no constraints or indices. This seems reasonable to consider, scope of work is unclear if it is a documentation change or potentially a constraint enhancement or both to meet the ask.

[Arminta-Jenkins-NIST]

At 10/12 Triage Meeting: @aj-stein-nist needs to come up with an example to support the hypothesis before refining this issue.

[brian-ruf-ezd]

I believe this is an issue resulting from the re-use of the same origin-actor assembly in both the AR and the POA&M metaschema definitions.

The type flag is currently defined as part of the origin-actor assembly in the oscal_assessment-common_metaschema.xml file as follows:

<define-flag name="type" as-type="token" required="yes">
   <formal-name>Actor Type</formal-name>
   <description>The kind of actor.</description>
   <constraint>
      <allowed-values>
         <enum value="tool">A reference to a tool component defined with the assessment assets.</enum>
         <enum value="assessment-platform">A reference to an assessment-platform defined with the assessment assets.</enum>
         <enum value="party">A reference to a party defined within the document metadata.</enum>
      </allowed-values>
   </constraint>
</define-flag>

This was clearly defined with the AR in mind, and was not adjusted for use in the POA&M model. The evidence of this is that the POA&M has no way to reference content in the AP or AR, thus tool and assessment-platform are both invalid choices in the context of the POA&M model.

@rachkim00 's point is similar to one I was making in #2026: Sometimes tools are the actor or the source of information.

A POA&M can only reference content in the POA&M content itself, the imported SSP, and any linked profiles or catalogs. Tools that may be referenced by a POA&M item's origin could only be defined in the POA&M's local definitions or SSP.

A simple resolution without introducing any breaking changes is to simply add the following two choices to the allowed-values above:

<enum value="component">A reference to a component defined within the local definitions or SSP.</enum>
<enum value="inventory-item">A reference to an inventory item defined within the local definitions or SSP.</enum>

A more complete resolution is for the AR origin's type flag should accept all five (tool, assessment-platform, party, component, and inventory-item), but have a revised definition for the POA&M origin's type flag that only allows it to accept party, component, and inventory-item.