[Feedback]: Digital Identity Level (DIL) Determination discrepancy in documentation and constraints

[Telos-sa]

This is a ...

question - need to understand something

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)
• the FedRAMP OSCAL Validations

What is your feedback?

For the Digital Identity Level (DIL) Determination there is a discrepancy between the document templates and OSCAL with the values it accepts. In the document templates it accepts the following values: IAL3/FAL3/AAL3, IAL2/FAL2/AAL2, IAL 1/FAL1/AAL1, but in OSCAL it needs an integer: 1, 2, or 3.

Similarly, in the definitions for the SSP meta schema, it requires 1, 2, or 3:

Is there a reason for having this difference between the documents and OSCAL? Could we instead use only one of the value option types (string vs integer)?

Where, exactly?

SSP OSCAL and Document Templates

Other information

No response

[Rene2mt]

The document templates followed the nomenclature in NIST 800-63 (see https://pages.nist.gov/800-63-3/sp800-63-3.html#:~:text=For%20non%2Dfederated%20systems%2C%20agencies%20will%20select%20two%20components%2C%20referred%20to%20as%20Identity%20Assurance%20Level%20(IAL)%20and%20Authenticator%20Assurance%20Level%20(AAL).%20For%20federated%20systems%2C%20agencies%20will%20select%20a%20third%20component%2C%20Federation%20Assurance%20Level%20(FAL).). OSCAL has named properties that align (there is an implicit mapping). For example:

• OSCAL <prop name="identity-assurance-level" value="1" /> is the equivalent of IAL1 in the documented template
• OSCAL <prop name="authenticator-assurance-level" value="2" /> is the equivalent of AAL2 in the documented template
• OSCAL <prop name="federation-assurance-level" value="3" /> is the equivalent of FAL3 in the documented template

Removing these props from core NIST OSCAL would be a backwards breaking / non-compatible change and adding new props would be duplicative so we do not foresee a change in the near-term.

[Telos-sa]

I agree. I would recommend instead changing the requirement in the legacy SSP template to 1, 2, 3 to match OSCAL, and not changing the OSCAL to match legacy.

And/or Accept the OSCAL syntax of 1,2,3 in an SSP produced by OSCAL as opposed to IAL1,AAL1,FAL1, IAL2, AAL2,FAL2, IAL3,AAL3,FAL3.

Ticket is for consistency between the manual and OSCAL process, without requiring a processor between the two to convert the formatting back and forth.

[aj-stein-gsa]

Thanks for this report. I see it is a little old, but seems relevant to ongoing work on porting the new constraints. We should discuss this feedback and decide how to act on it since these newer constraints were already covered with #701. I will move this into backlog to triage further.