[Question]: Is non-provider-responsible-role-references-user supposed to link to "privilege-uuid" in the root SSP?

[JoseGHdz]

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's your feedback?

I am encountering an issue with the "non-provider-responsible-role-references-user" constraint validation. The error message states:

"A FedRAMP SSP MUST have each component describing leveraged systems, interconnections, or authorized services reference at least one user with an authorized privilege and function performed via the 'privilege-uuid' property."

However, the validation system points to the overall SSP location:
/system-security-plan

This behavior creates ambiguity because the problem originates from specific components that lack the privilege-uuid property within their responsible-role definitions. Checking this constraint at the component level under:
/system-security-plan/system-implementation/components
would provide more actionable and precise feedback.

---

Where Exactly?

This is related to the constraint:
non-provider-responsible-role-references-user

The issue arises because the validation error points to /system-security-plan instead of the specific components that violate the rule:
/system-security-plan/system-implementation/components

Supporting Information:

• Constraint: non-provider-responsible-role-references-user
• Documentation Reference: External Systems and Services Not Having FedRAMP Authorization

---

Expected Behavior:

The error should be reported at the component level where the issue originates. This approach provides a clear and actionable location to address the missing privilege-uuid.

Actual Behavior:

The validation system reports the error at the SSP root: /system-security-plan, making it challenging to identify which component is responsible.

---

Request for Assistance:

Could you confirm if this constraint is intended to operate at the component level? If so, can the validation system be updated to point to the specific path where the error occurs?

Any clarification or further guidance would be greatly appreciated.

[JoseGHdz]

Working with the Validation Error that is given out:

[ERROR] [/system-security-plan] non-provider-responsible-role-references-user: A FedRAMP SSP MUST have each component describing leveraged systems, interconnections, or authorized services reference at least one user with an authorized privilege and function performed via the "privilege-uuid" property.

The Sarif Document links to this help documentation:
External Systems and Services Not Having FedRAMP Authorization

The documentation that it links to does not have information to that specific error. The other section
Leveraged FedRAMP-Authorized Services

mentions the responsible roles to the leveraged-authorization-uuid but does not show the "privilege-uuid" property.

<responsible-role role-id="system-admin">
     <party-uuid>11111111-1111-3333-0000-000000000001</party-uuid>
     <remarks>
          <p>Using responsible-role to represent the CSPs "authorized users" </p>
          <p>who have access the leveraged authorization service.</p>
     </remarks>
</responsible-role>

[aj-stein-gsa]

Hi @JoseGHdz, thanks so much for this report. I have not closed out the related development task and the documentation work is potentially still pending. We got ahead of ourselves, apologies. I will update the documentation in a PR before release and also ask you for your review.

In the interim, you may want to review a valid example with more detail and inline remarks that you may find informative.

fedramp-automation/src/content/rev5/examples/ssp/xml/fedramp-ssp-example.oscal.xml

