[xacml] Proposal on comparison for target

[Michiharu Kudoh <KUDO@jp.ibm.com>]

The following is my proposal on comparisons for target expression.

A) Summary of Issues
1. The current draft does not fully address the semantics of the equality
written in the target section. For example, there is no description about
when the XPath returns a sequence of nodes.

2. The current draft does not support how to specify the regular expression
as a pattern matching. We need to distinguish a pattern matching from the
string comparison. For example, a string like "abc.xml" means both a normal
text string and a regular expression with the meta character of ".".

3. The current draft does not describe the semantics when two or more
AttributeDesignator are specified in each target.

4. We may need to support the semantics for the "deep-equal" and the
"sequence-deep-equal" defined in XPath 2.0 for supporting a perfect
structural match.


B) Proposals
1. We borrow the semantics of the comparison from XPath 2.0. We aims more
simplicity by assuming that the data types are specified by a policy
writer. I copied the description below (*)

2. We specify a Base attribute in the AttributeDesignator for specifying
the exact comparison semantics. For example, when the comparison is a
normal string comparison, the Base is "string-equal". When the comparison
uses a typical regular expression matching, the Base is "regexp-match". The
semantics of the target is easily implied by the Base attribute that
indicates the function if it is specified in the condition section. The
Base attribute allows users to extend it to a local equality implementation
such as "X500-equal".

3. Multiple AttributeDesignators are connected by AND.

4. "deep-equal" and "sequence-deep-equal" may be supported as user-defined
comparison pattern in the Target section. If that is the case, the Base is
specified as "deep-equal" and "sequence-deep-equal".

C) Example Policy in English

- Policy D1 has one rule. Target consists of <Subjects>, <Resources> and
<Actions> sections.
<Subjects> section compares "12345678" with the referenced value of the
SubjectId using numeric-equal semantics. If two values are identical, this
rule is applicable w.r.t. the subject equality.

<Resource> section consists of two equalities: a regular expression for
file name matching and an equality on the name of the root element. The
first compares the ResourceURI attribute with the regular expression
"patient[A-E]*.xml". For example, patientA123.xml matches this pattern. The
second compares "record" with the reference value of the attribute value of
the root element. If both equalities are satisified by AND, this rule is
applicable w.r.t. the resource equality.

<Actions> section compares "read" action with the value written in the
Context. If two values are identical, this rule is applicable w.r.t. the
action equality.

- Policy D2 has one rule. Target consists of <Subjects> section.
<Subjects> section compares "o=research c=us" with the values specified in
the SubjectId. X500-equal is a user-defined equality function.


D1) Proposed XACML Target Specification

<Rule>
  <Target>
    <Subjects>
      <AttributeDesignator Base="numeric-equal" DataType="xs:integer"
Designator="/Request/Subjects/SubjectId[@Format='SerialNumber']>
        <AttributeValue DataType="xs:integer">12345678</AttributeValue>
      </AttributeDesignator>
    </Subjects>
    <Resource>
      <AttributeDesignator Base="regexp-match" DataType="xs:string"
Designator="/Request/Resources/ResourceSpecifier/@ResourceURI">
        <AttributeValue DataType="xs:string">patient[A-E]
*.xml</AttributeValue>
      </AttributeDesignator>
      <AttributeDesignator Base="string-equal" DataType="xs:string"
Designator="/Request/Resources/ResourceAttribute/AttributeMetaData[@Name
='Root']/../AttributeValue">
        <AttributeValue>record</AttributeValue>
      </AttributeDesignator>
    </Resource>
    <Action>
      <AttributeDesignator Base="string-equal" DataType="xs:string"
Designator="Request/Action[@Namespace='XMLAccessControl']">
        <AttributeValue DataType="xs:string">read</AttributeValue>
      </AttributeDesignator>
    </Action>
  </Target>
</Rule>

D2) Proposed XACML Target Specification

<Rule>
  <Target>
    <Subjects>
      <AttributeDesignator Base="X500-equal" DataType="xs:string"
Designator="/Request/Subjects/SubjectId[@Format='X500Name']>
        <AttributeValue DataType="xs:string">o=research
c=us</AttributeValue>
      </AttributeDesignator>
    </Subjects>
  </Target>
</Rule>


E) Notes
1. Since the Base attribute implies the data types of the two arguments, we
can omit the DataType attributes if it is not necessary.
2. In this proposal, I used just a string for the Base attribute. It should
be URI type to uniquely identify each semantics.

==========================
(*) Excerpt from XPath 2.0 Draft 19 (with some modifications)

- Value Comparisons (copied from Section 2.6.1 with many modifications at
step 3)
Value comparisons are intended for comparing single values. The result of a
value comparison is defined by applying the following rules, in order:

1. Atomization is applied to each operand, resulting in a single atomic
value or an empty sequence for each operand.
2. If either operand is an empty sequence, the result is an empty sequence.
3. Each operand has its data type. Each value is converted to the requested
type if necessary. Failure in type conversion raises type exception.
4. The result of the comparison is true if the value of the first operand
is equal to the value of the second operand; otherwise the result of the
comparison is false. B.2 Operator Mapping describes which combinations of
atomic types are comparable, and how comparisons are performed on values of
various types.

Here are some examples of value comparisons:
The following comparison is true only if $book1 has a single author
subelement and its value is "Kennedy": $book1/author eq "Kennedy"

- General Comparisons (copied from the description in Section 2.6.2)
General comparisons are defined by adding existential semantics to value
comparisons. The operands of a general comparison may be sequences of any
length. The result of a general comparison is always true or false.

The general comparison A = B is true for sequences A and B if the value
comparison a eq b is true for some item a in A and some item b in B.
Otherwise, A = B is false.

- Atomization (copied from Section 2.1.3.3)
Type conversions sometimes depend on a process called atomization, which is
used when an optional atomic value is expected. When atomization is applied
to a given value, the result is either a single atomic value, an empty
sequence, or a type exception. Atomization is defined as follows:

1. If the value is a single atomic value or an empty sequence, atomization
simply returns the value.
2. If the value is a single node, the typed value of the node is extracted
and returned; however, if the typed value is a sequence containing more
than one item, a type exception is raised.
3. In any other case, atomization raises a type exception.

- Typed Value (copied from Section 2.1.2.2)
Every node has a typed value, which is a sequence of atomic values. The
typed value of any node can be extracted by calling the data function with
the node as argument. The typed value for the various kinds of nodes is
defined as follows:

1. The typed value of a document, namespace, comment, or processing
instruction node is the error value.
2. The typed value of a text node is the string content of the node, as an
instance of xs:anySimpleType.
3. The typed value of an element or attribute node that has no type
annotation is a sequence of atomic values that is stored in the Data Model.
4. The typed value of an element or attribute node whose type annotation
denotes either a simple type or a complex type with simple content is a
sequence of atomic values that is obtained by applying the type annotation
to the content of the node, as in the following examples:

Example: N is an element node of type hatsizelist, which is a complex type
that includes a country attribute. The content of the type hatsizelist is a
sequence of items of type hatsize, which is derived from xs:decimal. In XML
Schema, this content is considered to have a simple type. The typed value
of N is a sequence of values of type hatsize.

Example: A is an attribute of type IDREFS, a list type derived from IDREF,
and its value is "bar baz faz". The typed value of A is a sequence of three
atomic values of type IDREF.

The typed value of an element node whose type annotation denotes a complex
type with complex content is the error value.
==========================

Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428