Move XPath-related features out of the core spec to a new XACML profile

[cdanger]

Study the feasibility of removing all XPath-related features from the core spec and move them to a new profile, e.g. XPath Profile.

Rationale:

1. Simplify the core spec, esp. for implementers that have no interest in supporting XPath or XML Content at all, and similarly for policy writers that have no interest in using XPath expressions either.
2. Simplify the core XACML schema: move XPath-related XSD elements/types, to separate XSD if possible
3. Make the core spec more digestible as a general goal.

A significant part of the core XACML 3.0 spec is about XPath-related features which are all optional though. So for the reasons above, they could be moved out to a new profile. Here is the list:

1. Schema element (§10.2.1) to be removed: xacml:XPathVersion
2. Schema elements (§10.2.1) to be either removed or changed to abstract types (see last paragraph down below): xacml:AttributeSelector, xacml:PolicyDefaults, xacml:PolicySetDefaults, xacml:RequestDefaults
3. Data-type (cf. §10.2.7) urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
4. Functions (cf. §10.2.8) urn:oasis:names:tc:xacml:3.0:function:xpath-node-count, urn:oasis:names:tc:xacml:3.0:function:xpath-node-equal, urn:oasis:names:tc:xacml:3.0:function:xpath-node-match
5. Sections to be removed: 2.7, 4.2, 5.4, 5.5, 5.15, 5.30, 5.43, 6, A.3.15.
6. Sections to be reduced/simplified: 2.5, 2.11, 3.2, 3.3.1.1, 4.2.4 (rewrite the examples without AttributeSelector and xpath function / expression), 5.42, 7.3.1, 7.3.2, 7.3.4, 7.3.7, 7.20, 10.2.1, 10.2.7, 10.2.8, A.2, B.3.

Downside: this requires some effort to rewrite examples in 4.2.4 using XPath.

Instead of simply removing the schema elements xacml:AttributeSelector, xacml:PolicyDefaults, xacml:PolicySetDefaults, xacml:RequestDefaults from the core schema, we can keep them but make the definitions more generic / not XPath-specific, i.e. usable for any structured data-type (XML, JSON or whatever), and leave the datatype-specific definitions to separate XACML profiles (e.g. JSON Profile, XPath profile).

What does it mean exactly in terms of XML schema ? Here is a proposal:

Change the AttributeSelectorType and DefaultsType to abstract types in the core XACML schema (remove XPath specifics):

<xs:complexType name=”DefaultsType” abstract="true" />

<xs:complexType name="AttributeSelectorType" abstract="true">
   <xs:complexContent>
          <xs:extension base="xacml:ExpressionType">
                <xs:attribute name="Category" type="xs:anyURI" use="required"/>
                <!-- ContextSelectorId removed because XPath-specific (?) -->
                <!-- Remove the Path attribute? or consider this generic, i.e. applicable to any structured data type (XML has XPath, JSON has JSONPath, what else?) -->
                <xs:attribute name="Path" type="xs:string" use="required"/>
                <xs:attribute name="DataType" type="xs:anyURI" use="required"/>
                <xs:attribute name="MustBePresent" type="xs:boolean" use="required"/>
          </xs:extension>
   </xs:complexContent>
</xs:complexType>

Then in the new XPath profile, we would have:

<!-- Maybe it's time to use a XML enumeration type instead of anyURI! -->
<xs:element name="XPathVersion" type="xs:anyURI"/>

<xs:element name="XPathAttributeSelector" type="xacml:XPathAttributeSelectorType" substitutionGroup="xacml:AttributeSelector"/>
<xs:complexType name="XPathAttributeSelectorType">
   <xs:complexContent>
          <xs:extension base="xacml:AttributeSelectorType">
                  <xs:attribute name="ContextSelectorId" type="xs:anyURI" use="optional"/>
          </xs:extension>
   </xs:complexContent>
</xs:complexType>

