OASIS eXtensible Access Control Markup Language (XACML) TC

Hi Rich,

Some of the reasons why an XPath approach could be better are:

1. XPath contains many functions and other capabilities, which might not 
be as easily available in the URI based approach.

2. The TC would avoid the effort to define the URI approach. We would 
need to improve the xpath approach instead, but I suspect that the 
effort is smaller since we can reuse so much from xpath, compared with a 
wholly new URI based approach.

3. It is likely that an XML resource is already available in XML form, 
so an xpath implimentation can be applied to it directly, while the URI 
approach requires a transformation, which could degrade performance.

Note that it is not true that the whole XML has to be repeated for each 
resource since multiple 

Hi Erik,

The intent of the proposal is not to replace or be better than XPath, 
but to be an "alternative representation" for node identification as 
described in section 2.0 of the profile, which if we included in the 
profile as suggested in section 2.2.1, presumably would then be a 
"recommended alternative representation".

The reason for the suggestion was to address the requirements specified 
in issue 11, which contained a recommended syntax that did not 
incorporate namespaces. By using the Clark notation for the namespaces, 
the syntax in issue 11 can be directly incorporated to the URI scheme as 
described in the proposal.

Once the syntax is in place then the same kinds of regexp-scoped 
Policy's can be written for XML nodes as for file system and URL resources.

Assuming the syntax and proposal is correct, it may be a useful 
alternative representation in some situations, particularly where it may 
be an objective to identify all resources w URIs, and/or where the mixed 
XACML/XPATH syntax is a concern wrt Policy specification.

    Thanks,  
    Rich


Erik Rissanen wrote:
> Hi Rich,
>
> Some of the reasons why an XPath approach could be better are:
>
> 1. XPath contains many functions and other capabilities, which might 
> not be as easily available in the URI based approach.
>
> 2. The TC would avoid the effort to define the URI approach. We would 
> need to improve the xpath approach instead, but I suspect that the 
> effort is smaller since we can reuse so much from xpath, compared with 
> a wholly new URI based approach.
>
> 3. It is likely that an XML resource is already available in XML form, 
> so an xpath implimentation can be applied to it directly, while the 
> URI approach requires a transformation, which could degrade performance.
>
> Note that it is not true that the whole XML has to be repeated for 
> each resource since multiple 

Hi Rich,

I highly agree with what you said in this mail. It seems that your use case
goes a bit further then the one I am thinking of. Let me try to identify the
common and varying parts of our use cases.

If I understand you correctly you are not only thinking about how the
resource-id values of the individual decision requests in the xml use case
have to look like. You are further having the file system and URL resource
use case in mind. This is something I have never thought about so far.

Further it seems that you are trying to represent the whole resource through
and only through URIs in one decision request. That’s also somehow different
to the use case I have in mind, as in my scenario the resource (the xml doc)
is always included under 

No one has produced an actual use case that requires regexp on xpath resource-ids to solve. I am not inclined to jump to this sort of solution.  I have a lot of experience writing xpath expressions for xslt transformations, so I am skeptical when anyone suggests  additional functionality is required in this area, that is not already provided by well-established standards.

I still plan to start some wiki pages on these topics, but I want to introduce some other aspects of this discussion.

1. Part of the problem is that XACML overloads the concept of "resource-id" when it can be used actually as a "resource-selector" in multi-resource request for XML resources.  This causes the actual resource-id that is used during evaluation to be different than the initial resource-id (it has been "expanded" to describe the exact node).  I believe this is a defect in the specification, which should be remedied in any case.  You face this problem when you want to write (as Jan does) rules involving the string value of the resource-id.  (I still don't understand the motivation for writing these sorts of rules, but that's a different matter.)

2. Related to the above point, there seems to be a gap in the current multi-resource specification, because it is not clear how the response identifies the xml node for each decision.  If PEP asks for decisions on "//*[@id=('foo','bar','baz')]"  (i.e., elements whose id attribute is 'foo', 'bar', or 'baz'), what should be the respective values of the resource-ids in the response?  They could be "//*[@id='foo']", "//*[@id='bar']", "//*[@id='baz']".  Or they could be "/chapter[1]/section[3]/para[1]", "/chapter[2]", "/chapter[2]/section[1]/fig[1]".  Assuming the PEP has xpath processing capabilities, it really shouldn't matter.  But the XACML spec should at least say something like "the returned resource-id shall be an xpath expression which, when evaluated against the original xml content, returns exactly (and only) the node on which the decision was issued".

3.  Much of this discussion centers around the conceptual model of multi-resource requests.  The spec says these are to be treated as a series of individual requests, and describes the required context of each derived request.  This model is normative only in concept, not for implementation--that is, a PDP must issue decisions as if this model had been followed.  The MR spec says "This Profile does NOT REQUIRE that the implementation of the evaluation of a request for access to multiple resources conform to the preceding model or that actual Individual Resource Requests be constructed." (section 2)  Therefore, the behavior of any rule evaluation that depends on a particular implementation of multi-resource requests is out of scope (and unspecified).  I believe the discussion of xpath resource-id rules falls into this category.  (I also believe the model of multi-resource decision evaluation needs to be defined better.)

--Paul


> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Jan Herrmann [mailto:herrmanj@in.tum.de] 
> Sent: Thursday, October 01, 2009 07:04
> To: 'Rich.Levinson'
> Cc: xacml@lists.oasis-open.org
> Subject: 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
> 
> Hi Rich,
> 
> I highly agree with what you said in this mail. It seems that 
> your use case goes a bit further then the one I am thinking 
> of. Let me try to identify the common and varying parts of 
> our use cases.
> 
> If I understand you correctly you are not only thinking about 
> how the resource-id values of the individual decision 
> requests in the xml use case have to look like. You are 
> further having the file system and URL resource use case in 
> mind. This is something I have never thought about so far.
> 
> Further it seems that you are trying to represent the whole 
> resource through and only through URIs in one decision 
> request. That's also somehow different to the use case I have 
> in mind, as in my scenario the resource (the xml doc) is 
> always included under 

