AW: [xacml] Re: XACML's limitations in the access control for XML documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath definition

["Jan Herrmann" <herrmanj@in.tum.de>]

Hi Erik,

thanks for your detailed reply. I added comments inline.
Best Regards 
Jan


> -----Ursprüngliche Nachricht-----
> Von: Erik Rissanen [mailto:erik@axiomatics.com]
> Gesendet: Donnerstag, 24. September 2009 14:35
> An: Jan Herrmann
> Cc: PTyson@bellhelicopter.textron.com; 'Rich.Levinson'; xacml@lists.oasis-
> open.org
> Betreff: [xacml] Re: XACML's limitations in the access control for XML
> documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath
> definition
> 
> Hi Jan,
> 
> Thanks for the effort you put into explaining this with such detail.
> 
> I can see that you mix two separate issues in here. One of them I agree
> is a real problem, though I am not sure what the ideal solution would be.
> 
> The first issue which you explain very well is that is difficult to
> write XACML rules which interrelate XML content within a single XML
> resource among multiple XML resources because the resources "mix up"
> with each other. You propose an offset to the AttributeSelector to fix
> this.

I am not sure if I understand this but your conclusion sounds good. I
believe that an AttributeSelector with a child element instead of the
RequestContextPath attribute will be very powerful. Note that this issue is
closely related to the second issue.

> 
> This issue is listed as number 16 among the comments we received during
> the public review. See here:
> 
> http://lists.oasis-open.org/archives/xacml/200909/msg00023.html

That is one of the comments I made during the public review phase. I was
describing it in more detail in the last mail because Paul asked for more
explanations...


> 
> I think we should do something about it, but I would like to wait past
> 3.0 since 3.0 has already been so delayed. I am not sure the right fix
> is the offset, so opening up technical work on this would delay 3.0 even
> more. Whatever solution we make could be done as a separate profile in
> the next batch of 3.0 documents (like metadata and so on).
> 
> To me the fundamental problem in this use case is that an XML resource
> like this breaks the XACML "assumption", if you permit the expression,
> that the request describes a single access request. The multiple
> <Resource>/<Attributes> elements approach does not have the same
> problem. Consider the following multiple request:
> 
> <Subject>subject-id=alice</Subject>
> <Resource>resource-id=documentA</Resource>
> <Resource>resource-id=documentB</Resource>
> 
> The above request is shorthand for a series of XACML requests, and an
> individual request like this would never reach the actual policy
> processing in the PDP, rather it would be pre-processed into these two
> requests:
> 
> <Subject>subject-id=alice</Subject>
> <Resource>resource-id=documentA</Resource>
> 
> <Subject>subject-id=alice</Subject>
> <Resource>resource-id=documentB</Resource>
> 
> Note how each individual request is about a single access request with a
> single subject and single resource, with no risk of mixing the resources
> up in the matching operations.
> 
> However, consider this multiple XML resource request instead:
> 
> <Subject>subject-id=alice</Subject>
> <Resource>
>   scope=xpath-expression
>   resource-id = book
>   <book>
>     <title>xxx</title>
>     <author>Bob</author>
>     <id>100</id>
>     <price>30</price>
>     <book-content>...</book-content >
>   <book>
>   <book>
>     <title>yyy</title>
>     <author>Alice</author>
>     <id>200</id>
>     <price>80</price>
>     <book-content >...</book-content >
>   <book>
> </Resource>
> 
> Now, this would be pre-processed into two separate requests like this:
> 
> <Subject>subject-id=alice</Subject>
> <Resource>
>   resource-id = book[1]
>   <book>
>     <title>xxx</title>
>     <author>Bob</author>
>     <id>100</id>
>     <price>30</price>
>     <book-content>...</book-content >
>   <book>
>   <book>
>     <title>yyy</title>
>     <author>Alice</author>
>     <id>200</id>
>     <price>80</price>
>     <book-content >...</book-content >
>   <book>
> </Resource>
> 
> and
> 
> <Subject>subject-id=alice</Subject>
> <Resource>
>   resource-id = book[2]
>   <book>
>     <title>xxx</title>
>     <author>Bob</author>
>     <id>100</id>
>     <price>30</price>
>     <book-content>...</book-content >
>   <book>
>   <book>
>     <title>yyy</title>
>     <author>Alice</author>
>     <id>200</id>
>     <price>80</price>
>     <book-content >...</book-content >
>   <book>
> </Resource>
> 
> Note how both these requests contain data about all resources, and the
> data can therefore be mixed up. The offset is one way to handle this,
> but, maybe it would be better to trim away the data of the other
> resources instead? Something like this:
> 
> 
> <Subject>subject-id=alice</Subject>
> <Resource>
>   resource-id = book
>   <book>
>     <title>xxx</title>
>     <author>Bob</author>
>     <id>100</id>
>     <price>30</price>
>     <book-content>...</book-content >
>   <book>
> </Resource>
> 
> and
> 
> <Subject>subject-id=alice</Subject>
> <Resource>
>   resource-id = book
>   <book>
>     <title>yyy</title>
>     <author>Alice</author>
>     <id>200</id>
>     <price>80</price>
>     <book-content >...</book-content >
>   <book>
> </Resource>
> 
> I don't know, which is better, but the second alternative would be
> closer to the original idea of XACML describing the attributes of a
> single attempted access, and there is less risk that a policy author
> would mix up the resources. However, I am sure there are complications
> with this approach as well.