<xs:element name="PolicyXPathDefaults" type="xacml:XPathDefaultsType" substitutionGroup="xacml:PolicyDefaults"/>
<xs:element name="RequestXPathDefaults" type="xacml:XPathDefaultsType" substitutionGroup="xacml:RequestDefaults"/>
<xs:complexType name="XPathDefaultsType">
   <xs:complexContent>
          <xs:sequence>
          <xs:choice>
                <xs:element ref="xacml:XPathVersion"/>
          </xs:choice>
   </xs:sequence>
   </xs:complexContent>
</xs:complexType>

Then in the JSON profile, we would have:

<!-- Maybe it's time to use a enumeration type instead of anyURI! -->
<xs:element name="JSONPathVersion" type="xs:anyURI"/>

<xs:element name="JSONPathAttributeSelector" type="xacml:JSONPathAttributeSelectorType" substitutionGroup="xacml:AttributeSelector"/>
<xs:complexType name="JSONPathAttributeSelectorType">
   <xs:complexContent>
          <xs:extension base="xacml:AttributeSelectorType">
                  <!-- Any parameter specific to JSONPath evaluation goes here -->
          </xs:extension>
   </xs:complexContent>
</xs:complexType>

<xs:element name="PolicyJSONPathDefaults" type="xacml:JSONPathDefaultsType" substitutionGroup="xacml:PolicyDefaults"/>
<xs:element name="RequestJSONPathDefaults" type="xacml:JSONPathDefaultsType" substitutionGroup="xacml:RequestDefaults"/>
<xs:complexType name="JSONPathDefaultsType">
   <xs:complexContent>
          <xs:sequence>
          <xs:choice>
                <xs:element ref="xacml:JSONPathVersion"/>
          </xs:choice>
   </xs:sequence>
   </xs:complexContent>
</xs:complexType>

Not sure this is all valid XSD. To be checked.

Regarding AttributeSelector, there is also the question whether we still need it in XACML 4.0 or we could remove it completely, and instead, use XACML functions for XML/JSON parsing and XPath/JSONPath evaluation (to be defined in XPath / JSON profiles).

[steven-legg]

Regarding AttributeSelector, there is also the question whether we still need it in XACML 4.0 or we could remove it completely, and instead, use XACML functions for XML/JSON parsing and XPath/JSONPath evaluation (to be defined in XPath / JSON profiles).

The Entities profile defines an attribute selector function. The downside of a function representation is that it is much more verbose in XML because every XML attribute becomes an XACML expression, minimally an <AttributeValue> element.

[steven-legg]

2. Simplify the core XACML schema: move XPath-related XSD elements/types, to separate XSD if possible

Spreading the XSD for the same namespace over multiple files is awkward because some file needs to include the various bits. You would need a series of files to account for the different combinations of optional bits. It would be easier to combine all the XSD in the core XSD even if chunks of it are described elsewhere.

Using a different namespace in each XSD file (and assuming the profiles were extending abstract types in the core) avoids having to include anything but does require extra namespace declarations in the policy XML documents. Which, of course, is no cost to someone ignoring the profile.

[steven-legg]

Attribute designators and attribute selectors are instances of "attribute extracting things" so there could be an even more abstract base type.

[steven-legg]

Maybe it's time to use a enumeration type instead of anyURI!

When a new version of the path language comes along it would be necessary to update the enumeration type in the XSD to use it, forcing a new version. Using AnyURI avoids this.

[steven-legg]

JSONPathPolicyDefaults makes more sense to me as a name than PolicyJSONPathDefaults. Similarly for the other names. Do we even need to have "Policy" in the names?

Incidentally, I prefer to keep acronyms fully capitalized in names, so "JSONPath" rather than "JsonPath".

[cdanger]

Regarding AttributeSelector, there is also the question whether we still need it in XACML 4.0 or we could remove it completely, and instead, use XACML functions for XML/JSON parsing and XPath/JSONPath evaluation (to be defined in XPath / JSON profiles).

The Entities profile defines an attribute selector function. The downside of a function representation is that it is much more verbose in XML because every XML attribute becomes an XACML expression, minimally an <AttributeValue> element.

Agreed.

Using a different namespace in each XSD file (and assuming the profiles were extending abstract types in the core) avoids having to include anything but does require extra namespace declarations in the policy XML documents. Which, of course, is no cost to someone ignoring the profile.

Yes, I'd rather use a different namespace for each profile, they would not be part of the core schema (but would import it since they extend AttributeSelectorType, DefaultsType).

Maybe it's time to use a enumeration type instead of anyURI!

When a new version of the path language comes along it would be necessary to update the enumeration type in the XSD to use it, forcing a new version. Using AnyURI avoids this.

I get that, but since the allowed XPath URIs are listed explicitly in section 5.5. of the specification document anyhow, we would have to update it to include the new version URI, so why not update the XSD in the process. Or we could stop listing the XPath version URIs in the spec, and everyone could use any XPath version they want. Not sure about the consequences of that.

JSONPathPolicyDefaults makes more sense to me as a name than PolicyJSONPathDefaults. Similarly for the other names. Do we even need to have "Policy" in the names?

I don't think we need, but in the current schema, there is RequestDefaults and PolicyDefaults (why? I have no clue), that's something else we could simplify btw.

So replacing all this with JSONPathDefaults and XPathDefaults is perfectly fine by me.

[steven-legg]

I get that, but since the allowed XPath URIs are listed explicitly in section 5.5. of the specification document anyhow, we would have to update it to include the new version URI, so why not update the XSD in the process.

Because the XPath version change after that would require a new XSD with a new namespace, even for implementions that have no interest in supporting XPath.

There's no reason the supported XPath versions have to be mentioned in the core. A separate XPath profile can do that and that profile can be updated for a new version without affecting the core or the XSD if the version is indicated with a URI. If we arrange for the version to be an enumerated type defined in the profile then adding a new version will still require a new XSD with a new namespace for the implementations that do choose to implement XPath. It's a lot of disruption for the sake of an extra constant.

[steven-legg]

I don't think we need, but in the current schema, there is RequestDefaults and PolicyDefaults (why? I have no clue), that's something else we could simplify btw.

I imagine PolicySetDefaults, PolicyDefaults and RequestDefaults were created as places to gather various defaults, which would not necessarily be the same set of things across the three contexts. As it happened, XPathVersion was the only default setting that eventuated and it was the same across the three contexts. We may well add a JSONPathVersion, but it wouldn't be needed in RequestsDefaults unless we analogously define a JSONPathExpression data type.

[cdanger]

I get that, but since the allowed XPath URIs are listed explicitly in section 5.5. of the specification document anyhow, we would have to update it to include the new version URI, so why not update the XSD in the process.

Because the XPath version change after that would require a new XSD with a new namespace, even for implementions that have no interest in supporting XPath.

There's no reason the supported XPath versions have to be mentioned in the core. A separate XPath profile can do that and that profile can be updated for a new version without affecting the core or the XSD if the version is indicated with a URI. If we arrange for the version to be an enumerated type defined in the profile then adding a new version will still require a new XSD with a new namespace for the implementations that do choose to implement XPath. It's a lot of disruption for the sake of an extra constant.

Yes, one more reason to do a separate XPath (XML even?) profile with its own XSD namespace. But in that case, it would not be necessary to change the namespace to support a new XPath version URI. It is just adding a new possible value in the enumeration, therefore a minor / backward-compatible change (all currently valid documents would still be valid with the new schema). In this case, we can use a different XSD versioning practice as recommended here: http://www.xfront.com/Versioning.pdf

[steven-legg]

It is just adding a new possible value in the enumeration, therefore a minor / backward-compatible change (all currently valid documents would still be valid with the new schema). In this case, we can use a different XSD versioning practice as recommended here: http://www.xfront.com/Versioning.pdf

Each of those options has drawbacks. They all start from the presumption that the XSD has to be updated. If we use a URI to indicate the XPath version then the XSD doesn't need to change and we avoid all the drawbacks.