Hi Paul,

See some comments inline.

Best regards,
Erik

Tyson, Paul H wrote:
> No one has produced an actual use case that requires regexp on xpath resource-ids to solve. I am not inclined to jump to this sort of solution.  I have a lot of experience writing xpath expressions for xslt transformations, so I am skeptical when anyone suggests  additional functionality is required in this area, that is not already provided by well-established standards.
>
> I still plan to start some wiki pages on these topics, but I want to introduce some other aspects of this discussion.
>
> 1. Part of the problem is that XACML overloads the concept of "resource-id" when it can be used actually as a "resource-selector" in multi-resource request for XML resources.  This causes the actual resource-id that is used during evaluation to be different than the initial resource-id (it has been "expanded" to describe the exact node).  I believe this is a defect in the specification, which should be remedied in any case.  You face this problem when you want to write (as Jan does) rules involving the string value of the resource-id.  (I still don't understand the motivation for writing these sorts of rules, but that's a different matter.)
>   

Yes, I agree. If I understand you correctly, this is the exact same 
issue I am thinking of when I say that the multiple resource profile 
"breaks the XACML assumption that the 

  
  


Hi Erik, Paul, Jan,


There has been good discussion in the last 6 emails:

http://lists.oasis-open.org/archives/xacml/200910/msg00005.html

http://lists.oasis-open.org/archives/xacml/200910/msg00004.html

http://lists.oasis-open.org/archives/xacml/200910/msg00003.html

http://lists.oasis-open.org/archives/xacml/200910/msg00002.html

http://lists.oasis-open.org/archives/xacml/200910/msg00001.html

http://lists.oasis-open.org/archives/xacml/200910/msg00000.html


Reviewing them all has led me to step back a bit and try to see a
larger scope thru which all the details might be systematically viewed.
I will try to present the larger scope that has helped me view these
issues and then try to address a couple of the issues within that
context.


Starting with the Multiple Resource Profile, I see 4 basic
"hierarchical use cases", which involve "hierarchical node
identification", which I think can reduced to 2 "hierarchical use
cases", which may then be viewed as applying to xml and non-xml
resources.


The 4 use cases I see in the Multiple Profile are the following (Note:
the top node of the hierarchies involved in these use cases is
generally the node identified by the " 'resource-id' attribute in the
original request context", a phrase that appears on lines 111,115,143,
145. I think the term "original resource-id" can be used to distinguish
this resource-id from the generated individual resource-ids that appear
in the individual requests. Also, the original resource-id is used, as
one of the individual requests as well.):


  
resource:scope="Immediate" covered by section 2.3. This use case
is essentially a "single" resource request and is relatively
uninteresting (in the context of the hierarchical node-naming
discussion), except for the fact that the individual "resource-id"
attribute may be considered to be essentially the same as the "original
resource-id" attribute. Also, section 2.3 covers the multiple single
request use case, which is essentially non-hierarchical in nature and
simply a list of resources

  
  
resource:scope="Children" covered by sections 2.1 and 2.2, and
consists essentially of sending a set of individual requests, which are
each identified by "resource-id", where the "parent" or "original
resource-id" is one request and each child of this parent has a
"generated resource-id" to identify it. Also, all these resource-id's
may appear in the individual Result elements that are returned and thus
represents a tangible entity that needs to be explicitly implemented,
because it can actually appear as a specific return element as an
identifier of the explicit resource to which the Result applies.
  
resource:scope="Descendants" also covered by sections 2.1 and
2.2, and represents the node identified by the "original resource-id"
plus all the element and attribute descendants of the original
resource-id node. Therefore, this use case requires the generation of a
tangible resource-id for every element and attribute in a hierarchical
resource including and below the element identified by the original
resource-id. Again, these may be tangible return values, and therefore
need to have a specific syntax and literal representation.
  
resource:scope="EntireHierarchy" covered by sections 3.1 and 3.2.
This use case is essentially the same as resource:scope="Descendants"
except only one Result element is generated, and is therefore
relatively uninteresting from a "hierarchical naming perspective".

The point of the above is to call attention to the two primary use
cases: resource:scope="Children" and resource:scope="Descendants" that
involve the issue of naming of nodes in a hierarchy. In this context, I
note the following characteristics that I think may be of general
interest:


  
Because the resource:scope="Descendants" use case requires the
ability to provide a tangible unique identifier to every node in an XML
document, if the original resource-id refers to the top node of that
document, there is an implicit requirement to have an explicit name for
every element in the hierarchy.
  
There appears to be no explicit "need" to send the actual XML
document along with the Request, because all that is explicitly
required is the resource-id Attribute. The only need for the XML
document would be to look at additional attributes that may be in that
document, but those attributes are outside the scope of anything in the
Multiple Profile itself.
  

    
Assuming the above point is acknowledged, it can also be
pointed out that while there may be policies written that use
additional attributes, there is no reason to think that any, or all of
those attributes necessarily would be found in the XML document.
  
  

    
Therefore, if agreement exists on the above 2 points, one might
also be able to say that there really is no reason to restrict the
attributes for the policies to be attributes that can be accessed
specifically by the XPath mechanism, and therefore no real "reason" to
restrict the node identification to be an XPath syntax as opposed to
any other syntax.
  
  
What these points are getting at is the notion that within the
multiple and hierarchical resource profiles there is an explicit need
to define an explicit syntax for identifying the nodes in a hierarchy,
be it and xml document or a non-xml document, but there is not explicit
need that this syntax should be explicitly XPath.

Given all the above I think it is also fair to say that XPath does not
even provide a syntax for explicit node-naming, although one can
specify a syntax for node naming using namespace prefixes in the path,
however, the XML document which has the resolution of those namespace
prefixes in xmlns attributes will need to accompany the request in
order to resolve the resource-id to a tangible value that can be
included in an IncludeInResult return attribute.


