Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify validation for telephone-numbers>number #33

Closed
3 tasks
Telos-sa opened this issue Sep 17, 2024 · 3 comments
Closed
3 tasks

Modify validation for telephone-numbers>number #33

Telos-sa opened this issue Sep 17, 2024 · 3 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@Telos-sa
Copy link

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.
@Telos-sa Telos-sa added the enhancement New feature or request label Sep 17, 2024
@iMichaela
Copy link

iMichaela commented Sep 17, 2024

@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.

Screenshot 2024-09-17 at 4 00 09 PM

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

@Telos-sa
Copy link
Author

@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
Copy link
Contributor

david-waltermire commented Sep 27, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants