Practicalities in the XACML 3.0 schema

[Erik Rissanen <erik@axiomatics.com>]

All,

Currently the XACML 3.0 schema policy type looks like this:

    <xs:element name="Policy" type="xacml:PolicyType"/>
    <xs:complexType name="PolicyType">
        <xs:sequence>
            <xs:element ref="xacml:Description" minOccurs="0"/>
            <xs:element ref="xacml:PolicyIssuer" minOccurs="0"/>
            <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
            <xs:element ref="xacml:CombinerParameters" minOccurs="0"/>
            <xs:element ref="xacml:Target"/>
            <xs:choice maxOccurs="unbounded">
                <xs:element ref="xacml:CombinerParameters" minOccurs="0"/>
                <xs:element ref="xacml:RuleCombinerParameters" 
minOccurs="0"/>
                <xs:element ref="xacml:VariableDefinition"/>
                <xs:element ref="xacml:Rule"/>
            </xs:choice>
            <xs:element ref="xacml:Obligations" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
        <xs:attribute name="Version" type="xacml:VersionType" 
default="1.0"/>
        <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" 
use="required"/>
        <xs:attribute name="MaxDelegationDepth" type="xs:integer" 
use="optional"/>
    </xs:complexType>

Note that the xacml:CombinerParameters element occurs twice. (It's like 
that in XACML 2.0 as well.) Is there a reason for this? It seems 
redundant to me since the specification document says that if there are 
multiple CombinerParameters elements, they should be considered as  a 
single concatenated element.

It's a construct which makes at least JAXB fail on the schema, so unless 
there is a good reason for keeping it like this, I suggest we change it 
to make things easier for developers. The change I suggest is that we 
remove the first occurrence in the schema. Like this:

    <xs:element name="Policy" type="xacml:PolicyType"/>
    <xs:complexType name="PolicyType">
        <xs:sequence>
            <xs:element ref="xacml:Description" minOccurs="0"/>
            <xs:element ref="xacml:PolicyIssuer" minOccurs="0"/>
            <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
            <xs:element ref="xacml:Target"/>
            <xs:choice maxOccurs="unbounded">
                <xs:element ref="xacml:CombinerParameters" minOccurs="0"/>
                <xs:element ref="xacml:RuleCombinerParameters" 
minOccurs="0"/>
                <xs:element ref="xacml:VariableDefinition"/>
                <xs:element ref="xacml:Rule"/>
            </xs:choice>
            <xs:element ref="xacml:Obligations" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
        <xs:attribute name="Version" type="xacml:VersionType" 
default="1.0"/>
        <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" 
use="required"/>
        <xs:attribute name="MaxDelegationDepth" type="xs:integer" 
use="optional"/>
    </xs:complexType>

I am not sure if the right thing is to remove the first occurrence, 
rather than the second. My line of reasoning is that we want to make the 
Policy and PolicySet elements similar to each other. The PolicySet 
already contains only one occurrence of the CombinerParameters element 
in the schema, and it is within the choice element. So we should keep a 
similar format for the Policy. (And we shouldn't change the PolicySet 
since this way it will be the same as in 2.0, which is good since that 
means one less thing to trip on in the 2.0 -> 3.0 migration.)

Another issue with the XACML 3.0 schema: The schema contains a few 
default values for attributes. I have been thinking that maybe we should 
change these attributes to mandatory rather than defaults? The 
attributes are the <PolicySet> and <Policy> "Version" attributes and the 
"MustBePresent" attributes in <AttributeSelector> and <AttributeDesignator>

The problem with default XML attributes is that doing schema validation 
fills in them automatically, while parsing the XML without the schema 
does not do so. The default attributes are significant in an XML 
signature, which means that signatures will differ depending on whether 
the parsing was done with or without schema, unless the default 
attributes are filled in manually.

It's perhaps not a big deal, but schema validation does present a 
significant overhead and it would be nice if XACML could be parsed and 
signed without having to worry about the schema validation just because 
of the signature. And it's one less thing that can go wrong in product 
interoperability. :-)

What do you think?

And just to be clear: All proposed changes are for XACML 3.0. (Not the 
2.0 errata.)

Regards,
Erik