Granted that in a totally self-contained XPath environment, one might
be able to exist without ever explicitly naming a node outside of the
presence of the XML document itself, or the document schema, it appears
to me, at least, that such a situation kind of "bakes in" one specific
technology that will be required to be used to identify these
resources. This seems to me to be ok for specific implementations, but
it also appears to me to be at odds with the spirit of the core XACML
spec which states (lines 2659-2664):

"5.42 Element <Request>

The <Request> element is an abstraction layer used by the policy
language. For simplicity of expression, this document describes policy
evaluation in terms of operations on the context. However a conforming
PDP is not required to actually instantiate the context in the form of
an XML document. But, any system conforming to the XACML specification
MUST produce exactly the same authorization decisions as if all the
inputs had been transformed into the form of an <Request> element."


In summary, I believe the above considerations indicate that there is
nothing of functional substance in the Multiple or Hierarchical
Resource profiles that really require the presence of the XML document
in the Request element, and that all the capabilities can be
implemented without XPath or the XML document, and that therefore,
restricting functional capabilities, such as node-naming to be
represented in an explicitly XML-XPath dependent manner, while
providing no alternatives is unnecessarily restricting the
implementation technology to a specific form of resource representation.


i.e. the point I am trying to make is that while I have no objection to
XPath methods being included as representative of a way to implement
the functionality of the profiles, I do not agree that these methods
are necessarily sufficient in and of themselves to represent the
functional capabilities of these profiles. And for the node-naming
problem, in particular, I think that the XPath syntax provides only a
technology-specific way of representing the node names and that
therefore an alternative string representation that is not
technology-dependent is effectively required as an alternative. In
addition, I also believe that the suggestion I made using URI syntax or
something equivalent, meets the requirements and is transformable to
XPath syntax if necessary for implementation purposes.


Comments and suggestions welcome, and I realize that I may have
overlooked aspects of the problem, which might alter these conclusions,
but would request that those oversights or mistakes be pointed out for
consideration.


    Thanks,

    Rich




Erik Rissanen wrote:
4AC4B1B1.7050605@axiomatics.com" type="cite">Hi
Paul,


See some comments inline.


Best regards,

Erik


Tyson, Paul H wrote:

  
No one has produced an actual use case that
requires regexp on xpath resource-ids to solve. I am not inclined to
jump to this sort of solution.  I have a lot of experience writing
xpath expressions for xslt transformations, so I am skeptical when
anyone suggests  additional functionality is required in this area,
that is not already provided by well-established standards.


I still plan to start some wiki pages on these topics, but I want to
introduce some other aspects of this discussion.


