For the guide, please indicate the section number and printed page number (lower right corner)
The current structure of Attestations needs to be revamped. The current structure, as indicated by the guide, is attached below:
What is your feedback?
The guide snapshot above suggests that there should be a parent part called “authorization-statements” that contains the recommend-authorization prop, along with several singular “authorization-statement”. Instead, each of these singular statements must have their own recommend-authorization prop:
Additionally, the responsible parties must be paired directly, 1 to 1, with each “recommend-authorization”. This requires that each attestation under attestations should have one or more responsible party per recommend-authorization prop (stored within their unique part). A JSON example of a single attestation entry is shown below:
The only expansion of cardinality that can be made in this example is increasing the count of party-uuids that occur in the responsible roles.
I have attached a screenshot of the attestation outline from NIST. While their parts structure supports having multiple sub-parts with their own respective attestation, the responsible roles must be paired per each individual part.
This is a ...
This relates to ...
NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.
The current structure of Attestations needs to be revamped. The current structure, as indicated by the guide, is attached below:
The guide snapshot above suggests that there should be a parent part called “authorization-statements” that contains the recommend-authorization prop, along with several singular “authorization-statement”. Instead, each of these singular statements must have their own recommend-authorization prop:
Additionally, the responsible parties must be paired directly, 1 to 1, with each “recommend-authorization”. This requires that each attestation under attestations should have one or more responsible party per recommend-authorization prop (stored within their unique part). A JSON example of a single attestation entry is shown below:
The only expansion of cardinality that can be made in this example is increasing the count of party-uuids that occur in the responsible roles. I have attached a screenshot of the attestation outline from NIST. While their parts structure supports having multiple sub-parts with their own respective attestation, the responsible roles must be paired per each individual part.
Is this report specifically related to the Word or Excel files from fedramp.gov? If so, please do not open an issue here. Follow the guidance in this repository's README and contact info@fedramp..gov. -No
What version of OSCAL are you using? (Check our info on supported OSCAL versions)
What action would you like to see from the FedRAMP PMO?
Please address the above, and scope the required changes to the attestation requirement. I would be happy to discuss these proposed changes in a call.