Update and Standardize src/content/rev5/resources/xml/FedRAMP_extensions.xml in metaschema format

[Telos-sa]

This is a ...

improvement - something could be better

This relates to ...

• the FedRAMP OSCAL Registry
• the FedRAMP OSCAL baselines
• the Guide to OSCAL-based FedRAMP Content
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)
• the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)

User Story

Requesting that this document, or something like this, be created for each model that outlines the FedRAMP requirements, in a way that they can be standardized and ingested. For instance, where props are created, sometimes the FedRAMP created prop identifies the name spaces and sometimes it does not.

Goals

Would like to standardize this process so that the programmatic requirements can be layered onto the NIST SSP metaschema requirements to create a full SSP template to generate, will all required/expected props, their values, and any additional validation assumptions (like core controls, required response points, parameters, etc) if referenced in baseline profile.

Dependencies

No response

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) 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.

Other information

No response

[Rene2mt]

Concur. We are reviewing all the models to capture all of the constraints and other (data) requirements. We have not settled on a particular format but see great benefit in something that is standardized and can that can be ingested. We are open to proposed data structures or recommended changes to the FedRAMP_extensions.xml to better support this need.