Documentation for implemented-requirement prop leveraged-authorization in SSP is unclear

[aj-stein-nist]

Describe the bug

As an OSCAL tool developer, in order to understand when and how to annotate a control implementation with a property to indicate the control implementation requirement is fulfilled in whole or in part by control implementations from a leveraged authorization, I want clear documentation of the intended value for that prop.

Who is the bug affecting

OSCAL tool developers implementing SSPs leveraging a leveraged authorization, specifically @telosBA and their colleagues as reported on a feedback call.

What is affected by this bug

Documentation

How do we replicate this issue

1. Read the current documentation on the implemented-requirement/prop[@name='leveraged-authorization'].
2. Review the source code definition for the prop in this context of the SSP model.
3. Observe the kind of value (boolean? UUID?), recommended values, or constraints, are unclear.

Expected behavior (i.e. solution)

Documentation clearly explains what the intended value of this prop in this particular context of the SSP model.

Other comments

Thanks to @telosBA and company for the verbal report when providing feedback to us.

[david-waltermire]

This relates to inheritance:type in #1385, which would indicate the degree of inheritance.

[david-waltermire]

To address this we need a clear understanding of how to document, in OSCAL, that a given requirement is implemented using a leveraged authorization. This should involve the by-component/inherited object. This means the prop identified may be misplaced. We need to work up an example of how to properly do this in OSCAL and then figure out what changes are needed.

[aj-stein-nist]

Community member collaborating with FedRAMP says they will update with examples soon enough.

[Compton-US]

@aj-stein-nist I claimed this for the sprint, but if we are expecting someone else to still deliver content, let me know.

[aj-stein-nist]

It appears the first commit this prop was introduced, not just relocated or modified, is 284e56f.

[aj-stein-nist]

So there is no constraint for this prop and the documentation string has been there as-is, albeit it with some typo improvements, since 2+ years ago. It appears to have come after the addition of the by-component where you can have specific requirement breakdown for any component with one or many inherited assemblies attached under the location of the prop.

Since the only report we received from users is a clarifying question about how to use it, and presumably it is unclear how and if to use it, and removing it is not a backwards breaking change, I will open a PR to consult the team for final review and approval.

/cc @Compton-NIST (I know you had picked this up and have looked at related work, I would like your feedback on the PR if you have time for it.)

[aj-stein-nist]

Once #1726 shakes out, I can then unblock this and merge to close this sprint. Wait, I take back the previous statement: that's not true, this is good to go for now as it points to develop and it shouldn't touch that work.