The current version of the multiple and hierarchical resource profile
describes both approaches and from my point of view the first approach is
more relevant/interesting in the xml-resource use case. 
The profiles say that: The decision request should stay the same with two
exceptions:
1. the resource-id Attribute should match exactly one individual node and
2. the scope Attribute should be absent.

I would leave the profiles like this in this aspect. You can't divide the
xml-resource like you did for the book example in general. Each individual
element-, attribute- and text-node are the real resources. The reason why
they should still all be in the individual decision requests is that it is
necessary to define content dependant rights that depend on other
values/nodes/resources. 
Following the multiple and hierarchical resource profile of XACML Version
2.0 I strongly suggest to leave this like it is currently specified. 

I think what may be confusing is the use of the word resource for different
things.

From my point of view a resource is a xml node. The xml code included under
the content element (of category resource) is a set of resources -
hierarchically organised and consisting of multiple nodes and thus both
profiles apply. A XACML decision request can refer to multiple "resources"
in two different ways.
The first as you explained above really has two different <Resource>
elements. In fact I think that this was changed in xacml 3.0 ..but that’s
not important here and this case is clear anyway.

Second and more interesting from my point of view is the situation where you
have the real resources under the <content> element.   

If you take e.g. an Web Service request and response than both the requests
and the response can be XML documents (think e.g. of an XML based SQL
interface). In this use case a ws-request will be included in the XACML
decision request under content if you do access control on the web service
request. Similar if you do access control on the web-service response than
in a completely independent xacml decision request you add the web service
response to the xacml decision request under a content element...  

> 
> I am trying to say is that I have concerns about making a significant
> change like that without considering all the alternatives thoroughly.