Lines 1492 to 1567 in 99f532f

	<component uuid="11111111-2222-4000-8000-009000500004" type="service">
	<title>Service C</title>
	<description>
	<p>A service provided by an external system other than the leveraged system.</p>
	<p>Describe the service and what it is used for.</p>
	</description>
	<prop name="implementation-point" value="internal"/>
	<prop name="connection-security" value="tls-1.3" ns="https://fedramp.gov/ns/oscal"/>
	<prop ns="https://fedramp.gov/ns/oscal" name="provider" value="self"/>
	<prop ns="https://fedramp.gov/ns/oscal" name="direction" value="outgoing"/>
	<prop ns="https://fedramp.gov/ns/oscal" name="authentication-method" value="yes">
	<remarks>
	<p>If 'yes', describe the authentication method in the remarks.</p>
	<p>If 'no', explain why no authentication is used in the remarks.</p>
	<p>If 'not-applicable', attest explain why authentication is not applicable in the remarks.</p>
	</remarks>
	</prop>
	<prop ns="https://fedramp.gov/ns/oscal" name="risk" value="see-remarks">
	<remarks>
	<p>Either describe a risk associated with this service, or indicate there is no identified risk.</p>
	<p>If there is no risk, please explain your basis for that conclusion.</p>
	</remarks>
	</prop>
	<prop ns="https://fedramp.gov/ns/oscal" name="impact" value="see-remarks">
	<remarks>
	<p>If there are one or more identified risks, describe any resulting impact.</p>
	</remarks>
	</prop>
	<prop ns="https://fedramp.gov/ns/oscal" name="mitigation" value="see-remarks">
	<remarks>
	<p>If there are one or more identified risks, describe any mitigating factors.</p>
	</remarks>
	</prop>
	<!-- <link href="11111111-2222-4000-8000-009000000000" rel="used-by"/> -->
	<link rel="api" href="https://api.example.com/v1" />
	<link rel="used-by" href="#11111111-2222-4000-8000-009000000000"/>
	<status state="operational"/>
	<responsible-role role-id="provider">
	<party-uuid>11111111-2222-4000-8000-004000000018</party-uuid>
	</responsible-role>
	<responsible-role role-id="admin">
	<party-uuid>11111111-2222-4000-8000-004000000011</party-uuid> <!-- placeholder to satisfy constraint: component-has-non-provider-responsible-role -->
	</responsible-role>
	<protocol name="remote" uuid="11111111-2222-4000-8000-010000000002">
	<title>Remote API Service</title>
	<port-range start="443" end="443" transport="TCP"/>
	</protocol>
	<remarks>
	<p>This is a service provided by an external system other than the leveraged system.</p>
	<p>- A "risk" property/extension - using the remarks, either describe any risk or state there is no risk and provide a basis for that assertion.</p>
	<p>As a result, the "leveraged-authorization-uuid" property is not applicable and must
	NOT be used.</p>
	<p>All services require the "implementation-point" property. In this case, the property
	value is set to "external.</p>
	<p>All external services would normally require a "provided-by" link; however, a known
	bug in core OSCAL syntax prevents the use of this property at this time.</p>
	<p>If the leveraged system owner provides a UUID for their service (such as in an
	OSCAL-based CRM), it should be reflected in the <code>inherited-uuid</code>
	property.</p>
	</remarks>
	</component>

[aj-stein-gsa]

Just a heads up, @JoseGHdz, since you posed this as a question, I will only mark it blocked until I hear back from you as the author to ensure this helps. Since the answer involves completing and publishing the documentation, not the example, this question issue will not get resolved until those tasks are achieved. I will just want to check back with you on the interim and confirm this sample helps you. Either way, let us know.

[JoseGHdz]

Just a heads up, @JoseGHdz, since you posed this as a question, I will only mark it blocked until I hear back from you as the author to ensure this helps. Since the answer involves completing and publishing the documentation, not the example, this question issue will not get resolved until those tasks are achieved. I will just want to check back with you on the interim and confirm this sample helps you. Either way, let us know.

This looks great! I just went through the sample documentation, and based on this example:

fedramp-automation/src/content/rev5/examples/ssp/xml/fedramp-ssp-example.oscal.xml

