OASIS eXtensible Access Control Markup Language (XACML) TC

Paul, All,

Thanks Paul for the xpath proposal write up at

http://wiki.oasis-open.org/xacml/XpathDiscussion

Permanent link to the version I am discussing in this email:

http://wiki.oasis-open.org/xacml/XpathDiscussion?action=recall&rev=1

It seems mostly good as far as I understand it and does not appear to 
have the performance issues that some of the ideas which have been 
floating around earlier.

I have a few questions:

1. Regarding the request model, you propose a new element 
Request/Content[@Category="general"]. Can't we make it 
Request/Attributes[@Category="general"]/Content instead? It would have 
the same capabilities and the benefit is that we don't need to change 
the current schema or introduce new constructs to reach the new 

Erik, thanks for your review and comments.  See inline and revised page
at http://wiki.oasis-open.org/xacml/XpathDiscussion?rev=3. 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Friday, December 04, 2009 06:02
> To: xacml
> Subject: [xacml] Paul's xpath proposal
> 
> 
> 1. Regarding the request model, you propose a new element 
> Request/Content[@Category="general"]. Can't we make it 
> Request/Attributes[@Category="general"]/Content instead? It 
> would have the same capabilities and the benefit is that we 
> don't need to change the current schema or introduce new 
> constructs to reach the new 

Hi Paul,

See comments inline.

On 2009-12-04 15:50, Tyson, Paul H wrote:
> Erik, thanks for your review and comments.  See inline and revised page
> at http://wiki.oasis-open.org/xacml/XpathDiscussion?rev=3.
>
>    
>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Friday, December 04, 2009 06:02
>> To: xacml
>> Subject: [xacml] Paul's xpath proposal
>>
>>
>> 1. Regarding the request model, you propose a new element
>> Request/Content[@Category="general"]. Can't we make it
>> Request/Attributes[@Category="general"]/Content instead? It
>> would have the same capabilities and the benefit is that we
>> don't need to change the current schema or introduce new
>> constructs to reach the new

Hi Paul,

I gave it some more thought. Your example can probably be fixed by 
casting the xpath boolean value type into a string representation within 
the xpath expression. But I don't know the syntax myself, and I am not 
sure it is available in xpath 1.

Best regards,
Erik


On 2009-12-04 10:29, Erik Rissanen wrote:
> Hi Paul,
>
> See comments inline.
>
> On 2009-12-04 15:50, Tyson, Paul H wrote:
>> Erik, thanks for your review and comments.  See inline and revised page
>> at http://wiki.oasis-open.org/xacml/XpathDiscussion?rev=3.
>>
>>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>>> Sent: Friday, December 04, 2009 06:02
>>> To: xacml
>>> Subject: [xacml] Paul's xpath proposal
>>>
>>>
>>> 1. Regarding the request model, you propose a new element
>>> Request/Content[@Category="general"]. Can't we make it
>>> Request/Attributes[@Category="general"]/Content instead? It
>>> would have the same capabilities and the benefit is that we
>>> don't need to change the current schema or introduce new
>>> constructs to reach the new

Erik,

I revised the wiki page to correct the example, and to show native xpath
replacements for all XACML xpath-* functions.  These are correct in
theory, but I don't have a testbed to test them.

I was not aware that AttributeSelector specified the use of an xpath
constructor function for its return value, so I was expecting "effective
boolean value".  As you said in your latest, the problem is easily fixed
by casting within xpath.  This is only a minor problem for people (like
me) who are accustomed to XSLT's "Principle of least surprise" approach.

As far as I can tell (without testing), the only syntax difference for
Xpath 1.0 is in the node equality test.  This is noted in the wiki page.

Regards,
--Paul

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Sunday, December 06, 2009 08:48
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] Paul's xpath proposal
> 
> Hi Paul,
> 
> I gave it some more thought. Your example can probably be 
> fixed by casting the xpath boolean value type into a string 
> representation within the xpath expression. But I don't know 
> the syntax myself, and I am not sure it is available in xpath 1.
> 
> Best regards,
> Erik
> 
> 

Thanks Paul,

Did you already update the wiki with the required cast? I couldn't find it.

Another question. In the examples the xpath you are matching against is 
always a single location step. Would it still work with a path with 
multiple location steps? I get a feeling that there will be a 
difference. Can you do it without an absolute xpath anywhere? (Absolute 
xpaths cause problems for optimization because the span the request 
context and may also be a security risk since the 

Hi Erik,

See inline.

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Monday, December 07, 2009 07:06
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] Paul's xpath proposal
> 
> Thanks Paul,
> 
> Did you already update the wiki with the required cast? I 
> couldn't find it.
>

Are you seeing the latest at
http://wiki.oasis-open.org/xacml/XpathDiscussion?

In the example, I use count() in the RequestContextPath, which will
return an integer that fn:boolean() will use to construct a boolean
return value.
 
> Another question. In the examples the xpath you are matching 
> against is always a single location step. Would it still work 
> with a path with multiple location steps? I get a feeling 
> that there will be a difference. Can you do it without an 
> absolute xpath anywhere? (Absolute xpaths cause problems for 
> optimization because the span the request context and may 
> also be a security risk since the 

Hi Paul,

See inline.

On 2009-12-07 05:41, Tyson, Paul H wrote:
> Hi Erik,
>
> See inline.
>
>    
>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Monday, December 07, 2009 07:06
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: [xacml] Paul's xpath proposal
>>
>> Thanks Paul,
>>
>> Did you already update the wiki with the required cast? I
>> couldn't find it.
>>
>>      
> Are you seeing the latest at
> http://wiki.oasis-open.org/xacml/XpathDiscussion?
>
> In the example, I use count() in the RequestContextPath, which will
> return an integer that fn:boolean() will use to construct a boolean
> return value.
>    

Yes, I did see the count function. But I am uncertain that this will 
work. The XACML attribute selector requires a textual return value from 
the xpath expression. It is not defined in terms of the xs:boolean 
return value from the xpath expression. At least that is how I read the 
definition. Naturally, we could fix this and allow direct interpretation 
of xs:boolean.

>
>    
>> Another question. In the examples the xpath you are matching
>> against is always a single location step. Would it still work
>> with a path with multiple location steps? I get a feeling
>> that there will be a difference. Can you do it without an
>> absolute xpath anywhere? (Absolute xpaths cause problems for
>> optimization because the span the request context and may
>> also be a security risk since the