I agree but I would take the position that it took nearly 5 years to come up
with a new XACML version so it is worth to spend some extra time (O(1-2
weeks) to add powerful features. By the way, within the OGC we did already a
lot of thinking in this direction in the last 5 years. Further I think that
the changes needed in the profiles are more minor but are still important
changes enhancing the expressivness. In fact as I read the current version
of the profiles, the baseline is already set up and thus it just needs some
further guidelines.   


> 
> Now, the second issue which was debated a lot on the list last week was
> the use of string matching vs xpath matching. See the thread here:
> 
> http://lists.oasis-open.org/archives/xacml/200909/msg00020.html
> 
> You use string matching in your example, but it would work better with
> the xpath functions instead, since you would avoid all the
> namespace/canonical form issues which stem from string matching. 

If I could use the xpath functions i would be happy but as i tried to
explain they do not offer enough expressiveness. I agree that the
namespace/canonical form issues have to be thought of for interoperability
reasons but as was said in this thread :
"When using XACML 3.0 functions related to XPath you MUST include namespace
definition(s)" so the namespace issue seems to be addressed already.
Further the canonical form thing is just a syntactical and more or less
obvious decision that everybody has to agree on.


> I still
> don't see the need of a strict format for xpath expressions generated by
> the PDP.

that is just the consequence and only needed in order to ensure that a pdp
from vendor A and the rules defined by distributed administrator (writing
rules for different pdp implementations) will be interoperable . 
Upfront it is important to agree that xpath is not powerfull enough to
express access rights in the xml resource use case.


Best regards jan

> 
> Best regards,
> Erik
> 
> 
> Jan Herrmann wrote:
> > Hi Paul, all
> >
> >
> >
> > in the following I try to explain some limitations of the current
> version of
> > the multiple and hierarchical resource profile and the core-spec in the
> > xml-resource use case. Then through an example I will show how the
> proposed
> > extensions could enhance the capabilities and expressiveness
> significantly.
> >
> >
> >
> > Baseline:
> >
> > - you are trying to control access to xml resources on a fine-grained
> level
> >
> > - contend dependant rules should be supported. i.e. it must be possible
> to
> > express access rights for a node that are dependant on the value of
> other
> > nodes
> >
> > - filtering should be supported. I.e. in case access to one (or some)
> > node(s) in the xml resource is denied, it should be possible to filter
> out
> > these nodes and return the accessible part of the xml-resource to the
> user
> >
> >
> >
> > Example Scenario:
> >
> > To simplify the discussion assume the following situation:
> >
> > You have xml docs looking like this one:
> >
> > <objects>
> >
> >   <book>
> >
> >     <title>xxx</title>
> >
> >     <author>Bob</author>
> >
> >     <id>100</id>
> >
> >     <price>30</price>
> >
> >     <book-content>...</book-content >
> >
> >   <book>
> >
> >   <book>
> >
> >     <title>yyy</title>
> >
> >     <author>Alice</author>
> >
> >     <id>200</id>
> >
> >     <price>80</price>
> >
> >     <book-content >...</book-content >
> >
> >   <book>
> >
> > </objects>
> >
> >
> >
> > This resource is included in a global decision request which looks like
> > this:
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >
> >
> > Further assume you try to define a rule, that denies access to book
> nodes,
> > if the book's price is higher than 50$ and the author OF THIS BOOK is
> the
> > requesting subject.
> >
> >
> >
> > A first try to define the needed rule could look like this:
> >
> > Approach 1:
> >
> > <Rule effect=Deny>
> >
> > .Any-Of(less-than, 50, AttributeSelector(/objects/book/price/text()) )
> AND
> > Any-Of(string-equals, string-one-and-only(AttributeDesignator(subject-
> id)),
> > AttributeSelector(/objects/book/author/text()) )
> >
> > </Rule>
> >
> >
> >
> > Unfortunately this rule doesn't implement the intended behaviour.
> >
> >
> >
> > Prob 1: filtering is not possible
> >
> > The XACML decision request & response refers to the XML resource as a
> whole.
> > What you actually need to allow filtering are access decision request
> and
> > responses for each individual node.
> >
> >
> >
> > Prob 2: The use of two and-ed Any-Of expressions destroys the semantical
> > relationships between the nodes
> >
> > If e.g. Bob is the requesting subject, than the rule will match and deny
> > access although Bob should be allowed to access the first and second
> book
> > element.
> >
> >
> >
> > Note that this problem could be solved, if you would allow the following
> > type of xpath expression in the AttributeSelector:
> >
> > Approach 2:
> >
> > integer-greater-than
> > (integer-one-and-
> only(AttributeSelector(count(/objects/book[price/text()>50
> > AND author/text() = AttributeDesignator(subject-id)])), 0).
> >
> > This is not possible as XACML constructs like the AttributeDesignator
> can't
> > be used inside the XPATH predicate.
> >
> >
> >
> > Another approach that is XPath conformant could therefore be:
> >
> > Approach 3:
> >
> > <Rule effect=Deny>
> >
> > .Any-Of(string-equals, string-one-and-only(AttributeDesignator(subject-
> id)),
> > AttributeSelector(/objects/book[ price/text() > 50]/author/text()) )
> >
> > </Rule>
> >
> >
> >
> > This rule should implement the intended access semantics but still has
> its
> > limitations:
> >
> > 1. The problem was solved through a mix of XACML constructs and XPath
> > predicates. To overcome the limitations parts of the XACML constructs
> were
> > shifted into the XPath predicate. Note that this worked in the example,
> as a
> > less-than or higher-than function is allowed in XPath predicates.
> > Unfortunately this means that XACML's functions are not eXtensible below
> the
> > functions supported by XPath.
> >
> > E.g. in the OGC GeoXACML use case we have added functions like within,
> > touches, disjoint and so on. As these functions are not supported by
> XPath
> > they can only be used in the extened form of XACML and this introduces
> > strong limitations in the expressiveness.
> >
> > 2. Assume you want to change the intended rule semantics to:
> >
> > deny access to a book node, if the book's price is higher than an XACML
> > Attribute A and the author OF THIS BOOK is the requesting subject
> >
> > This will prevent you from shifting the semantics into the XPath
> predicate
> > and thus will cause limited expressiveness.
> >
> >
> >
> > From my understanding using the xpath-match functions doesn't help
> solving
> > the problems mentioned above.
> >
> > Filtering will still not be possible and the problem that pointers to
> XACML
> > decision request data are not allowed inside an XPath predicate and the
> > problem that only predicates supported by XPath can be used still apply.
> >
> >
> >
> > The good news is that with very little changes to the profiles the
> problems
> > above can be solved.
> >
> >
> >
> > A solution could look like this:
> >
> >
> >
> > 1. A PDP receives a global decision request with
> >
> >     resource-id=/objects
> >
> >     scope=descendant
> >
> >     <content>. the xml resource </content>
> >
> >
> >
> >     The resource-id and scope Attribute specifies a set of nodes that
> are
> > the individual resources for which the access rights have to be checked.
> >
> >
> >
> > 2. Based on this global decision request the PDP generates individual
> > decision requests. - one for each individual node.
> >
> >     Thus the PDP generates the following decision requests:
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]/book[1]
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]/book[1]/title[1]
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]/book[1]/author[1]
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]/book[1]/price[1]
> >
> >             <content>.the xml resource </content>
> >
> >      </request>
> >
> >      .
> >
> >
> >
> >      <request>
> >
> >             subject-id=Bob
> >
> >             resource-id=/objects[1]/book[2]
> >
> >             <content>.the xml resource
> >
> >      </request>
> >
> >      .
> >
> >
> >
> > 3. Having these decision requests allows you to define very powerful
> rule
> > semantics and filtering is supported too.
> >
> >     e.g. the rule in the example above would look like this
> >
> >
> >
> >     <Rule effect=Deny>
> >
> >             Target:
> >
> >                         reg-exp-string-match(resource-id,
> > /objects\[\d+\]/book\[\d+\]
> >
> >             Condition:
> >
> >                         AttributeSelector(concat(resource-id,
> /price/text())
> >
> >> 50 and
> >>
> >
> > AttributeSelector(concat(resource-id, /author/text()) =
> > AttributeDesignator(subject-id)
> >
> >     </Rule>
> >
> >
> >
> >
> >
> >
> >
> > Note that all the problems mentioned above are solved.
> >
> > Filtering is possible as resource-id always refers to exactly one node
> in
> > the xml resource and thus we get individual access decisions for each
> node
> > in the xml resource. As resource-id is included in the decision response
> the
> > PEP can (e.g. through a simple xslt) filter out the nodes for which the
> > decision was deny.
> >
> > Further the problem of defining content dependant rights without
> reducing
> > the possible authorization semantics is solved, thanks to an
> > AttributeSelector that uses a concatenation of the resource-id attribute
> > value and an arbitrary offset as its RequestContextPath value.
> >
> >
> >
> > Note that the explanations above are simplified and try to focus the
> core
> > aspects of the idea only. I hope that I could nevertheless make clear
> where
> > the limitations are and how they could be solved.
> >
> > Let me know if you have problems understanding the ideas and I will try
> to
> > explain in more detail. Further, more detailed information can be found
> in
> > the comments I submitted during the public review period.
> >
> >
> >
> > Best regards
> >
> > Jan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >   _____
> >
> > Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> > Gesendet: Montag, 21. September 2009 16:24
> > An: Rich.Levinson; Erik Rissanen; Jan Herrmann
> > Cc: xacml@lists.oasis-open.org
> > Betreff: RE: AW: [xacml] CD-1 issue #11: strictness of xpath definition
> >
> >
> >
> > I'd like to understand the original use case before commenting on the
> > proposed solution.
> >
> >
> >
> > Can Jan or Rich provide a complete example (rule, request, response)
> that
> > demonstrates capabilities of the proposed feature, which cannot be met
> with
> > existing provisions of the specification?
> >
> >
> >
> > Thanks,
> >
> > --Paul
> >
> >
> >
> >
> >
> >
> >   _____
> >
> >
> > From: Rich.Levinson [mailto:rich.levinson@oracle.com]
> > Sent: Sunday, September 20, 2009 18:41
> > To: Erik Rissanen; Jan Herrmann
> > Cc: xacml@lists.oasis-open.org
> > Subject: Re: AW: [xacml] CD-1 issue #11: strictness of xpath definition
> >
> > Hi again Erik and Jan,
> >
> > I did some further thinking about the issue, and decided leaving the
> > "details" for later was insufficient. I have therefore attached a
> proposed
> > change to the hierarchical profile, which I think may address the issue.
> >
> > The basic idea is to be able to identify any explicit element or
> attribute
> > in an XML document in an unambiguous manner with a string to which
> regular
> > expressions may be applied. As such, namespace prefixs must be included
> > directly in this identifier, and since each namespace itself is a URI,
> it
> > needs non-URI character delimeters to avoid it interfering with other
> > parsing. RFC 2396 prescribes "percent encoding" for such mechanics
> within
> > URI and URI-references (where the "URI-reference" includes the fragment
> > portion).
> >
> > In order to see what this might look like if we were to take this
> approach,
> > what I have done is added a new sub-section, 2.2.1, which expands on
> section
> > 2.2 to include a hierarchical fragment portion of a "URI-reference",
> which I
> > believe is consistent w RFC 2396. I also included a ref in section 2.1
> > pointing to this as an "alternate representation".
> >
> > Comments and suggestions welcome.
> >
> >     Thanks,
> >     Rich
> >
> >
> > Rich.Levinson wrote:
> >
> > Hi Erik and Jan,
> >
> > When I suggested starting w xpath expressions as a naming scheme, I had
> > assumed we would properly incorporate namespaces. My limited (although
> not
> > zero) understanding of XPath is that it is built around a normative data
> > model:
> > http://www.w3.org/TR/xpath-datamodel/
> >
> > I have not read this data model in any significant depth, but I do know
> that
> > it is an explicit hierarchical representation of an XML document and
> that
> > each element and attribute node can most likely be explicitly and
> uniquely
> > addressed by a string of QNames (combo of resolved namespace prefix plus
> the
> > local tag name) in the form:
> >
> > /root-qname/qname/qname/...
> >
> > where, in our case, the root-qname would probably be the top element of
> the
> > doc.
> >
> > I did come across a notation called the "Clark notation" where qnames
> can be
> > written as:
> >
> > {namespace URI}local-tag-name
> >
> > So, if we had an xpath segment such as:
> >
> > .../foo:Title[1]/bar:Name[1]
> > where xmlns:foo="example.com/nsA" xmlns:bar="example.com/nsB"
> >
> > Then the actual string used for the resource-id and in the regexp
> matches
> > would be:
> >
> > .../{example.com/nsA}Title[1]/{example.com/nsB}Name[1]
> >
> > While this may seem awkward from a  user-friendliness point of view, I
> > expect policy design tools can be developed to significantly ease the
> pain.
> >
> > I think the bottom line is that the purpose here (in the context of the
> > XACML hierarchical profile) is that the xml document represents a
> hierarchy
> > of resources, where each node in the xml document is a potential
> resource
> > (presumably only element and attribute nodes, but, whatever). Since the
> xml
> > document is a well-formed hierarchy, and that xpath is based on a
> normative
> > data model where these nodes are  identified by qnames, it is fairly
> obvious
> > that  each node (resource) is addressable by a sequence of these qnames
> with
> > "/" used for navigation and "[n]" used to differentiate nodes w same
> name in
> > document order.
> >
> > I believe we can also represent these qnames within the URI scheme if we
> > percent encode any of the special characters needed to lay out the full
> > sequences. Of course there would be details not covered here, but to get
> to
> > that level would probably require some consensus that we wanted to
> > incorporate the idea.
> >
> > Once we are past that awkwardness of the exact naming format, but I
> think it
> > is an awkwardness implicit in xml documents, somewhat hidden by the
> format
> > of xml documents, but necessarily incorporated to any xml processing
> tools,
> > then I think we have an almost exact analogy to file system naming
> patterns
> > and the commonly understood scoping relationships used in that context.
> >
> > This is not to say to not use xpath at all (in fact, I suggest leaving
> all
> > the xpath stuff as is), but there may be circumstances where xpath is
> not
> > appropriate, and a scheme like this is natural and consistent w the rest
> of
> > the resource representation in the hierarchical profile. Further, I
> don't
> > think this is "new" functionality, but simply explaining how an xml
> document
> > resource hierarchy can be used within the already existing hierarchical
> > profile constructs, i.e. a "missing piece" of the xml document part of
> the
> > profile.
> >
> > My suggestion is that we add a comment to this effect in section 2.1
> > explaining a suggested "naming" process, then pointing the reader to
> section
> > 2.2 to the URI scheme of which the xml document would simply be a
> special
> > case.
> >
> >     Thanks,
> >     Rich
> >
> >
> >
> >
> >
> >
> > Erik Rissanen wrote:
> >
> > Hi Jan,
> >
> > And welcome to the TC. :-)
> >
> > See inline for my response.
> >
> > Jan Herrmann wrote:
> >
> >
> >
> > First of all it is important to note that the problem you described has
> > nothing to do with the discussion whether to do string matching on xpath
> > expressions or not.
> >
> >
> >
> > It has everything to do with xpath vs string matching. See below.
> >
> >
> >
> >
> >
> >
> > Your example would only occur if your PEP or PDP can add two completely
> > different xml resources to the decision request which are (at least in
> > parts) syntactically very similar (but not semantically - and thus the
> ac
> > semantics should be different). E.g.
> >
> >
> > resource one:
> >
> > <foo:Book>
> >
> > where foo is bound to xmlns:foo="example.com/nsA"
> >
> >
> >
> > and the second resource looks like:
> >
> > <foo:Book>
> >
> > where foo is bound to xmlns:foo="example.com/nsB"
> >
> >
> >
> > Having a rule pointing to /foo:Book through an Attribute selector or an
> > XPATH Matching function will cause the rule to get applied in both
> cases.
> > Here it becomes clear that the problem is independent of the discussion
> > whether string matching on xpath expressions should be supported or not.
> >
> >
> > No, it won't apply in the xpath case. Let's say we have the following
> > attribute selector (XACML 3.0 syntax):
> >
> > <AttributeSelector
> > xmlns:foo= <http://example.com/nsA> "http://example.com/nsA";
> > Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> > RequestContextPath="foo:Book"
> > MustBePresent="true"
> > DataType= <http://www.w3.org/2001/XMLSchema#string>
> > "http://www.w3.org/2001/XMLSchema#string"/>
> >
> > then it will match the following resource content:
> >
> > <Content xmlns:foo= <http://example.com/nsA> "http://example.com/nsA";>
> > <foo:Book>.....
> > </foo:Book>
> > </Content>
> >
> > but it will not match the following
> >
> > <Content xmlns:foo= <http://example.com/nsB> "http://example.com/nsB";>
> > <foo:Book>.....
> > </foo:Book>
> > </Content>
> >
> > This is because xpath does take the namespaces into account. String
> > functions do not. Relying in a particular form for xpath expressions,
> > namespace prefixes, etc, and assuming that requests never could collide
> is a
> > huge security risk and otherwise problematic.
> >
> > Best regards,
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php