OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Better description of Issue#57 XPath intersection problem

I still don't have a definitive solution to Issue#57, but at least I 
have entered a better description of the problem into the WIKI.  Here it 
is for those who want to read it here:

In Web Services, a Client and a Service Provider both have
requirements for interaction, and we need to know if those
requirements are compatible.  At a minimum, we need to determine
at least one specific set of parameter values that will satisfy
both the Client's and the Service Provider's policies.  Ideally,
we want to determine a new policy that will accept exactly those
sets of parameter values that would have been accepted by BOTH
the original policies, and that will reject all other sets of
parameter values.  Making this determination is what we call
"policy intersection."  If the policy requirements refer to XML
documents, at a minimum we need to determine at least one
specific XML document that will satisfy both original policies.
Ideally, we want a new policy that will accept all and only those
XML documents that would be accepted by both original policies.

WS-XACML allows the requirements in a Client or Service Provider
policy to be expressed using a list of <Apply> functions that
contain AttributeDesignators or AttributeSelectors.  The <Apply>
functions from each party specify the acceptable set of values
for each parameter or "Attribute" to be used in the interaction.
WS-XACML can efficiently create a new policy that meets the ideal
requirements for policy intersection: for each Attribute, it
specifies the set of values that is acceptable to both the Client
and the Service Provider.  From this new policy, it is easy to
create one or more specific sets of Attribute values that will
satisfy both parties.

In comparing requirements where AttributeDesignators are used,
WS-XACML knows that each AttributeId is associated with a unique
parameter that does not overlap with any other parameters.
WS-XACML thus compares the functions that apply to Attributes
having the same AttributeId values.  [By the way, this
restriction to non-overlapping parameters applies to XACML in
general.  For example, if one Boolean AttributeId was defined to
mean "isAManagerOrOfficer", and another Boolean AttributeId was
defined to mean "isAManager", an XACML PDP would not be able to
determine based only on the semantics it understands whether a
Client who submitted a value of "True" for "isAManager" satisfied
a policy that specified that "isAManagerOrOfficer" must be

In comparing requirements where AttributeSelectors are used,
WS-XACML runs into a problem: each XPath expression is not
associated with a unique parameter, but instead with a "nodeset"
- the set of nodes selected by the XPath expression in the
various XML documents against which it is evaluated; the various
nodes in the set may represent different parameters.  It is
possible that two different <Apply> functions using
AttributeSelectors may specify some requirements that apply to
the same nodes and some that apply to different nodes.

So with unrestricted XPath expressions in AttributeSelectors,
WS-XACML is unable to determine which <Apply> function
requirements should be compared with which other <Apply> function
requirements, and is also unable to determine exactly which XML
documents would satisfy both (and only) the original sets of

For this reason, we would like to define a restricted XPath
syntax such that

1) Two XPath expressions match, for example as string values, if
and only if they refer to exactly the same set of nodes in all
input XML documents.

2) Two XPath expressions that do not match will never select any
of the same nodes in any XML document.


Take the following two XPath expressions:
1) /C/text()
2) //A/B/C/text()

Take the following two Apply functions, representing requirements
from two different Web Service policies:

1) <Apply> function with //A/B/C/text()

    <Apply FunctionId="integer-subset">
        <AttributeSelector DataType="integer"
        <Apply FunctionId="integer-bag">

2) <Apply> function with /C/text()

    <Apply FunctionId="integer-subset">
        <AttributeSelector DataType="integer"
        <Apply FunctionId="integer-bag">

When these two <Apply> functions are evaluated against the
following document, the two AttributeSelector elements select
exactly the same nodes - those with values {3, 4} - and both
functions evaluate to "True":

     Request ResourceContent A:

       <B size="little">
       <B size="big">

When these two <Apply> functions are evaluated against the
following document, however, the two AttributeSelector elements
select overlapping nodes.  "//A/B/C/text()" will select the nodes
with values {3, 4} and will return "True".  "/C/text()" will
select the nodes with values {3, 4, 5} and will return "False".

     Request ResourceContent B:

       <B size="little">
       <B size="big">

Other known problems
1) Use of elements specified according to document order:
e.g. //A/B[2]/C/text() would overlap with "//A/B/C/text()".

2) Use of relative path expressions: e.g. /B/../C/text()

3) Use of XML attribute match functions in the XPath expression:
e.g. //A/B[@size="big"]/C/text() overlaps with "//A/B/C/text()".

Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]