Simplify combiner parameters

[steven-legg]

There are four varieties of combiner parameters yet none of the standardized combining algorithms take parameters. The four varieties are CombinerParameters, PolicySetCombinerParameters, PolicyCombinerParameters and RuleCombinerParameters.

The question arises, does any non-standard combining algorithm use them?

[steven-legg]

There is a non-trivial amount of XSD for something no one seems to be using.

We can simplify the XSD if we remove combiner parameters completely, but we can simplify things a bit for XACML 4.0 while keeping the functionality for anyone who happens to be making use of combiner parameters and wants to migrate to XACML 4.0.

We drop PolicySetCombinerParameters because of the merger of PolicySet into Policy. PolicyCombinerParameters and RuleCombinerParameters extend CombinerParameters by adding an XML attribute identifying a policy or rule, respectively, by ID. Since CombinerParameters is a list of arbitrary CombinerParameter elements that wrap an XACML attribute and apply a parameter name, the task of the policy and rule identifying XML attributes in PolicyCombinerParameters and RuleCombinerParameters could be taken on by a CombinerParameter instead. Thus we can drop PolicyCombinerParameters and RuleCombinerParameters as well, leaving only CombinerParameters. A CombinerParameter element is more verbose than an XML attribute, but this is a capability no one seems to be making use of anyway.

We could choose to set aside two combiner parameter names for indicating policy and rule IDs and describe how they are intended to be used, or not worry about it and leave it to the implementer to come up with a solution for their non-standard combining algorithm . There isn't a need for consistency between different, non-standard combining algorithms.

[cdanger]

On my side, I don't know and don't have any use case for PoliyCombinerParameters and RuleCombinerParameters, therefore I welcome any simplification of the schema there :-) . I am not sure what xml schema you have in mind in your third paragraph though, maybe give an example of what it would lok like?

In the meantime, I see one possibility to merge all xxxCombinerParameters into CombinerParameters using a type like this (also considering there's no more PolicySet in xacml 4.0):

<xs:complexType name="CombinerParametersType">
   <xs:sequence>
          <xs:choice minOccurs="0">
                <xs:element name="RuleIdRef" type="xs:string"/>
                <xs:element name="PolicyIdRef" type="xs:anyURI"/>
          </xs:choice>
          <!--  I changed minOccurs from 0 (XACML 3.0 schema) to *1* below because having CombinerParameters with zero CombinerParameter makes no sense (yet another issue in the XSD) -->
          <xs:element ref="xacml:CombinerParameter" minOccurs="1" maxOccurs="unbounded"/>
   </xs:sequence>
</xs:complexType>

If we add the constraint that a Rule ID must be different from any sibling Policy ID, i.e. any Rule/Policy ID is unique (within the same parent Policy), then we can simplify:

<xs:complexType name="CombinerParametersType">
   <xs:sequence>
          <xs:element ref="xacml:CombinerParameter" minOccurs="1" maxOccurs="unbounded"/>
   </xs:sequence>
   <!-- Replaces PolicyIdRef/RuleIdRef. The ID is enough to identify the Policy/Rule because of the constraint. -->
   <xs:attribute name="CombinedElementIdRef" type="xs:string" />
</xs:complexType>

[steven-legg]

I am not sure what xml schema you have in mind in your third paragraph though, maybe give an example of what it would look like?

The first part was suggesting adding RuleIdRef and PolicyIdRef as optional XML attributes to CombinerParametersType with a constraint in prose that both can't be present. The simpler syntax is to leave CombinerParametersType alone and reserve RuleIdRef and PolicyIdRef as ParameterName values for a CombinerParameter element with standardized meanings. So do this:

<CombinerParameters>
  <CombinerParameter ParameterName="RuleIdRef>
    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MyRule</AttributeValue>
  </CombinerParameter>
  <!-- More Parameters ->
</CombinerParameters>

instead of this:

<RuleCombinerParameters RuleIdRef="MyRule">
  <!-- More Parameters ->
</RuleCombinerParameters>

A combiner parameter can be anything, including a reference to a rule or a reference to a policy. The meaning can be anything, including "only apply the other parameters to the identified rule" (or policy). The policy reference would be anyURI type.

[steven-legg]

If we add the constraint that a Rule ID must be different from any sibling Policy ID, i.e. any Rule/Policy ID is unique (within the same parent Policy)

Slightly off on a tangent ...

I can't find any statement in the core that rule IDs have to be unique within the same policy, though it is a reasonable expectation, and RuleCombinerParameters seems to be the only place where it matters - maybe. Would it really hurt if someone gave a bunch of rules the same ID so that the same set of parameters would apply to each of them? Similarly, if we make RuleIdRef and PolicyIdRef parameter names then would it really hurt if someone listed multiple RuleIdRef and PolicyIdRef parameters in the same CombiningParameters element with the intention that the set of parameters would apply to all of them?

There's no compelling reason to insist on rule IDs being unique within a policy and no compelling reason not to. We might do it for completeness.

[cdanger]

Well, just a question of semantics for me, using the term ID is a bit misleading if it's not unique in some scope. It's something else then, just a name. But also on my side, we use the RuleID for logging/troubleshooting purposes, when developers want to identify precisely which rule is being evaluated, which rule is causing the error (it's more user-friendly than just logging the index of the rule in the list for instance).

[steven-legg]

Okay, we explicitly state that RuleID has to be unique within a policy and we allow multiple RuleIdRef and PolicyIdRef parameters in a CombiningParameters.