Modify validation for telephone-numbers>number

[Telos-sa]

User Story:

We have outlined the user story and goals for this enhancement on NIST OSCAL Repo issue 2041

There are validation constraints the oscal-cli uses for telephone-numbers>number that are not outlined in the OSCAL SSP json schema

Acceptance Criteria

• [ ] All website and readme documentation affected by the changes in this issue have been updated.
• [ ] 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.

[iMichaela]

@Telos-sa - in general none of the OSCAL constraints are implemented in the schemas because it is not possible. The Schematron rules were used for the OSCAL XML to validate the artifacts and ensure the constraints are following the OSCAL Reference (documentation) for the JSON constraints. Please review https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/system-security-plan/json-reference/#/system-security-plan/metadata/parties/telephone-numbers - in particular the information presented below.

I am not sure what is the purpose of this issue. @Telos-sa - could you please clarify the expectations? Thank you.

[Telos-sa]

@iMichaela I guess we're just confused with where these constraints are coming from and how we could apply them programmatically. I understand that this is all covered in the outline on the link you provided - we are very familiar with this resource.

The concern is how will we be able to programmatically implement these constraints in the module we've created for exporting OSCAL. We currently leverage the JSON schemas for the different models - so our hope is that these various constraints for specific fields could be represented in the schemas somehow.

[david-waltermire]

@Telos-sa These are defined in the OSCAL Metaschemas as a built-in constraint.

Here is an excerpt:

<allowed-values allow-other="yes">
  <enum value="home">A home phone number.</enum>
  <enum value="office">An office phone number.</enum>
  <enum value="mobile">A mobile phone number.</enum>
</allowed-values>

Because this is allow-other="yes", which means any value can be used, it is not possible to check for one of a set of given values.

In general, some things can be expressed in JSON schema, but others are not easily or possible to express in JSON or XML schema. We use constraints for these, which supports validation in addition to schema validation. For the extra-schema validation case, you have a few choices for how to do this in your tooling:

1) Call OSCAL CLI to perform the checks, processing the results (which are now in SARIF) making this easier. 2) Implement Metaschema constraint processing and checking to do something similar to what OSCAL CLI does. 3) Implement the constraints as code in your tool.

Given the above, this issue cannot be addressed through a change in OSCAL CLI.