usnistgov/oscal-content

IA-13 <param>'s have a different structure from the other controls

Closed this issue · 2 comments

Describe the bug

The new <param> elements under IA-13 have a different structure than all the other <param> elements.

See below the new IA-13 <param> elements

    <control class="SP800-53" id="ia-13">
      <title>Identity Providers and Authorization Servers</title>
      <param id="ia-13_prm_1">
        <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ia-13_odp.01"/>
        <label>organization-defined identification and authentication policy</label>
      </param>
      <param id="ia-13_prm_2">
        <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ia-13_odp.02"/>
        <label>organization-defined mechanisms</label>
      </param>      
      <param id="ia-13_odp.01">
        <prop name="label" class="sp800-53a" value="IA-13_ODP[01]"/>
        <label>policy</label>
        <guideline>
          <p>identification and authentication policy is defined;</p>
        </guideline>
      </param>
      <param id="ia-13_odp.02">
        <prop name="label" class="sp800-53a" value="IA-13_ODP[02]"/>
        <label>mechanisms</label>
        <guideline>
          <p>mechanisms supporting authentication and authorization decisions are defined;</p>
        </guideline>
      </param>

And for comparison, some params for AC-01

      <param id="ac-1_prm_1">
        <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ac-01_odp.01"/>
        <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ac-01_odp.02"/>
        <label>organization-defined personnel or roles</label>
      </param>
      <param id="ac-01_odp.01">
        <prop name="label" class="sp800-53a" value="AC-01_ODP[01]"/>
        <label>personnel or roles</label>
        <guideline>
          <p>personnel or roles to whom the access control policy is to be disseminated is/are defined;</p>
        </guideline>
      </param>
      <param id="ac-01_odp.02">
        <prop name="label" class="sp800-53a" value="AC-01_ODP[02]"/>
        <label>personnel or roles</label>
        <guideline>
          <p>personnel or roles to whom the access control procedures are to be disseminated is/are defined;</p>
        </guideline>
      </param>
      <param id="ac-01_odp.04">
        <prop name="alt-identifier" value="ac-1_prm_3"/>
        <prop name="label" class="sp800-53a" value="AC-01_ODP[04]"/>
        <label>official</label>
        <guideline>
          <p>an official to manage the access control policy and procedures is defined;</p>
        </guideline>
      </param>

For every control (except IA-13):

  • a <param> only has a "_prm" id if it aggregates 2 or more "_odp"'s (such as in ac-1_prm_1).
  • If an "_odp" is used in a control statement, then there is a <prop name="alt-identifier" ... > sub-element (such as in ac-01_odp.04".

This is not the case for IA-13, and each of the "_prm" elements aggregate only one "_odp" element.

What is affected by this bug?

Redundant to define these parameters twice, instead of just once with the "alt-identifier" methodology

Expected behavior (i.e. solution)

I think that these parameters should be replaced with something like the following:

    <control class="SP800-53" id="ia-13">
      <title>Identity Providers and Authorization Servers</title>
      <param id="ia-13_odp.01">
        <prop name="alt-identifier" value="ia-13_prm_1"/>
        <prop name="label" class="sp800-53a" value="IA-13_ODP[01]"/>
        <label>policy</label>
        <guideline>
          <p>identification and authentication policy is defined;</p>
        </guideline>
      </param>
      <param id="ia-13_odp.02">
        <prop name="alt-identifier" value="ia-13_prm_2"/>
        <prop name="label" class="sp800-53a" value="IA-13_ODP[02]"/>
        <label>mechanisms</label>
        <guideline>
          <p>mechanisms supporting authentication and authorization decisions are defined;</p>
        </guideline>
      </param>

This would be consistent with how the other controls elements are formatted

@Telos-sa - thank you for reporting the discrepancy. We will review it and address it .

Addressed by #228