Walkthrough of multiple profile (related to public review issue #11)

All,

(I am mailing this in HTML since some of the lines are long, and I
don't want them to be cut off. I hope this works.)

One issue which was brought up several times during the TC call
yesterday was that some TC members said that the multiple resource
profile does not define in any normative manner how the XPath based
multiple request is divided into individual requests. I don't agree, so
here is a walkthrough of an example with references to the
specification.

The relevant section is 2.2 of the multiple resource profile. I am
using the PDF version of the CD-1, so line numbers refer to it.

Section 2.2.2 describes the original request context. This says that
the resource-id must be an XPath expression over the <Content>
element of the resource category. The scope attribute must be
"XPath-expression". Here is an example of such a request:

<Request

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

            <AttributeValue

              DataType="http://www.w3.org/2001/XMLSchema#string"

              >Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

            <md:record>

                <md:patient_info>

                    <md:name>Bart Simpson</md:name>

                </md:patient_info>

                <md:diagnosis_info>

                    <md:diagnosis>

                        <md:item type="primary">Gastric
Cancer</md:item>

                    </md:diagnosis>

                </md:diagnosis_info>                

            </md:record>

        </Content>

        <Attribute

              IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

            <AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

             
>md:record/descendant-or-self::node()</AttributeValue>

        </Attribute>

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">

            <AttributeValue

             
DataType="http://www.w3.org/2001/XMLSchema#string">XPath-expression</AttributeValue>

        </Attribute>

    </Attributes>

</Request>

Section 2.2.3 of the spec, lines 137-139, say that each node selected
by the XPath expression shall be considered as an individual request.
The rest of section 2.2.3 specifies how the individual requests are
produced. It simply states that each individual request is identitical
to the above request, except that the scope attribute is not present
and that the resource-id is replaced with an xpath which points to the
individual resource (each in turn).

There is no normative statement about the exact form of this XPath
expression, except that it must identify an individual node. Issue #11
from the public review concerns this XPath expression. As will be
clear, its exact form does not matter, which is the reason the
specification does not specify a particular form.

The Axiomatics implementation constructs the expression by referencing
the nodes by their order in the tree, so in our implementation the
individual requests look like this:

<Request

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

            <AttributeValue

              DataType="http://www.w3.org/2001/XMLSchema#string"

              >Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

            <md:record>

                <md:patient_info>

                    <md:name>Bart Simpson</md:name>

                </md:patient_info>

                <md:diagnosis_info>

                    <md:diagnosis>

                        <md:item type="primary">Gastric
Cancer</md:item>

                    </md:diagnosis>

                </md:diagnosis_info>                

            </md:record>

        </Content>

        <Attribute

              IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

            <AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

              >./*[1]/*[1]/*[1]</AttributeValue>

        </Attribute>

    </Attributes>

</Request>

For each individual request, the XPath expression "./*[1]/*[1]/*[1]"
will be different, like "./*[1]/*[1]/*[1]/text()[1]", "./*[1]/*[2]" and
so on, covering all nodes selected by the original XPath expression.
Other implementations may use another form, but this form is easy to
produce since we don't need to track element names, namespaces, etc,
just their order.

Somebody mentioned XML overhead before, so I will note that there is no
reason to construct each individual XML document in their entirety,
rather one can point to pieces of the orignial XML and keep a small
chache on the side for the resource-id value. So there is not really
any overhead to it. (In XACML 2.0 it is necessary to construct the full
<Request> XML since an XPath could be used to refer to any part
of it. That is not allowed in XACML 3.0, so the implementation can be
efficient.)

A policy could look like this:

<Policy

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record"

      PolicyId="urn:FIXME:policy1"

     
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

    <Target/>

    <Rule

          RuleId="urn:FIXME:rule1"

          Effect="Permit">

        <Target>

            <AnyOf>

                <AllOf>

                    <Match

                         
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

                        <AttributeValue

                             
DataType="http://www.w3.org/2001/XMLSchema#string">Julius
Hibbert</AttributeValue>

                        <AttributeDesignator

                             
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

                             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

                             
DataType="http://www.w3.org/2001/XMLSchema#string"/>

                    </Match>

                </AllOf>

            </AnyOf>

            <AnyOf>

                <AllOf>

                    <Match

                         
MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

                        <AttributeValue

                             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

                             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">

                              md:record/md:patient_info

                        </AttributeValue>

                        <AttributeDesignator

                             
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

                             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

                             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>

                    </Match>

                </AllOf>

            </AnyOf>

        </Target>

    </Rule>

</Policy>

This policy will allow Julius Hibbert access to the patient_info
section of the medical record, but not the rest. Note how the policy
uses an xpath match function, so the exact form of the xpath expression
is not significant.

So, there will be results like this:

The md:record/md:diagnosis element:

  <xacml-ctx:Result>

    <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[2]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>

The string "Bart Simpson":

  <xacml-ctx:Result>

    <xacml-ctx:Decision>Permit</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[1]/*[1]/text()[1]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>

The resource-id is part of the <Result>s since the original
resource-id has IncludeInResult="true", see the lines 144-147 in the
spec.

So, it is not true that the specification does not have any normative
statements of how the XPath "variant" works. Personally I also think
the text is quite clear. I can agree that the spec is not good learning
material, but I don't think that is the role of standard specification
since good learning material needs to be verbose and redundant because
one needs examples and different ways to explain the same thing to help
learning. But those are qualities which are undesirable in a technical
specification, so I would like to keep the text as it is.

Best regards,

Erik