Update the authorization-type for FedRAMP JAB to be deprecated

[aj-stein-gsa]

Constraint Task

As a developer of OSCAL-enabled tools, to ensure I do not continue to prepare OSCAL data for system authorizations that are currently obsolete, I want a deprecation warning to the .[@type="fedramp-jab"] for the value in allowed-value of authorization-type in FedRAMP constraints to know and possibly communicate through software to users this value is deprecated, even if still applicable.

Intended Outcome

Add a deprecation message like to so the fedramp-jab authorization-type value in the enum set.

https://github.com/usnistgov/OSCAL/blob/b39789e5ab6df36dbe14f481e40113b91fd25f3f/src/metaschema/oscal_catalog_metaschema.xml#L234

                        <enum value="fedramp-jab" deprecated="3.0.0-milestone1">**(deprecated)*** The authorization type of 'fedramp-jab' is deprecated. Use it for pre-existing JAB authorizations only.</enum>

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

FedRAMP allowed values must be defined or verified.

Metapath(s) to Content

/system-security-plan/system-characteristics/prop[@name='authorization-type'][@ns='http://fedramp.gov/ns/oscal']/@value

Purpose of the OSCAL Content

No response

Dependencies

No response

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response