Add WIP ADR for attachment handling for #1061

[aj-stein-gsa]

Committer Notes

Closes #1061.

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Have you added an explanation of what your changes do and why you'd like us to include them?
• If applicable, have all FedRAMP Documents Related to OSCAL Adoption affected by the changes in this issue have been updated.?
• If applicable, does this PR reference the issue it addresses and explain how it addresses the issue?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

[aj-stein-gsa]

This is not necessarily ready for review right right now, but it will be later in the afternoon and more importantly for others first thing Monday once I am on leave. So on that note, I will be changing status for my future aspirations now. 😄

[wandmagic]

rmf-use is a good choice for the param, i like this solution

[Rene2mt]

Would we not still need <prop name="type" value="plan"/> in addition to <prop ns="http://fedramp.gov/ns/oscal" name="has-oscal-document" value="yes"/> for approach 2B?

[aj-stein-gsa]

Hmmm, I think about this, I had not considered that when I originally wrote the thing. 😅

[Rene2mt]

I was initially getting hung up on the difference between oscal-model=poam and fedramp-use=poam but I see that the former specifies if its an oscal model, while the latter specifies the specific use case.

I recommend we use something like oscal-model=true|false or oscal-model=yes|no

And for the use case, we have either fedramp-use=catalog|profile|ssp|sap|sar|poam or rmf-use=catalog|profile|ssp|sap|sar|poam

[wandmagic]

yes i prefer rmf-use, and something seperate that declares its an oscal item

[aj-stein-gsa]

These are the conversations I was hoping to have! 😄

So in this one-off case, it would seem redundant. But where this will probably become less redundant over time (or at least the beginning) is where certain non-OSCAL data is handled for similarly named OSCAL uses cases.

At this point, there are a collection of attachment types that can 1) encode data in an alternative format to OSCAL or 2) there is no alternative to OSCAL. Is there another approach to meaningfully handle that? There are a series of others that get a little more nuanced after that.

<resource uuid="11111111-2222-4000-8000-001000000048">
    <title>Assessment Results (SAR)</title>
    <prop name="published" value="2023-05-31T00:00:00Z"/>
    <rlink href="./attachments/POAMs/SAMPLE_SAR_20230531.xml" media-type="application/xml;oscal-model=assessment-results; fedramp-use=ret"/>
    <rlink href="./attachments/POAMs/SAMPLE_POAM_20230531.xlsx" media-type="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;oscal-model=none; fedramp-use=ret"/>
</resource>

<resource uuid="11111111-2222-4000-8000-001000000048">
    <title>CIS/CRM</title>
    <prop name="published" value="2023-05-31T00:00:00Z"/>
    <!-- Strictly speaking there is no pure CIS/CRM model in core OSCAL yet. -->
    <rlink href="./attachments/POAMs/SAMPLE_POAM_20230531.xlsx" media-type="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;oscal-model=none; fedramp-use=crm"/>
</resource>

As it stands now, we also have ConMon, but no definitve ConMon model. So I would assume assessment for authorization and ConMon use AP/AR bundles, but it might not be clear if there are multiple ARs in a presentation view into a "whole package over time" what that would look like without having both params, so less redundancy than our first case.

<resource uuid="11111111-2222-4000-8000-001000000048">
    <title>Authorization Assessment Results from a while ago (SAR)</title>
    <prop name="published" value="2023-05-31T00:00:00Z"/>
    <rlink href="./attachments/POAMs/SAMPLE_SAR_20230531.xml" media-type="application/xml;oscal-model=assessment-results; fedramp-use=authorization-sar"/>
    <rlink href="./attachments/POAMs/SAMPLE_POAM_20230531.xlsx" media-type="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;oscal-model=none; fedramp-use=ret"/>
</resource>
<resource uuid="11111111-2222-4000-8000-001000000049">
    <title>ConMon Assessment Results (SAR)</title>
    <prop name="published" value="2025-01-26T00:00:00Z"/>
    <rlink href="./attachments/POAMs/SAMPLE_SAR_20250126.xml" media-type="application/xml;oscal-model=assessment-results;fedramp-use=conmon-sar"/>
    <rlink href="./attachments/POAMs/SAMPLE_POAM_20230531.xlsx" media-type="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;oscal-model=none; ;fedramp-use=conmon-sar"/>
</resource>

I think in these cases having both params gives us some of that context without overloading one parameter with a need for a bunch of conditional logic for a few cases, and this is just the first one that comes to mind with hybrid data that will be OSCAL and non-OSCAL for specific use cases.

Thoughts?