Comments Summary
Open Comments 19
While I completely agree that multi-layer profile resolution is the the preferred approach and the only way to handle overlays and multi-frameworks, we are looking to initially reduce complexity to the greatest degree practical for MVP/Core adoption, then allow organizations to mature their capabilities over time based on their needs and priorities.
In the TFG meeting, highlighted the need to verify FedRAMP has not changed the baselines since these were drafted in Jan 2025.
The SSP OSCAL guidance for “import-profile” specifically discourages the use of a “resolved profile catalog” for good reasons.
It makes sense to create the “tailoring-profile” and have the other profiles pull from the tailoring-profile, while this approach is useful from authoring effort perspective, it adds runtime burden for having to resolve multiple layers of profiles.
Is there an approach to resolve “multiple stacked profiles” into single profiles so that they can be referenced directly in the SSP?
The baselines are not likely to change very often, so perhaps a more efficient runtime solution bears better.
It's actually covered in Appendix E, but should be linked from this page. I'll make that update. I haven't yet converted the example to YAML, but you can see it with XML here:
This is complete.
I didn't completely respond to your comment in my last response, and it's a fair question.
I'd prefer to keep the three levels (IAL, FAL, AAL) separate even though the historic guidance is that all three are the same for a given baseline. If that guidance ever changes, I don't want people to have to change the props they use. Also, I believe the three separate props we are using are recognized as core OSCAL whereas a single prop would need to be a FedRAMP extension.
This is complete.
This page is now part of a larger adoption topic that covers both retrofit and new adoptions.
It's actually covered in Appendix E, but should be linked from this page. I'll make that update.
I haven't yet converted the example to YAML, but you can see it with XML here:
In the TFG meeting we discussed putting more content at the top to clarify tools should be using the profiles and performing the resolution themselves. Tools may cache as appropriate depending on frequency of updates to these profiles and any overlays. @Brian Ruftaking action to draft content.
Clarify this is important to ensure baselines remain fresh.
Needs end-to-end review for alignment with FedRAMP templates and defined OSCAL patterns.
Good catch. I'm more inclined to remove this from the validator, but we should discuss either way.
According to the fedramp-automation validator, the following additional role appears to be required:
- fedramp-pmo: FedRAMP Project Management Office (PMO)
I like the catch and addition of `marking`. Thank you!
I removed the `fedramp-version` prop as that was tied to the validation file version, which is no longer relevant as PMO is no longer maintaining or publishing validation files. If we end up maintaining validation files and want to address that with a prop, it will need to be a different prop name.
@Brian Ruf I added an additional prop reference based upon the guidance formally found on the FedRAMP documentation website (since decomissioned). I preserved it mostly as is, but change the verb from "must" to "should" since the implied reference no longer exists. However, it seems like a useful addition. If not, my edit should be reverted.
Per TFG discussion, we are not including paths/pointers in the documentation at this time.
There doesn't seem to be a pattern for the Digital Identity Level (DIL) Determination (folliow Service Model). As much a test of my own understanding as it is a recommendation, but what about this?
<system-security-plan>
<system-characteristics>
<prop ns="https://fedramp.gov/ns/oscal" name="dil-determination" value="SOME_VALUE" />
</system-characteristics>
</system-security-plan>
As indicated above must be either IAL3/FAL3/AAL3, IAL2/FAL2/AAL2, or IAL1/FAL1/AAL1.
Switch XML to YAML
Switch XPath to JSON Pointer (https://datatracker.ietf.org/doc/html/rfc6901)
Apply to all pattern content.
We need to fix the link in the "Important for Leveraged Systems" callout once the controls section is complete and the location is not likely to change again.
Todo: Convert XPath queries to JSON Pointer
Todo: Replace XPath queries with JSON Pointer
We have since agreed not to include paths at this time.
To do: Replace XPath queries with JSON Pointer
Should Separation of Duties matrix be listed as an optional attachment (e.g., for MVP) or do we have a good way to represent this in OSCAL?
Per TFG discussion, we are not including paths/pointers in the documentation at this time.
To do: Replace XPath queries with JSON Pointer
Looks like this was resolved. If you agree, please archive this comment.
Typo in the page heading / title
Add note to adoption pages that anything not converted to machine readable should still be attached as a Word artifact.
This is now addressed as the New Adoption Path.
Per today's TFG, need to clarify that this approach is focused on legacy Word SSP conversion. Need a different approach for "New" SSP authors who should likely start with components.
The SSP adoption strategy described on this page is well suited for systems that are already authorized / already have an SSP. However, CSPs that are early in their authorization journey may be better positioned to attempt the "advanced" / "ideal" path from the get go, especially if they have access to OSCAL-ready GRCs and tooling.
⚠ Recycle Bin (4 comments)
Either:
- remove or background page (leaning in this direction)
- keep, but don't include links
- keep and link to oscal-foundation forks
Note: the above repos have been removed as of April 6th, 2026. However, forks are available:
- https://github.com/search?q=fork%3Atrue%20fedramp-automation%20GSA%20in%3Aname&type=repositories
- https://github.com/search?q=fork%3Atrue+automate.fedramp.gov+GSA+in%3Aname&type=repositories
Use at your own discresion as they may not represent the lastest content as of source decomissioning.
Add Section 5 roles here. Then point section 5 here.
@Brian RufLooking at the schema, i think the correct prop name under resource is "Published" not "Publication".
Discussed in today's TFG. We agree that that resolved profiles allow an easy quick-start. Verified that we show it initially in the adoption and moving to proper profile processing by the "Normalized" phase.. Considering this closed.