SSP Leveraged Authorizations @name Attribute

[brian-ruf]

Describe the bug

Currently the SSP model requires the @name attribute on the leveraged-authorization field, and limits its contents to the NCName datatype.

After initial discussion and research it sounds as if the data type should be string, as it was intended to capture the system name.

Who is the bug affecting?

Anyone trying to model a leveraged authorization for a system.

What is affected by this bug?

Most system names have spaces, which are not allowed in an NCName.
Since this attribute can not accept a system name, there is no place to capture the name of the leveraged system. (Work-around has been to define a annotation with an @ns to capture the system name.)

When does this occur?

When trying to represent a leveraged authorization using the SSP model

How do we replicate the issue?

Try replacing "NCName" with a system name that has spaces.

      <leveraged-authorization id="lva-1" **name="NCName"**> 
         <party-id>party-bip</party-id>
         <date-authorized>2018-11-27</date-authorized>
      </leveraged-authorization>

Expected behavior (i.e. solution)

The @name attribute should accept a system name with spaces, and still validate correctly using the SSP model schema file.

Possibly, schema validation should also allow the @name attribute to be absent.

[brian-ruf]

This is also true of the @name attribute in the service assembly of the SSP model.
(/system-security-plan/system-implementation/service[1]/@name)

The @name attribute of the protocol assembly is also set to CName, but that may be intentional and might be OK.

The service and leveraged authorization assemblies need name fields that can have spaces and other characters not allowed in NCName. Either these need to be changed to string or a title field should be added to each assembly.

For now, I'm handling these with extensions:

      <leveraged-authorization id="lva-1" name="NCName"> 
         <annotation name="system-name" id="leveraged-01-name" ns="fedramp" value="MegaIaaS">
            <remarks><p>Remarks about this system</p></remarks>
         </annotation>
         <!-- cut -->
      </leveraged-authorization> 

and

      <service id="svc-1" name="ServiceName">
         <description><p>Purpose</p></description>
         <prop name="title" ns="fedramp">[SAMPLE]Service Name</prop>
         <!-- cut -->
      </service>

... and notes that the extensions may change depending on the solution here.

[brian-ruf]

In an email interaction with @wendellpiez on this topic, he said:

I am also concerned about the consistency of our modeling. It makes me uneasy if a common construct is not the same everywhere – for example, where @name is bound to NCName since it is expected to be a machine-readable token, vs where it needs to be a string so it can hold content.

<prop name=”billing_code”>A123</prop>
<prop name=”Billing Code”>A123</prop>

 The latter is frequently harder to process, because the @name attribute does double duty (I guess) both as a disambiguating token (what kind of property is this) vs a label for display.

If these elements need names for the second reason not the first, maybe a better solution is an element (such as ‘title’), or at least a different flag (attribute) with different semantics.

FWIW the component and SSP layers also have other inconsistencies with lower layers … as I noted yesterday on a comment on Issue #478….

I responded as follows:

I agree with what you are saying about @name in the context of prop, part, and annotation.
With an explicit element name like "leveraged-authorization", I am not sure how else I would use @name. Or at least is fair to say the ability to capture the name of the system is more important to me than the more typical use of @name in this context.

That said, your point is well taken. The use of @name should remain pure, and it sounds like I'm (unintentionally) trying to repurpose it here. 

I think to address both your concerns and mine, the following needs to happen:
@name should not be required for leveraged-authorization. (It is already not required for service)
A title (or system-name) element should be added as a child element under leveraged-authorization and service
  That allows @name to remain as you assert it should, while also addressing my need to capture the name of the system being leveraged.

(moving the conversation here)

[wendellpiez]

There are several elements in the SSP model where the @name flag (attribute) should probably be a title element, for consistency with similar structures elsewhere:

• information-type
• component
• privilege

This change is backward-incompatible, but it solves the data typing problem noted above.

These are also declared in the SSP Metaschema with flag@name='name' i.e. local overrides of the global flag declaration. As such they are also related to schema/docs bugs see #554, which will go away (for these flags) when this is repaired.

Data instances must also be repaired and an XSLT could be provided to upgrade data, if wanted.

[david-waltermire]

This is addressed in PR #619 where we moved name to title.