Lines 1023 to 1078 in 99f532f

	<component uuid="11111111-2222-4000-8000-009000500001" type="service">
	<title>Service A</title>
	<description>
	<p>An authorized service provided by the Awesome Cloud leveraged authorization.</p>
	<p>Describe the service and what it is used for.</p>
	</description>
	<prop name="leveraged-authorization-uuid" value="11111111-2222-4000-8000-019000000001"/>
	<prop name="implementation-point" value="external"/>
	<prop ns="https://fedramp.gov/ns/oscal" name="information-type" value="C.3.5.1"/>
	<prop ns="https://fedramp.gov/ns/oscal" name="information-type" value="C.3.5.8"/>
	<link rel="provided-by" href="#11111111-2222-4000-8000-009000100001"/>
	<status state="operational"/>
	<responsible-role role-id="administrator">
	<prop name="privilege-uuid" value="11111111-2222-4000-8000-008000000004" ns="https://fedramp.gov/ns/oscal" />
	<prop name="privilege-uuid" value="11111111-2222-4000-8000-008000000005" ns="https://fedramp.gov/ns/oscal" />
	</responsible-role>
	<remarks>
	<p>This is a service offered by a leveraged system and used by this system.
	It is explicitly listed on the FedRAMP marketplace as being included in the
	scope of this leveraged system's ATO, thus is considered an "Authorized Service.</p>
	<p/>
	<p>Each leveraged service must be expressed as a "service" component, and must have:</p>
	<ul>
	<li>the name of the service in the title - exactly as it appears in the FedRAMP
	Marketplace</li>
	<li>a "leveraged authorization-uuid" property that links this component to the
	leveraged-authorization entry</li>
	<li>an "implementation-point" property with a value of "external"; and</li>
	<li>a "provided-by" link with a URI fragment that points to the
	"system" component representing the leveraged system. (Example: <code>"#11111111-2222-4000-8000-009000100001"</code>)
	</li>
	</ul>
	<p/>
	<p>Where relevant, this component should also have:</p>
	<ul>
	<li>One or more "information-type" properties, where the allowed values are the 800-63
	information type identifiers.</li>
	<li>At least one responsible-role that indicates the authorized userswith a role-id of "leveraged-authorization-users" and exactly
	one or more party-uuid entries that indicates which users within this system may
	interact with the leveraged systeme.</li>
	<li>An "inherited-uuid" property if the leveraged system's owner provides a UUID for
	their system (such as in an OSCAL-based CRM).</li>
	</ul>
	<p>Link(s) to the vendor's web site describing the service are encouraged, but not
	required.</p>
	<p>The following fields from the Leveraged Authorization Table are handled in the
	leveraged-authorization assembly:</p>
	<ul>
	<li>Package ID, Authorization Type, Impact Level</li>
	</ul>
	<p/>
	<p>The following fields from the Leveraged Authorization Table are handled in the
	"system" component representing the leveraged system as a whole:</p>
	<p>- Nature of Agreement, CSP Name</p>
	</remarks>
	</component>

It’s pretty similar to what I have, and I can see the changes I need to make.

One thing I noticed: The validation error is currently pointing to the root level, which makes it harder to track down the exact component that needs fixing for the "privilege-uuid".

Would it be possible to have the error reported at the /system-security-plan/system-implementation/components level instead of /system-security-plan? That would make it much easier to pinpoint where the issue is with the validation tool.

[aj-stein-gsa]

We appreciate the feedback that is a sensible request. I will follow up later today or tomorrow with a comment about the decision and status updates if we make a code change. I'd say that it is quite likely we'll do that, @JoseGHdz. 😁

[JoseGHdz]

We appreciate the feedback that is a sensible request. I will follow up later today or tomorrow with a comment about the decision and status updates if we make a code change. I'd say that it is quite likely we'll do that, @JoseGHdz. 😁

Awesome! Thanks for all the help. I really appreciate it.

[aj-stein-gsa]

Would it be possible to have the error reported at the /system-security-plan/system-implementation/components level instead of /system-security-plan? That would make it much easier to pinpoint where the issue is with the validation tool.

I just wanted to follow up after the last few days of issues. I thought your follow-on request was for path retargeting was in #999, but it seems not. You still want this change, but I should open it up in a separate issue, correct? I just wanted to make sure I understood constraint changes and documentation touch-ups we do based upon the issue original reported here, @JoseGHdz. Thanks!

[JoseGHdz]

Would it be possible to have the error reported at the /system-security-plan/system-implementation/components level instead of /system-security-plan? That would make it much easier to pinpoint where the issue is with the validation tool.

I just wanted to follow up after the last few days of issues. I thought your follow-on request was for path retargeting was in #999, but it seems not. You still want this change, but I should open it up in a separate issue, correct? I just wanted to make sure I understood constraint changes and documentation touch-ups we do based upon the issue original reported here, @JoseGHdz. Thanks!

I wanted to clarify the difference between issue #999 and issue #977.

Issue #999 was about a specific error I ran into, whereas issue #977 is more focused on how the validation system reports those errors.

After digging deeper, I realized the problem with #999 was actually on my end. I missed a key detail in the documentation that Leveraged Authorization linking can only be applied to items of type "system", not "service". Since I was using AWS and Azure services in the components section, I had set their type to "service", which caused the error. That’s why I ended up closing #999.

However, this ties directly back to issue #977. The validation system didn’t give me enough information to figure out where the problem was or how to fix it. Instead, the error was just pointed at the root item, which made it harder to identify the actual issue.

I hope this helps clarify things. It also highlights how improving the validation system’s feedback would make it a lot easier to track down and fix these kinds of errors.