1. Part of the problem is that XACML overloads the concept of
"resource-id" when it can be used actually as a "resource-selector" in
multi-resource request for XML resources.  This causes the actual
resource-id that is used during evaluation to be different than the
initial resource-id (it has been "expanded" to describe the exact
node).  I believe this is a defect in the specification, which should
be remedied in any case.  You face this problem when you want to write
(as Jan does) rules involving the string value of the resource-id.  (I
still don't understand the motivation for writing these sorts of rules,
but that's a different matter.)

  


Yes, I agree. If I understand you correctly, this is the exact same
issue I am thinking of when I say that the multiple resource profile
"breaks the XACML assumption that the <Request> describes a
single attempted access to a single resource".


  
2. Related to the above point, there seems to
be a gap in the current multi-resource specification, because it is not
clear how the response identifies the xml node for each decision.  If
PEP asks for decisions on "//*[@id=('foo','bar','baz')]"  (i.e.,
elements whose id attribute is 'foo', 'bar', or 'baz'), what should be
the respective values of the resource-ids in the response?  They could
be "//*[@id='foo']", "//*[@id='bar']", "//*[@id='baz']".  Or they could
be "/chapter[1]/section[3]/para[1]", "/chapter[2]",
"/chapter[2]/section[1]/fig[1]".  Assuming the PEP has xpath processing
capabilities, it really shouldn't matter.  But the XACML spec should at
least say something like "the returned resource-id shall be an xpath
expression which, when evaluated against the original xml content,
returns exactly (and only) the node on which the decision was issued".

  


This behavior is already required by the current specification, but
could perhaps be stated more explicitly. The PDP will return the
resource-id attribute specified in the individual request if the
"IncludeInResult" attribute has been set to "true". And the multiple
resource profile already requires that for each individual request the
resource-id must consist of an XPath expression which matches exactly
one node. The combined effect of this is the behavior you describe
above.


  
3.  Much of this discussion centers around
the conceptual model of multi-resource requests.  The spec says these
are to be treated as a series of individual requests, and describes the
required context of each derived request.  This model is normative only
in concept, not for implementation--that is, a PDP must issue decisions
as if this model had been followed.  The MR spec says "This Profile
does NOT REQUIRE that the implementation of the evaluation of a request
for access to multiple resources conform to the preceding model or that
actual Individual Resource Requests be constructed." (section 2) 
Therefore, the behavior of any rule evaluation that depends on a
particular implementation of multi-resource requests is out of scope
(and unspecified).  I believe the discussion of xpath resource-id rules
falls into this category.  (I also believe the model of multi-resource
decision evaluation needs to be defined better.)

  


Sorry, but I don't understand this point. But I do think it is relevant
to discuss whether the spec can be implemented in any efficient manner,
and this can affect what the specification should be like.


  
--Paul



 
    


                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----

From: Jan Herrmann [mailto:herrmanj@in.tum.de] Sent: Thursday, October
01, 2009 07:04

To: 'Rich.Levinson'

Cc: xacml@lists.oasis-open.org

Subject: 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


Hi Rich,


I highly agree with what you said in this mail. It seems that your use
case goes a bit further then the one I am thinking of. Let me try to
identify the common and varying parts of our use cases.


If I understand you correctly you are not only thinking about how the
resource-id values of the individual decision requests in the xml use
case have to look like. You are further having the file system and URL
resource use case in mind. This is something I have never thought about
so far.


Further it seems that you are trying to represent the whole resource
through and only through URIs in one decision request. That's also
somehow different to the use case I have in mind, as in my scenario the
resource (the xml doc) is always included under <content> as it
is and the question of representation is always reduced to how to
represent the resource-id value that must match exactly one node under
content.


I think one important task is to try to identify the common or relating
aspects of the different use cases and where they differ or where they
are independent.


I agree that in issue 11 the namespace problem was not handled at all.
Thus some little extra work is needed.


I further agree that it would be beautiful to have the same style how
to define rules for different kind of resources if possible. Thus I
fully share your proposal to add an alternative for representing nodes
(or whatsoever) as resource-id-values or in general.


As far as I understand the Clark notation it is simply a substituted
form where prefixes are replaced by the namespaces bound to them. For
my use case this would work perfectly well. The question is if you want
to try to force the policy writer to follow this syntax when defining
the resource-id match in its rule. Further if you think of an
AttributeSelector that can concatenate resource-id with an offset this
implies that the AttributeSelector implementation must be able to deal
with the clark syntax to :-(



In my scenario there is another possible alternative (as mentioned in
the mail submitted two hours ago):

You could use a special reg-exp-On-XPath-strings function that is
namespace aware and substitutes the prefixes correspondingly before
doing the common reg-expr matching stuff on the resource-id attribute.
This reg-exp-On-XPath-strings function is the function to test the
resource-id values only.

Does your use cases require more functions that work on a URI based
representation of individual resources?


Below you'll find further comments to your questions in an earlier
mail.

Basic conclusion of the comments below:

allow to represent the resource in xml or through a set of
attribute/value pairs (if can be shown that this realy brings
advantages).


Looking forward to further discussions and comments.


Best regards

Jan

 





________________________________________


Jan Herrmann

Dipl.-Inform., Dipl.-Geogr.

wissenschaftlicher Mitarbeiter


Technische Universität München

Institut für Informatik

Lehrstuhl für Angewandte Informatik / Kooperative Systeme


Boltzmannstr. 3

85748 Garching


Tel:      +49 (0)89 289-18692

Fax:     +49 (0)89 289-18657

www11.informatik.tu-muenchen.de

________________________________________

 


   
      
-----Ursprüngliche Nachricht-----

Von: Rich.Levinson [mailto:rich.levinson@oracle.com]

Gesendet: Montag, 28. September 2009 22:40

An: Erik Rissanen

Cc: XACML TC

Betreff: Re: [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 Erik,


The intent of the proposal is not to replace or be better       
than XPath,

   
      
but to be an "alternative representation"
for node identification as

described in section 2.0 of the profile, which if we included in the

profile as suggested in section 2.2.1, presumably would then be a

"recommended alternative representation".


The reason for the suggestion was to address the       
requirements specified

   
      
in issue 11, which contained a
recommended syntax that did not

incorporate namespaces. By using the Clark notation for the       
namespaces,

   
      
the syntax in issue 11 can be directly
incorporated to the       
URI scheme as

   
      
described in the proposal.


Once the syntax is in place then the same kinds of regexp-scoped

Policy's can be written for XML nodes as for file system and URL

resources.


Assuming the syntax and proposal is correct, it may be a useful

alternative representation in some situations, particularly       
where it may

   
      
be an objective to identify all resources
w URIs, and/or       
where the mixed

   
      
XACML/XPATH syntax is a concern wrt
Policy specification.


    Thanks,

    Rich



Erik Rissanen wrote:

     
        
Hi Rich,


Some of the reasons why an XPath approach could be better are:


1. XPath contains many functions and other capabilities,         
      
which might

   
      

        
not be as easily available in the URI
based approach.


2. The TC would avoid the effort to define the URI         
      
approach. We would

   
      

        
need to improve the xpath approach
instead, but I suspect that the

effort is smaller since we can reuse so much from xpath,         
      
compared with

   
      

        
a wholly new URI based approach.


3. It is likely that an XML resource is already available         
      
in XML form,

   
      

        
so an xpath implimentation can be
applied to it directly,         
      
while the

   
      

        
URI approach requires a transformation,
which could         
      
degrade performance.

   
      

        
Note that it is not true that the whole
XML has to be repeated for

each resource since multiple <Attributes> elements are         
      
not required

   
      

        
with the xpath approach, and with XACML
3.0 it is         
      
possible to reuse

   
      

        
the same <Content> document for
all the multiple queries.


Best regards,

Erik


Rich.Levinson wrote:

       
          
Hi Jan, et al,


I have had a busy week and not been able to respond until now,

however, looking over all the subsequent emails to the           
        
      
one to which

   
      

        

          
this is a response (

http://lists.oasis-open.org/archives/xacml/200909/msg00081.html

), it appears to me that there are still unresolved           
        
      
issues, and from

   
      

        

          
my perspective, there are some
assertions made, with which I

disagree, about AttributeDesignators, which I thought my           
        
      
suggested

   
      

        

          
URI scheme would address, but
apparently it either needs further

explanation or I am missing something that I have not           
        
      
yet understood.

   
      

        

          
In any event I would very much like
to determine whether these

assertions are true or false in order that the TC be of           
        
      
a single mind

   
      

        

          
when comparing the capabilities of
AttributeSelectors and

AttributeDesignators.


   The assertion with which I disagree is that the           
        
      
AttributeDesignators

   
      

        

          
   cannot do what the
AttributeSelectors can do because the

   AttributeDesignators lose the hierarchical structure.           
        
      
My response is

   
      

        

          
   that if you don't throw away the
hierarchical structure when

   creating your AttributeDesignators then this           
        
      
perceived problem does

   
      

        

          
   not exist.

          
        
      
For the XML use case:

I can imagine that it is possible to rebuild the semantics that are

expressed through the structure of nodes through an appropriate naming
of

the attributes. But it seems to be very complicated and I can't find
the

advantages of transforming an originally xml encoded resource in uris

without benefits. Further this will imply special functions working on
the

chosen naming-schema see below.

Why should one try to avoid AttributeSelectors at all?



   
      

        

          
If I am wrong about this, I will
accept that, however, I do not

believe that my approach to the AttributeDesignators has been

considered on its merits yet, and I will try to be           
        
      
totally explicit

   
      

        

          
in this email, and I will show how I
think Jan's           
        
      
proposed solution

   
      

        

          
can be completely done using only
AttributeDesignators and regexp

string matching.


Having been thru some lengthy discussions earlier this           
        
      
year on the

   
      

        

          
hierarchical profile, I became quite
sensitive to the node naming

issue, and one of the results of those earlier           
        
      
discussions was that

   
      

        

          
if hierarchical URIs are used to name
nodes, that these           
        
      
names contain

   
      

        

          
within them the navigation necessary
to locate the node, so that

using these names outside of an XML document does not lose the

structural relationships.


Using James Clark's universal name syntax           
        
      
("{namespace}elementname"

   
      

        

          
http://www.jclark.com/xml/xmlns.htm)
combined with a transform to

replace the xml document with a list of name/value pairs           
        
      
(there are

   
      

        

          
several XML to JSON xslt transformers
available free,           
        
      
which I expect

   
      

        

          
could readily be adapted to produce
name/value pairs in           
        
      
the format

   
      

        

          
below), where each element and
attribute is identfied by its full

path expressed as universal element names. For example,           
        
      
assuming the

   
      

        

          
document you gave as an example had a
namespace = "foo":


<objects xmlns:="foo">

 <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>


The above document would first be transformed to the           
        
      
following set of

   
      

        

          
name value pairs (ignoring
whitespace):

/{foo}objects = ""

/{foo}objects/{foo}book[1] = ""

/{foo}objects/{foo}book[1]/{foo}title = "xxx"

/{foo}objects/{foo}book[1]/{foo}author = "Bob"

/{foo}objects/{foo}book[1]/{foo}id = "100"

/{foo}objects/{foo}book[1]/{foo}price = "30"

/{foo}objects/{foo}book[1]/{foo}content = "..."

/{foo}objects/{foo}book[2] = ""

/{foo}objects/{foo}book[2]/{foo}title = "yyy"

/{foo}objects/{foo}book[2]/{foo}author = "Alice"

/{foo}objects/{foo}book[2]/{foo}id = "200"

/{foo}objects/{foo}book[2]/{foo}price = "80"

/{foo}objects/{foo}book[2]/{foo}content = "..."


The next step is to define resources, which for this use           
        
      
case would

   
      

        

          
be done based on multiple resource
profile, where we would have 2

resources, using Erik's shorthand:

<Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>

<Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>


The next step is to create xacml attributes for these           
        
      
resources using

   
      

        

          
the full universal names as
AttributeIds (again w some           
        
      
shorthand),

   
      

        

          
resulting in the following 2
requests:

(Note: since AttributeId requires anyURI datatype, the following

percent-encoding must be applied to the AttributeId values:


   * { -> %7B

   * } -> %7D

   * [ -> %5B

   * ] -> %5D )



<Request>

<Subject>subject-id="Bob"</Subject>

<Resource>

<Attribute>AttributeId="resource-id"

value="/{foo}objects/{foo}book[1]"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D

/%7Bfoo%7Dti

   
      
tle"

     
        

          
value = "xxx"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D

/%7Bfoo%7Dau

   
      
thor"

     
        

          
value = "Bob"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D

/%7Bfoo%7Did

   
      
"

     
        

          
value = "100"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D

/%7Bfoo%7Dpr

   
      
ice"

     
        

          
value = "30"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D

/%7Bfoo%7Dco

   
      
ntent"

     
        

          
value = "..."</Attribute>

</Resource>

</Request>


<Request>

<Subject>subject-id="Bob"</Subject>

<Resource>

<Attribute>AttributeId="resource-id"

value="/{foo}objects/{foo}book[2]"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D

/%7Bfoo%7Dti

   
      
tle"

     
        

          
value = "yyy"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D

/%7Bfoo%7Dau

   
      
thor"

     
        

          
value = "Alice"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D

/%7Bfoo%7Did

   
      
"

     
        

          
value = "200"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D

/%7Bfoo%7Dpr

   
      
ice"

     
        

          
value = "80"</Attribute>


          
        
      
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D

/%7Bfoo%7Dco

   
      
ntent"

     
        

          
value = "..."</Attribute>

</Resource>

</Request>


All the above processing to create the requests is done in the

ContextHandler, then the requests are submitted one at a           
        
      
time to the

   
      

        

          
PDP.

Now the rule that gets applied to each of these requests is the

following:


<Rule effect=Deny>

 Target:

   reg-exp-string-match(resource-id,           
        
      
/{foo}objects/{foo}book\[\d+\]

   
      

        

          
 Condition:

   AttributeDesignator(AttributeId =

function:string-concatenate(resource-id,           
        
      
/%7Bfoo%7Dprice) > 50 and

   
      

        

          
   AttributeDesignator(AttributeId =

function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =

AttributeDesignator(subject-id)

</Rule>


Unless I am mistaken, all the logic and structure is           
        
      
retained and it

   
      

        

          
has been done purely w
AttributeDesignators and regexp.

          
        
      
I think i can follow your approach and agree that this explicitly
represents

the xml resource through URIs.

Probs:

- things like ../../ will be hard to handle

- in the geo use case we have an geometry data type. This datapye is
defined

by the following xml code:


<gml:Polygon srsName="http://www.opengis.net/../epsg.xml#43">

  <gml:outerBoundaryIs>

    <gml:LinearRing>

      <gml:coordinates decimal="." cs="," ts="
">-120.000000,65.588264

...-120.000000,65.588264

      </gml:coordinates>

    </gml:LinearRing>

  </gml:outerBoundaryIs>

</gml:Polygon>


Now assume you try to define a rule, following your approach, in which
you

use a pointer to a polygon element in the decision request's content
element

(e.g. a polgon representing the location of a building):

In very dirty/wrong XACML this will look like this:

<Rule effect=permit>

<Target>

  subject-id==Alice

  reg-exp-string-match(resource-id, /{foo}objects/{foo}building\[\d+\]

<Condition>

  <Apply FunctionId=within>

    <ExtendedAttributeSelector Category=resource>

      <concat>

        <AttributeDesigntor>resource-id

        <AttributeValue>/%7Bfoo%7Dlocation/%7Bfoo%7DPolygon

      </concat>

    <AttributeValue DataType=Geometry>

      <Polygon>...defining the area of the USA </Polygon>

    </AttributeValue>

 </Apply>

</Condition>

</Rule>


So far no probs. Let's have a have a closer look at the
AttributeSeletor,

responsible for instantiating an attribute of datatype Geometry. It
will

have to go through all the URIs representing the resource and find the

relevant ones in order to instantiate the geometry attribute. This can
off

course be implemented but the question is why to "flatten" an xml doc,
if

afterwards, you need to rebuild parts of it.

This makes the AttributeSelector implementation unneccesarely
complicated.


I think what needs to be analysed is:

- What are the advantages to transform the xml resource completely into
uris

or Attribut/Value pairs respectively?

- What are the disadvantages of doing this?


The approach of leaving the xml resource as it is in the decision
request

and just adding a resource-id/value pair pointing to one node implies
that

you will have to use AttributeDesignators and AttributeSelectors in
your

rules. Is this a disadvantage? It seems that you are trying to avoid
the

selector at all. But I can't follow why.

 

However if it can be shown that it brings advantages to encode an xml

resource in the decision request only through Attribute/Value pairs
that I

would support this as an legal option that should be added to the
profile.

Of course this must bring advantages. Whithout advantages this will
just

introduce another way of how to define the same rules for now reason.






   
      

        

          
Assuming the above is correct, then
the points I made about the

advantages over XPath (for an enterprise looking to use           
        
      
only URIs to

   
      

        

          
identify attributes):


  1. The XML document does not need to be passed in with           
        
      
the request.

   
      

        

          
     There is no node collection,
only string operations.

          
        
      
If I may concretise:

Case 1.

In the global request you will have a content element containing the
xml

resource and an scope attribute describing a subset of this node
collection

that will be subject to the access control process.

Based on this the PDP or Contexthandler will derive the individual
decision

requests. Here the xml resource could be transformed as you described
above

and thus you will afterwards only have attribute/value pairs.

Case2:

The PEP can directly submits "already-transformed" global decision
request

where the xml resource that is "normally" under <content> is
replaced by a

set of Attribute/Value pairs. Further the resource-id and scope must
specify

a set of these Attribute-Names. Based on this the PDP or Contexthandler
will

derive the individual decision requests. The individual decision
requests

will still contain the complete set of Attribute/Value pairs that
represent

the xml resource and further the resource-id value will be equal to one
of

these Attribute-Names.

 



   
      

        

          
  2. For very large XML documents,
say a catalog of           
        
      
10,000 books, each

   
      

        

          
     book is processed individually
independent of the           
        
      
other books, as

   
      

        

          
     compared to the XPath case,
where one might expect the whole

     document has to get parsed for each of the 10,000 individual

requests.

          
        
      
This is only true if you don't have content dependant rules. e.g.
assume you

have a rule that says permit access to books if none of the other books
is

from the same author. Nevertheless I can imagine that in average less
data

has to be parsed... On the other side there might be an overhead of

determining which data. Again the question: What are the advantages of
transforming the resource

completely into URIs. I think if this is the central point a closer
analysis

is needed.


   
      

        

          
  3. There is no paradigm shifting,
or what I believe           
        
      
was referred to

   
      

        

          
     in the discussion as "shifting
semantics between           
        
      
XPath and XACML

   
      

        

          
     in terms of representing the
policies.

          
        
      
If i understand you correctly you mean that all access right semantic
will

be expressed in xacml. That is necessarily true as you don't have any
xml

resource in the request anymore and thus xpath predicates can't be
defined

anymore. Is this an advantage? Clearly this reduces the options how the
same

rule can be defined in xacml and might therefore simplify a

are-two-rules-equal test. Note that this could also be achieved if you

disallow xpath with predicates in xacml. Thus this issue can be
discussed in

general.

My experience in using a mixture of xpath predicates and xacml where

necessary (i.e. where the ac semantics can't be expressed through xpath

predicates) helps defining shorter and more readable rules. I would
leave it

open to the policy administrator if he implements the semantics through

xpath predicates or xacml functions. Maybe a best practise study could

analyse this topic (next to others). In general I think such a document

might be very helpful as soon as the 3.0 specs are standardised in
order to

make it easier for users to use XACML

 


   
      

        

          
Again, assuming the above is correct,
I am not assuming           
        
      
this will be

   
      

        

          
desirable for everyone, however there
may very well be           
        
      
organizations

   
      

        

          
for whom the advantages of this
approach are decisive.


A couple other points are that


   * the "unsightliness" of the AttributeIds and the

     AttributeDesignators can be "covered" up by policy           
        
      
tools that

   
      

        

          
     facilitate defining policies
based on XML Schemas,           
        
      
and can keep

   
      

        

          
     all the encoding details
transparent to the policy           
        
      
designers.



i agree


   
      

        

          
   * the issue about basing policies
on the structure of           
        
      
XML documents

   
      

        

          
     is a legitimate concern,
however, if structure of documents

     change, then a legitimate case could probably made that the

     namespace associated with that structure should           
        
      
also change, which

   
      

        

          
     would mean the policy tools
would need to be able           
        
      
to facilitate

   
      

        

          
     upgrading of policies to new
namespaces based on           
        
      
new revs of the

   
      

        

          
     schemas.


Comments and suggestions welcome.


   Thanks,

   Rich


          


        
      
---------------------------------------------------------------------

   
      

        
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



---------------------------------------------------------------------

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_workgr

oups.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

  




---------------------------------------------------------------------

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

Hi Rich,

If I understand you correctly, the essence of your email is that you say 
that a hierarchical resource could be described in some other manner 
than an XML document, so use of XML in the request or XPath in the 
policies are not required.

Well, maybe so, but if one does not use XML for the hierarchy, one has 
to use something else somewhere else, and you leave this question 
completely open. So you are really proposing yet another brand new 
scheme for doing hierarchies and multiple requests. This could be 
interesting in its own right, but there are many people who wish to use 
XML for their resources since it is convenient. And these users do want 
to look up additional attributes in the XML. This discussion started 
because users of XACML saw limitations in XACML's capabilities with 
regard to XML resources.

So, I think we should make a clear distinction between:

1. How to improve XACML when the user is in fact using XML for resources 
and does want to look up attributes of the individual resources in the XML.

2. How to define other schemes for multiple requests and hierarchies.

One could also discuss the various merits of different schemes, but a 
strong point of the XML scheme is that XML is a standardized capability 
which does not require any custom capabilities in the PEP or context 
handler. The URI scheme leaves the whole issue of defining, storing and 
transmitting the hierarchy unspecified, so it would not work out of box 
on a standard XACML implementation.

Best regards,
Erik


Rich.Levinson wrote:
> Hi Erik, Paul, Jan,
>
> There has been good discussion in the last 6 emails:
> http://lists.oasis-open.org/archives/xacml/200910/msg00005.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00004.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00003.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00002.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00001.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00000.html
>
> Reviewing them all has led me to step back a bit and try to see a 
> larger scope thru which all the details might be systematically 
> viewed. I will try to present the larger scope that has helped me view 
> these issues and then try to address a couple of the issues within 
> that context.
>
> Starting with the Multiple Resource Profile, I see 4 basic 
> "hierarchical use cases", which involve "hierarchical node 
> identification", which I think can reduced to 2 "hierarchical use 
> cases", which may then be viewed as applying to xml and non-xml resources.
>
> The 4 use cases I see in the Multiple Profile are the following (Note: 
> the top node of the hierarchies involved in these use cases is 
> generally the node identified by the " 'resource-id' attribute in the 
> original request context", a phrase that appears on lines 111,115,143, 
> 145. I think the term "original resource-id" can be used to 
> distinguish this resource-id from the generated individual 
> resource-ids that appear in the individual requests. Also, the 
> original resource-id is used, as one of the individual requests as well.):
>
>    1. resource:scope="Immediate" covered by section 2.3. This use case
>       is essentially a "single" resource request and is relatively
>       uninteresting (in the context of the hierarchical node-naming
>       discussion), except for the fact that the individual
>       "resource-id" attribute may be considered to be essentially the
>       same as the "original resource-id" attribute. Also, section 2.3
>       covers the multiple single request use case, which is
>       essentially non-hierarchical in nature and simply a list of
>       resources
>    2. resource:scope="Children" covered by sections 2.1 and 2.2, and
>       consists essentially of sending a set of individual requests,
>       which are each identified by "resource-id", where the "parent"
>       or "original resource-id" is one request and each child of this
>       parent has a "generated resource-id" to identify it. Also, all
>       these resource-id's may appear in the individual Result elements
>       that are returned and thus represents a tangible entity that
>       needs to be explicitly implemented, because it can actually
>       appear as a specific return element as an identifier of the
>       explicit resource to which the Result applies.
>    3. resource:scope="Descendants" also covered by sections 2.1 and
>       2.2, and represents the node identified by the "original
>       resource-id" plus all the element and attribute descendants of
>       the original resource-id node. Therefore, this use case requires
>       the generation of a tangible resource-id for every element and
>       attribute in a hierarchical resource including and below the
>       element identified by the original resource-id. Again, these may
>       be tangible return values, and therefore need to have a specific
>       syntax and literal representation.
>    4. resource:scope="EntireHierarchy" covered by sections 3.1 and
>       3.2. This use case is essentially the same as
>       resource:scope="Descendants" except only one Result element is
>       generated, and is therefore relatively uninteresting from a
>       "hierarchical naming perspective".
>
> The point of the above is to call attention to the two primary use 
> cases: resource:scope="Children" and resource:scope="Descendants" that 
> involve the issue of naming of nodes in a hierarchy. In this context, 
> I note the following characteristics that I think may be of general 
> interest:
>
>     * Because the resource:scope="Descendants" use case requires the
>       ability to provide a tangible unique identifier to every node in
>       an XML document, if the original resource-id refers to the top
>       node of that document, there is an implicit requirement to have
>       an explicit name for every element in the hierarchy.
>     * There appears to be no explicit "need" to send the actual XML
>       document along with the Request, because all that is explicitly
>       required is the resource-id Attribute. The only need for the XML
>       document would be to look at additional attributes that may be
>       in that document, but those attributes are outside the scope of
>       anything in the Multiple Profile itself.
>           o Assuming the above point is acknowledged, it can also be
>             pointed out that while there may be policies written that
>             use additional attributes, there is no reason to think
>             that any, or all of those attributes necessarily would be
>             found in the XML document.
>           o Therefore, if agreement exists on the above 2 points, one
>             might also be able to say that there really is no reason
>             to restrict the attributes for the policies to be
>             attributes that can be accessed specifically by the XPath
>             mechanism, and therefore no real "reason" to restrict the
>             node identification to be an XPath syntax as opposed to
>             any other syntax.
>     * What these points are getting at is the notion that within the
>       multiple and hierarchical resource profiles there is an explicit
>       need to define an explicit syntax for identifying the nodes in a
>       hierarchy, be it and xml document or a non-xml document, but
>       there is not explicit need that this syntax should be explicitly
>       XPath.
>
> Given all the above I think it is also fair to say that XPath does not 
> even provide a syntax for explicit node-naming, although one can 
> specify a syntax for node naming using namespace prefixes in the path, 
> however, the XML document which has the resolution of those namespace 
> prefixes in xmlns attributes will need to accompany the request in 
> order to resolve the resource-id to a tangible value that can be 
> included in an IncludeInResult return attribute.
>
> Granted that in a totally self-contained XPath environment, one might 
> be able to exist without ever explicitly naming a node outside of the 
> presence of the XML document itself, or the document schema, it 
> appears to me, at least, that such a situation kind of "bakes in" one 
> specific technology that will be required to be used to identify these 
> resources. This seems to me to be ok for specific implementations, but 
> it also appears to me to be at odds with the spirit of the core XACML 
> spec which states (lines 2659-2664):
>
>     "5.42 Element 

Hi Rich,

Still, it should cover something which the xpath approach does not 
cover, or do something better. Could you elaborate what it does beyond 
xpath? So far I have only seen examples of how the URI approach can 
replicate the xpath approach.

Best regards,
Erik



Rich.Levinson wrote:
> Hi Erik,
>
> The intent of the proposal is not to replace or be better than XPath, 
> but to be an "alternative representation" for node identification as 
> described in section 2.0 of the profile, which if we included in the 
> profile as suggested in section 2.2.1, presumably would then be a 
> "recommended alternative representation".
>
> The reason for the suggestion was to address the requirements 
> specified in issue 11, which contained a recommended syntax that did 
> not incorporate namespaces. By using the Clark notation for the 
> namespaces, the syntax in issue 11 can be directly incorporated to the 
> URI scheme as described in the proposal.
>
> Once the syntax is in place then the same kinds of regexp-scoped 
> Policy's can be written for XML nodes as for file system and URL 
> resources.
>
> Assuming the syntax and proposal is correct, it may be a useful 
> alternative representation in some situations, particularly where it 
> may be an objective to identify all resources w URIs, and/or where the 
> mixed XACML/XPATH syntax is a concern wrt Policy specification.
>
>    Thanks,     Rich
>
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> Some of the reasons why an XPath approach could be better are:
>>
>> 1. XPath contains many functions and other capabilities, which might 
>> not be as easily available in the URI based approach.
>>
>> 2. The TC would avoid the effort to define the URI approach. We would 
>> need to improve the xpath approach instead, but I suspect that the 
>> effort is smaller since we can reuse so much from xpath, compared 
>> with a wholly new URI based approach.
>>
>> 3. It is likely that an XML resource is already available in XML 
>> form, so an xpath implimentation can be applied to it directly, while 
>> the URI approach requires a transformation, which could degrade 
>> performance.
>>
>> Note that it is not true that the whole XML has to be repeated for 
>> each resource since multiple 

Hi Erik, Rich, all

below you find a summary of the discussion on "xpath vs. reg-exp-match for
resource-id evaluations" so far (from my point of view) and some further
comments. I hope that helps to clarify where we are.

Baseline:
An individual decision request's resource-id attribute is an XPath
expression that points to exactly one node in the xml resource (i.e. a
multiple and hierarchically organised resource)

Open Question:
How two define the part of a rule that matches this resource-id attribute.

Possible approaches:
Approach 1: 
Use the XPath-node-XXX functions 
(e.g. xpath-node-equal(resource-id, /objects/book)

Approach 2: 
Use the reg-exp-string function
(e.g. reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\]))

Evaluation:
- both approaches can offer the same functionality

I hope so far we all agree. 

Now let's come to the pros and cons of each approach:

Let's start with Approach 2 (i.e. the reg-exp-string function based option):
 
A reason why the reg-expr-match approach could be better:

It is very simple and most importantly it can be evaluated very fast and
just on the two arguments - the string representing one node and a
corresponding regular expression. There is no need to do go through the xml
resource itself while evaluation.
In contrast, if you use the XPath approach the two XPath arguments of the
xpath node-match functions have to be evaluated against the xml resource
(e.g. a DOM representation in memory). This disadvantage becomes even more
serious if you take into account, that your multiple resource (e.g. an xml
doc) consists of n individual resources/nodes and thus you have to evaluate
n xpath node-match functions. In short a processing overhead that occurs
when using the XPath approach occurs n times.

On the other side the disadvantage of the reg-expr-match approach is that it
doesn't deal with the namespace definition behind the prefixes explicitly.
Thus, in case you have the following situation something unintended could
occur:

- Two xml schemas, that describe the xml resource, use the same
elementNodeName for the complexTypes (e.g. 

Hi All,

See responses inline.

Jan Herrmann wrote:
> Hi Erik, Rich, all
>
> below you find a summary of the discussion on "xpath vs. reg-exp-match for
> resource-id evaluations" so far (from my point of view) and some further
> comments. I hope that helps to clarify where we are.
>
> Baseline:
> An individual decision request's resource-id attribute is an XPath
> expression that points to exactly one node in the xml resource (i.e. a
> multiple and hierarchically organised resource)
>
> Open Question:
> How two define the part of a rule that matches this resource-id attribute.
>
> Possible approaches:
> Approach 1: 
> Use the XPath-node-XXX functions 
> (e.g. xpath-node-equal(resource-id, /objects/book)
>
> Approach 2: 
> Use the reg-exp-string function
> (e.g. reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\]))
>
> Evaluation:
> - both approaches can offer the same functionality
>   

Only if we fix the normalization problem of the regexp case.

> I hope so far we all agree. 
>
> Now let's come to the pros and cons of each approach:
>
> Let's start with Approach 2 (i.e. the reg-exp-string function based option):
>  
> A reason why the reg-expr-match approach could be better:
>
> It is very simple and most importantly it can be evaluated very fast and
> just on the two arguments - the string representing one node and a
> corresponding regular expression. There is no need to do go through the xml
> resource itself while evaluation.
> In contrast, if you use the XPath approach the two XPath arguments of the
> xpath node-match functions have to be evaluated against the xml resource
> (e.g. a DOM representation in memory). This disadvantage becomes even more
> serious if you take into account, that your multiple resource (e.g. an xml
> doc) consists of n individual resources/nodes and thus you have to evaluate
> n xpath node-match functions. In short a processing overhead that occurs
> when using the XPath approach occurs n times.
>
> On the other side the disadvantage of the reg-expr-match approach is that it
> doesn't deal with the namespace definition behind the prefixes explicitly.
> Thus, in case you have the following situation something unintended could
> occur:
>
> - Two xml schemas, that describe the xml resource, use the same
> elementNodeName for the complexTypes (e.g.