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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

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

Hi again Rich,

Just to give a simple example of some the complexities we would have to 
tackle if we start doing string matching on xpath expressions, consider 
these two expressions:

<AttributeValue DataType="...:xpath-expression" 
xmlns:foo="example.com/nsA" xmlns:bar="example.com/nsB">


<AttributeValue DataType="...:xpath-expression" 
xmlns:foo="example.com/nsC" xmlns:bar="example.com/nsD">

Both would match equally against string/regexp functions, but they are 
entirely different xpaths and refer to different resources.

Best regards,

Erik Rissanen wrote:
> 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 

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