Re: [xacml] CD-1 issue #11: strictness of xpath definition

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

Yes, I agree XML documents are well formed hierarchies, but I don't 
understand why another naming scheme is needed? What is it that cannot 
already be done with xpath as the naming scheme and xpath functions to 
work with them. Agreed, with xpath as the naming scheme the names are 
not unique, but is that necessary? I don't see that it is, at least not 
in the scope of the hierarchical profile we have.

One reason for why such a naming scheme should not be established, would 
be if such a naming scheme doesn't provide anything of value.

And if we are going to need a naming scheme, I doubt we are the first 
one to think of this problem, so defining our own subset of xpath is 
probably not the right way to go. At least not until we have done a 
thorough research on the issue.

Best regards,
Erik


Rich.Levinson wrote:
> Hi Erik,
>
> I understand your concern re: xpath, in particular, however, XML 
> documents are well formed hierarchies and there is no reason why a 
> standard naming scheme for the nodes that would incorporate the type 
> of scoping used for filename and URL policies should not be 
> established. In the absence of such a std, xpath expressions may be a 
> reasonable place to start, esp. w a limited syntax such as that was 
> proposed by Jan in the original issue.
>
>    Thanks,
>    Rich
>
>
> Erik Rissanen wrote:
>> Rich,
>>
>> I maintain that the paradigm of matching xpath expressions with 
>> regular expressions is flawed. XPath is a matching language in 
>> itself, and we should not make an attempt to define another layer of 
>> string matching on top of it because:
>>
>> 1. It is a complex task to do so, and it is very easy to make a mistake.
>>
>> 2. It is wasted effort since there are already xpath matching 
>> functions in XACML which work perfectly well.
>>
>> I agree that it could be a good idea to suggest how an implementation 
>> could construct the xpath expressions in order to help implementers 
>> and users alike, but that should not be normative. But I think that 
>> kind of advice belongs to some implementation guide document, rather 
>> than the standard specification itself.
>>
>> Best regards,
>> Erik
>>
>>
>> Rich.Levinson wrote:
>>> Significant changes have been proposed to the hierarchical/multiple 
>>> profiles and some related changes in the core as well as outlined in 
>>> these messages:
>>> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00001.html
>>> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00000.html
>>> as well as the OGC Engineering Report document attached to the first 
>>> message.
>>>
>>> Speaking for myself and as member of the XACML TC, I much appreciate 
>>> the effort that went into the analysis of the core spec and these 
>>> profiles by the GeoXACML group, and particularly, Jan Herrmann 
>>> (Chair: GeoXACML SWG), who presented this material to us this summer 
>>> (info for pres in these minutes):
>>> http://lists.oasis-open.org/archives/xacml/200907/msg00017.html
>>>
>>> The issues raised in these emails have been catalogued in the 
>>> spreadsheet prepared by Erik:
>>> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
>>> as well as other issues that have been raised in the public review 
>>> period.
>>>
>>> I believe there are significant substantive issues that remain to be 
>>> addressed, in particular, in the hierarchical profile, in the area 
>>> of XML document resources, that were not visited within the scope of 
>>> changes to the hierarchical profile in 3.0.
>>>
>>> *****************************************************************
>>> This particular issue, CD-1 #11 appears to me to be a good starting 
>>> point to begin to address the overall issue of the handling of XML 
>>> resources in the hier/multiple profiles. I will repeat the text of 
>>> the issue here, and after that, comment on it, along with some 
>>> starting suggestions as to how to address it (actually, I have 
>>> edited it slightly for readability and inserted a couple clarifying 
>>> notes that I needed to understand a couple of points):
>>>
>>> *******************************************
>>> Issue CD-1 #11:
>>>
>>> Comment 2: Line 56: interoperability problem
>>> “[XPath] expressions can be used to reference nodes in this document 
>>>  in a standard way, and can provide unique representations for a 
>>> given  node in the document.” ([3], S. 3).
>>>  Forcing to use XPath expressions referring to exactly one node in 
>>> the  <ResourceContent> element limits the representation 
>>> possibilities,  which is a step in the right direction.
>>>  But this still leaves some flexibility for no real reason and might 
>>>  therefore cause interoperability problems. Example:
>>>
>>>  A resource-id attribute value in an individual decision request 
>>> might be:
>>>
>>>     /Request[1]/Resource[1]/ResourceContent[1]      
>>> /wfs:FeatureCollection[1]/gml:featureMember[1]/Building[1]
>>>
>>>  A rule e.g. allowing access to building nodes will have a predicate 
>>> like  the following:
>>>
>>>     regexp-string-match(     resource-id,     
>>> /Request[1]/Resource[1]/ResourceContent[1]
>>>      /wfs:FeatureCollection\[\d+\]
>>>      /gml:featureMember\[\d+\]
>>>      /Building\[\d+\]$)
>>>
>>>  By using such a predicate all decision requests referring to 
>>> “Building”  nodes will match and the rule will get evaluated.
>>>     (note: $ (dollar) Matches at the end of the string the      
>>> regex pattern is applied to.      Matches a position rather than a 
>>> character.      Most regex flavors have an option to make the dollar 
>>> match      before line breaks (i.e. at the end of a line in a file) 
>>>      as well.      Also matches before the very last line break if 
>>> the string      ends with a line break.        
>>> http://www.regular-expressions.info/reference.html )
>>>
>>>  In this example we used the abbreviated XPath syntax to refer to 
>>> exactly  one node.
>>>  In case the Context Handler uses unabbreviated XPath syntax when 
>>> deriving  the individual decision requests from a global decision 
>>> request the rule  won’t match any more.
>>>     (note: abbreviated syntax in xpath spec:
>>>       http://www.w3.org/TR/xpath#path-abbrev
>>>      refers to prefixes like child:: etc.
>>>
>>>        "The most important abbreviation is that child::         can 
>>> be omitted from a location step. In effect,         child is the 
>>> default axis.
>>>         For example, a location path div/para is short         for 
>>> child::div/child::para.")
>>>
>>>  Conclusion:
>>>   In order to get a unique representation for a node in the document 
>>> it   should be specified more precisely which syntax the XPath 
>>> values of   the resource-id attribute have to conform.
>>>   We recommend to use a syntax as shown in the example (i.e.
>>>     /elementNodeName[integer]/../elementNodeName [integer]
>>>   in case of element nodes and
>>>     /elementNodeName[integer]/../@attributeNodeName
>>>   in case of attribute nodes.
>>>  Additionally the question is whether the XPath expressions should   
>>> always refer to the <xacml-context:Request> element as its context   
>>> node or to the content element that is additionally identified   
>>> through the category attribute?
>>>  If you choose option one
>>>     (i.e. the <Request> element is the context node),
>>>   then XPath expressions will always start with
>>>     /Request...
>>>   (c.p. e.g. line 4907 in the core XACML 2.0 specification).
>>>
>>>  Remark: Note that it is not possible to use the XPath node matching 
>>>   function in order to make the exact form of the xpath expression   
>>> irrelevant.
>>>   The reason is that XPath node match functions imply certain 
>>> limitations   in our use case like:
>>>
>>>     • only predicates supported by XPath can be used to define 
>>> content       dependant authorizations à limited expressiveness
>>>
>>>     • no pointers to XACML decision request data inside an XPath 
>>> predicate
>>>       (e.g. permit access if /bulding[owner = subject-id])       
>>> àlimited expressiveness
>>>
>>>     • filtering is not possible
>>>
>>>     – the XACML decision response refers to the Web Service request 
>>>       or response as a whole
>>>
>>>   *******************************************
>>>
>>> The above looked ok when I inserted it, hopefully the editors along 
>>> the way don't mess it up too much. :)
>>>
>>> In any event, here are a couple of initial comments on the issue:
>>>
>>>    1. From the above expression, where
>>>       regexp-string-match(resource-id, "xpath string") is given as a
>>>       sample predicate for a Rule, and the follow-up comments on
>>>       "recommended syntax" for the xpath expressions, it is clear to
>>>       me at least, that one significant paradigm for XML resource
>>>       processing is to treat the xpath expression as a string, and as
>>>       an instance of an explicit identity name for a resource.
>>>       Similarly, regular expressions can be applied to this syntax for
>>>       the purpose of "scoping" tests to determine whether the Rule is
>>>       applicable.
>>>       IMO, this comes very close to putting the xpath string on the
>>>       level of a URI, and in fact, w escape sequences, I think we can
>>>       probably consider it an instance of the URI strings described in
>>>       section 2.2 of the hierarchical profile. Therefore, part of my
>>>       suggested change to the profile is to consider this paradigm in
>>>       the context of representation of the identities associated with
>>>       XML document resources.
>>>    2. This also raises an issue of processing of XML document
>>>       resources. In particular, is it necessary to always send the
>>>       whole XML document in each of the detailed requests, which
>>>       probably entails significant xml processing overhead, in
>>>       general, even considering optimizations for non-xml processing
>>>       of the data. In some ways, I see this as equivalent to sending a
>>>       complete directory listing of all the files in a file system
>>>       with each request for access to a file. While, that is ok in
>>>       some situations (maybe?), I expect people will look to
>>>       alternatives, esp.in the area of send just the file name that is
>>>       being requested and setting policies to parse the file name
>>>       against scope file name expressions of the type described in the
>>>       multiple resource profile.
>>>       The bottom line here is that I agree that there should be
>>>       standard xpath expression syntaxes specified as a best practice
>>>       for specific installations. Then given the standard syntax,
>>>       policies can be specified treating xpath expressions like file
>>>       names and determining if the xpath expression identifying the
>>>       requested resource, falls within the scope of an xpath
>>>       expression in the policy describing the nodes that particular
>>>       expression is targeting.
>>>       The recommendation is to give an example of this type of scoping
>>>       in section 2.1 and refer to section 2.2 as the broader context
>>>       within which the paradigm may be viewed as URI scoping 
>>> expressions.
>>>
>>> Please regard the above as an initial proposal which describes 
>>> roughly the type of changes that I think can be put in the profile 
>>> to address the issue that has been raised.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>> Erik Rissanen wrote:
>>>> The issue number refers to the XLS-sheet found in this email:
>>>> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
>>>>
>>>> The commenter says that the way an xpath expression identifying a 
>>>> resource is not defined strictly enough that the expression can be 
>>>> used in string match functions.
>>>>
>>>> However, the constructed xpath expression is intended to be used 
>>>> with xpath match functions, where the exact, characted by 
>>>> character, form does not matter.
>>>>
>>>> I propose that we make no change.
>>>>
>>>> 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
>>
>>