Currently the system-characteristics element captures the date-authorized as entry. Depending on the Package, there may be multiple authorization types, and multiple authorization events for the same package.
I propose expanding on the date-authorized to include a list of events, with an array for each event to collect more specific details about the authorization event.
This would be able to demonstrate the package throughout its lifecycle, and have a location to centralize feedback about the authorization status and process. Needs to be use-case agnostic, interchangeable, and backwards compatible.
Possible structure requirements, represented in Json:
{
"system-characteritsics": {
"date-authorized": {
"type": "dateTimeStamp",
"value": "date of most recent authorization event"
},
"authorization-events": [
{
"authorization-decision": {
"type": "token",
"value": "Must be one of the requirements, or locally defined. Should provide a standardized list of options",
"requirements": ["ato", "p-ato", "d-ato", "withdraw", "decommission", "retire"]
},
"authorizing-official": {
"type": "uuid",
"value": "UUID of authorizing official that made the decision"
},
"date-of-decision": {
"type": "dateTimeStamp",
"value": "date of this associated event"
},
"date-of-expiration": {
"type": "dateTimeStamp",
"value": "could be a date of exp, or a term limit, or a risk limit. Need to determine options for flexibility."
},
"remarks": {
"type": "multi-line markup",
"value": "details of the decision"
}
}
]
}
}
Goals
The goal is to provide authorization decision details from the AO to see previous history, which may be important in making the current ATO decision. For instance, if provisional-ato or conditional ato, and the conditions arent met, is there an extension, no decision, feedback, etc? Need to capture those details in OSCAL to support visualization of the entire process. Even if it doesnt go into the SSP, having it exist somewhere in the models.
Dependencies
No response
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.
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
User Story
Currently the system-characteristics element captures the date-authorized as entry. Depending on the Package, there may be multiple authorization types, and multiple authorization events for the same package.
I propose expanding on the date-authorized to include a list of events, with an array for each event to collect more specific details about the authorization event.
This would be able to demonstrate the package throughout its lifecycle, and have a location to centralize feedback about the authorization status and process. Needs to be use-case agnostic, interchangeable, and backwards compatible.
Possible structure requirements, represented in Json:
{ "system-characteritsics": { "date-authorized": { "type": "dateTimeStamp", "value": "date of most recent authorization event" }, "authorization-events": [ { "authorization-decision": { "type": "token", "value": "Must be one of the requirements, or locally defined. Should provide a standardized list of options", "requirements": ["ato", "p-ato", "d-ato", "withdraw", "decommission", "retire"] }, "authorizing-official": { "type": "uuid", "value": "UUID of authorizing official that made the decision" }, "date-of-decision": { "type": "dateTimeStamp", "value": "date of this associated event" }, "date-of-expiration": { "type": "dateTimeStamp", "value": "could be a date of exp, or a term limit, or a risk limit. Need to determine options for flexibility." }, "remarks": { "type": "multi-line markup", "value": "details of the decision" } } ] } }
Goals
The goal is to provide authorization decision details from the AO to see previous history, which may be important in making the current ATO decision. For instance, if provisional-ato or conditional ato, and the conditions arent met, is there an extension, no decision, feedback, etc? Need to capture those details in OSCAL to support visualization of the entire process. Even if it doesnt go into the SSP, having it exist somewhere in the models.
Dependencies
No response
Acceptance Criteria
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response