OASIS eXtensible Access Control Markup Language (XACML) TC

All,

In issue 88 it has been proposed that all functions from XPath 2.0 be 
made available in XACML by means of a general mechanism.

I have looked at this issue and it seems to be doable.

Function calls in XPath 2 are defined here:

http://www.w3.org/TR/xpath20/#id-function-calls

In short, the call is written as a qname followed by its arguments. Such 
as this:

my:three-argument-function(1, 2, 3)

It would be simple to define some form of syntax which means that a 
particular XPath function is evaluated. It could naturally be done in a 
number of different ways.

The XPath 2 function library is defined here:

http://www.w3.org/TR/xquery-operators/


Potential issues I see:

- Do all the functions and data types make sense to XACML?

For instance, there is function called fn:node-name which returns the 
name of a DOM node. Would including this function and its associated 
data types make sense in XACML?

Another one is fn:error which raises an error. (BTW, some form of error 
raising capability would be good to have in XACML, for instance to make 
assertions about expected attributes in the request.)

Perhaps we should enumerate a list of functions and data types which we 
think make sense?

- XPath does some type conversion to function arguments. Are we 
comfortable with this, considering that XACML has been strictly typed?

- Are we happy with qnames as identifiers? Traditionally XACML has not 
done that. Perhaps we could create URIs from the qnames using 
namespace#name such as done in the XMLSchema data types. For instance 
http://www.w3.org/2005/xpath-functions#upper-case would convert a string 
to upper case. I searched the spec for a convention like this, but I 
couldn't find one, so we should probably not make up one.

BTW, the daytime and yearmonth durations are defined in the "op:" 
namespace. This namespace does not have a definition and the functions 
are not intended to be callable by users. Sadly, I was hoping that we 
would get our new function identifiers for the duration functions from 
the xpath spec.

So, assuming that we can go with qnames, we could do something like this:



