Need Location not tied to Person/Org

[brian-ruf]

User Story:

As an OSCAL SSP Author, I sometimes need to identify named locations without associating them with people or organizations. For example, an organization may have multiple data centers with inventory items, or multiple staff at the same location.

It would be helpful to have a separate assembly in metadata for locations (address, city, state, zip). Locations can then be linked to people and organizations without the need to define the same address in each metadata/party/person or metadata/party/org assembly. Also, these stand-alone locations can represent data centers or locations for assets.

The current address assembly within a metadata/party/org or metadata/party/person could remain. This would be an optional stand-alone metadata/location assembly, which has an id attribute, a label (or title) field, an address assembly, and remarks.

The current party, component, and inventory-item assemblies would then be expanded to include a location-id with cardinality of 0 or more.

Goals:

Ensure location can be defined as a stand-alone assembly separate from party, and is usable by party, component, and inventory-item.

Dependencies:

None.

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.

[brian-ruf]

Do we want to just consider location in terms of building address/location, or also enable more granular location, such as row 3, rack 5, slot 7?

[brian-ruf]

30-Jan-2020 Status

@david-waltermire-nist updated metaschema to support this.
Part of PR #614 Modeling refactoring based on feedback (Session 1)

[david-waltermire]

This is addressed by PR #619.