OASIS eXtensible Access Control Markup Language (XACML) TC

All,

I had a look at Craig's original post on this issue with the intention 
of proposing which functions we should import from xpath. Craig's post 
is here:

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

He proposes these functions as a start:

 - 

Hi Erik,

Thanks for summarising the conversations to date.  I agree that our
investigations have shown that generally importing XPath functions is
incompatible with the XACML data model.

So apart from the functions I've listed, does anyone else have suggestions
about what other new functions are needed for 3.0?

Regards,
Craig

---------------------------------------------------------------
Craig Forster
Software Engineer
IBM Australia Development Labs
---------------------------------------------------------------


                                                                                                                               
  From:       Erik Rissanen 

All,

I have not seen any more proposals for new functions, so I propose that 
the following is added to the next core 3.0 working draft:


urn:oasis:names:tc:xacml:2.0:function:string-starts-with

This function SHALL take two arguments of data-type 
"http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the first string begins with the second string, and false otherwise.


urn:oasis:names:tc:xacml:2.0:function:uri-starts-with

This function SHALL take a first argument of data-type  
"http://www.w3.org/2001/XMLSchema#anyURI" and an a second argument of 
data-type "http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the URI converted to a string begins with the string, and false otherwise.

urn:oasis:names:tc:xacml:2.0:function:string-ends-with

This function SHALL take two arguments of data-type 
"http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the first string ends with the second string, and false otherwise.


urn:oasis:names:tc:xacml:2.0:function:uri-ends-with

This function SHALL take a first argument of data-type  
"http://www.w3.org/2001/XMLSchema#anyURI" and an a second argument of 
data-type "http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the URI converted to a string ends with the string, and false otherwise.

urn:oasis:names:tc:xacml:2.0:function:string-contains

This function SHALL take two arguments of data-type 
"http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the first string contains the second string, and false otherwise.

urn:oasis:names:tc:xacml:2.0:function:uri-contains

This function SHALL take a first argument of data-type  
"http://www.w3.org/2001/XMLSchema#anyURI" and an a second argument of 
data-type "http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the URI converted to a string contains the string, and false otherwise.

urn:oasis:names:tc:xacml:2.0:function:string-substring

This function SHALL take a first argument of data-type 
"http://www.w3.org/2001/XMLSchema#string" and a second and a third 
argument of type "http://www.w3.org/2001/XMLSchema#integer" and SHALL 
return a "http://www.w3.org/2001/XMLSchema#string".  The result SHALL be 
the substring of the first argument beginning at the position given by 
the second argument and ending at the position before the position given 
by the third argument. The first character of the string has position zero.


urn:oasis:names:tc:xacml:2.0:function:uri-substring

This function SHALL take a first argument of data-type 
"http://www.w3.org/2001/XMLSchema#anyURI" and a second and a third 
argument of type "http://www.w3.org/2001/XMLSchema#integer" and SHALL 
return a "http://www.w3.org/2001/XMLSchema#string".  The result SHALL be 
the substring of the first argument converted to a string beginning at 
the position given by the second argument and ending at the position 
before the position given by the third argument. The first character of 
the URI converted to a string has position zero.


urn:oasis:names:tc:xacml:2.0:function:string-equal-ignore-case

This function SHALL take two arguments of data-type 
"http://www.w3.org/2001/XMLSchema#string" and SHALL return a 
"http://www.w3.org/2001/XMLSchema#boolean".  The result SHALL be true if 
the first string equals the second string when character case is 
ignored, and false otherwise.


Open issues:

- Could we live without the URI-variants since there is an URI to string 
conversion function in 3.0?

- Would we like to overload the substring functions such that a negative 
index indicated the beginning/end of the string? This would expand the 
functionality of the proposed functions. But could it lead to more hard 
to detect errors in policies?

- How is case conversion handled?

Since we use the XML string type, we are dealing with international 
characters and case conversion seems to depend on in which language the 
string is used. I found some references here: 
http://unicode.org/reports/tr21/tr21-5.html though I haven't read that 
in detail.

The Java string class javadoc contains the following text "Case mapping 
relies heavily on the information provided by the Unicode Consortium's 
Unicode 3.0 specification. The specification's UnicodeData.txt and 
SpecialCasing.txt files are used extensively to provide case mapping."

The Java implementation of the case conversion functions depend on the 
locale, BTW.

Does anyone know if the Java implementation conforms to some universally 
accepted specification? It would be nice if there is such a 
specification and we could refer to it easily, so no special trickery 
would be needed in XACML implementations (on Java or any other common 
language).

Another issue which has to be taken into account is that it looks to me 
that in general converting to upper case and testing for equality, vs, 
converting to lower case and testing for equality could yield different 
results. We would have to define either mode.

Does anybody know of an expert on these matters?

Best regards,
Erik

Craig Forster wrote:
> Hi Erik,
>
> Thanks for summarising the conversations to date.  I agree that our
> investigations have shown that generally importing XPath functions is
> incompatible with the XACML data model.
>
> So apart from the functions I've listed, does anyone else have suggestions
> about what other new functions are needed for 3.0?
>
> Regards,
> Craig
>
> ---------------------------------------------------------------
> Craig Forster
> Software Engineer
> IBM Australia Development Labs
> ---------------------------------------------------------------
>
>
>                                                                                                                                
>   From:       Erik Rissanen 

On Jul 8, 2008, at 5:45 AM, Erik Rissanen wrote:

> Open issues:
>
> - Could we live without the URI-variants since there is an URI to  
> string conversion function in 3.0?
>
Since URIs are unique beasts I suggest the functions stay separate.

>
> - Would we like to overload the substring functions such that a  
> negative index indicated the beginning/end of the string? This would  
> expand the functionality of the proposed functions. But could it  
> lead to more hard to detect errors in policies?
>
I should have read the whole email first, I just typed up this  
suggestion :-P I think there is a lot of value in allowing the second  
argument of substring/matching function to be negative. My experience  
is that a lot more logic is is typically expended where the payload is  
(end of string) vs. the domain/host side. Being able to grab chars  
from the back allows one to forgo length functions, parse counts, etc.  
and I think can actually improve the accuracy of culling out the chars  
of interest.

> Another issue which has to be taken into account is that it looks to  
> me that in general converting to upper case and testing for  
> equality, vs, converting to lower case and testing for equality  
> could yield different results. We would have to define either mode.

I assume you referring specifically to only string functions here?  
Portions of URIs are case sensitive so I would think that the  
application of global case functions would be highly undesirable for  
matching purposes regardless of charset :)

b

bill parducci wrote:
>
> On Jul 8, 2008, at 5:45 AM, Erik Rissanen wrote:
>
>> Another issue which has to be taken into account is that it looks to 
>> me that in general converting to upper case and testing for equality, 
>> vs, converting to lower case and testing for equality could yield 
>> different results. We would have to define either mode.
>
> I assume you referring specifically to only string functions here? 
> Portions of URIs are case sensitive so I would think that the 
> application of global case functions would be highly undesirable for 
> matching purposes regardless of charset :)

Yes, the string-equals-no-case is defined only for strings, not for URIs.

Erik