(Alternatively we could overload the regular 

Hi Erik (and all),

I'm not sure if adding an additional element 

Hi Craig and all,

Yes, if we can avoid creating a different element, it would be good to 
avoid it.

But keep in mind that the identification of the xpath function happens 
in a completely different manner than the XACML function. For XACML it 
is like this:

Hi Erik,

What about your initial proposal for "[namespace]#[name]"?  The example in
this case being "http://www.w3.org/2005/xpath-functions#upper-case".

Regards,
Craig

---------------------------------------------------------------
Craig Forster
Software Engineer
IBM Australia Development Labs
Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/
HomeBlog == http://blogs.tap.ibm.com/weblogs/craigforster/
---------------------------------------------------------------


                                                                                                                               
  From:       Erik Rissanen 

Hi Craig,

The main problem I have with this is that if W3C has not defined these 
identifiers (like they have done for the basic XML schema types), then 
we are intruding on their namespace. I couldn't find anything supporting 
that they have defined such URIs. But maybe I just didn't find it.

Perhaps the best approach is simply that we "import" all the XPath 
functions with our own identifiers, like this:

urn:oasis:tc:xacml:...:xpath-function:upper-case

In this alternative we would make a long list of identifiers and each 
case we would refer to a specific function in the XPath spec.

In the end, I am not sure how general we can make the xpath function 
import feature, and, indeed, how desirable it is to make it fully general.

With a "fully general import" of xpath functions I mean a feature which 
defines a mapping scheme to xpath functions and does not enumerate 
specific xpath functions.

A problem with a fully general import is that some functions might not 
make sense in XACML.

A benefit might be that as XPath evolves, XACML implementations could 
implement new versions of XPath since XACML already supports versioning 
of XPath, in which case XACML gain the new functions from the new XPath 
version. On the other hand, this might be a problem instead. I am not 
sure how robust the XACML versioning of XPath is and how compatible new 
version of XPath would be with the function import mapping. Or how 
desirable it is that different XACML implementations use different 
versions of XPath.

/Erik


Craig Forster wrote:
> Hi Erik,
>
> What about your initial proposal for "[namespace]#[name]"?  The example in
> this case being "http://www.w3.org/2005/xpath-functions#upper-case".
>
> Regards,
> Craig
>
> ---------------------------------------------------------------
> Craig Forster
> Software Engineer
> IBM Australia Development Labs
> Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/
> HomeBlog == http://blogs.tap.ibm.com/weblogs/craigforster/
> ---------------------------------------------------------------
>
>
>                                                                                                                                
>   From:       Erik Rissanen 

Hi Erik,

Given the concerns about wholesale importing of the XPath functions, then
perhaps we should move back to simply expanding the list of functions in
XACML 3.0 based on the XPath functions (and possibly others) that make
sense?

Regards,
Craig

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


                                                                                                                                   
  From:       Erik Rissanen 

Hi Craig,

Yes, I am leaning towards this as well.

What data types and functions are those which we should "import" from XPath?

The function list is here:

http://www.w3.org/2005/xpath-functions/

When I looked at that list I just noticed that it defines a mapping of 
the functions to URI identifiers like this (see section 1.1 at the above 
page):

http://www.w3.org/2005/xpath-functions/#max

I didn't find this earlier. We can use these as the identifiers, so we 
won't need to make up our own identifiers nor define an 

I like this approach.

I am completely opposed to specifying qnames in content under any circumstances because of the issues of C14N for signatures.

I think we need to separate the issue of specifying identifiers from specifying implementation.

1. If suitable definition of an implementation exists in some other stable specification, we should reference it. (In the case of XACML 2.0 we referenced a draft which we expected to become final. It did not, and when OASIS submitted XACML 2.0 to the ITU-T, this was an issue. In response, Abbie copied all the definitions into the ITU-T spec.)

2. If we reference such an implementation, our first choice for an identifier should be the identifier defined by the other organization in their namespace. 

3. If we are sure no such identifier exists, then we should define an identifier in our URN space. (urn:oasis:names:tc:xacml:...)

Hal

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Tuesday, June 10, 2008 7:25 AM
> To: Craig Forster
> Cc: XACML TC
> Subject: Re: [xacml] Issue 88, general XPath function calls
> 
> Hi Craig,
> 
> The main problem I have with this is that if W3C has not defined these
> identifiers (like they have done for the basic XML schema types), then
> we are intruding on their namespace. I couldn't find anything supporting
> that they have defined such URIs. But maybe I just didn't find it.
> 
> Perhaps the best approach is simply that we "import" all the XPath
> functions with our own identifiers, like this:
> 
> urn:oasis:tc:xacml:...:xpath-function:upper-case
> 
> In this alternative we would make a long list of identifiers and each
> case we would refer to a specific function in the XPath spec.
> 
> In the end, I am not sure how general we can make the xpath function
> import feature, and, indeed, how desirable it is to make it fully general.
> 
> With a "fully general import" of xpath functions I mean a feature which
> defines a mapping scheme to xpath functions and does not enumerate
> specific xpath functions.
> 
> A problem with a fully general import is that some functions might not
> make sense in XACML.
> 
> A benefit might be that as XPath evolves, XACML implementations could
> implement new versions of XPath since XACML already supports versioning
> of XPath, in which case XACML gain the new functions from the new XPath
> version. On the other hand, this might be a problem instead. I am not
> sure how robust the XACML versioning of XPath is and how compatible new
> version of XPath would be with the function import mapping. Or how
> desirable it is that different XACML implementations use different
> versions of XPath.
> 
> /Erik
> 
> 
> Craig Forster wrote:
> > Hi Erik,
> >
> > What about your initial proposal for "[namespace]#[name]"?  The example
> in
> > this case being "http://www.w3.org/2005/xpath-functions#upper-case".
> >
> > Regards,
> > Craig
> >
> > ---------------------------------------------------------------
> > Craig Forster
> > Software Engineer
> > IBM Australia Development Labs
> > Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/
> > HomeBlog == http://blogs.tap.ibm.com/weblogs/craigforster/
> > ---------------------------------------------------------------
> >
> >
> >
> >   From:       Erik Rissanen 

Hi Craig and all,

This is an interesting idea. My initial worry is that the XML identifier 
is not enough. A PDP would always have to implement actual processing 
logic for any particular data type and function. How would this be 
handled do you think? How general should it be?

In the end I think we would have to enumerate the types that an 
implementation has to support, or (equivalently) refer to a 
specification which does so.

What do you mean when you say "This means the decision engine would be 
responsible for maintaining the semantics of the AttributeValue 
containing an XML element"? I didn't understand this. And perhaps you 
could elaborate on what you mean with "Raw XML types". Do you mean the 
types defined in XML schema here: http://www.w3.org/TR/xmlschema-2/

How would the types be identified? With the normal URIs such as 
http://www.w3.org/2001/XMLSchema#string?

How would what you propose be different from that we just enumerate more 
of these URIs in the standard?

Regards,
Erik

Craig Forster wrote:
>
> I've often wondered about the support for raw XML types as a first-level
> DataType in XACML.  Perhaps this could be added to 3.0?
>
> For example, you could then specify:
>
> 
>
> This means the decision engine would be responsible for maintaining the
> semantics of the AttributeValue containing an XML element.  It also means a
> lot more XPath functions (include node-name) would be meaningful in the
> XACML context.
>
> Regards,
> Craig
>
> ---------------------------------------------------------------
> Craig Forster
> Software Engineer
> IBM Australia Development Labs
> ---------------------------------------------------------------
>
>
>                                                                                                                                   
>   From:       Erik Rissanen 

Hi Erik,

I wasn't proposing anything this complex, just a simple DataType identifier
that signifies XML is contained within.  Something like
"urn:oasis:names:tc:xacml:3.0:data-types:xml".

The decision engine would then need to keep these types as XML blobs (DOM
objects, probably), and then made available to whatever functions require
it.  Such functions would include whichever XPath functions, such as
node-count, require an XML element as an input.

Would this be useful, as opposed to defining a domain-specific DataType for
the XML element contained within?  I'm not sure on that one...  I do think
we need better native handling of raw XML data though, even if it's a set
of conventions that we establish and use in our core profiles.

Regards,
Craig

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


                                                                                                                               
  From:       Erik Rissanen 

Hi Craig,

Ok, than I understand you. Which functions do you think we need for 
using this data type?

Also, we already have the