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] | [Elist Home]


Subject: [xacml][schema] minutes 03-06


rgds


ernesto
ernesto carlisle hal michiharu anne tim polar 

Inside policies, how do we point to XACML context?
three techniques:

- implicit (by Qname)
- explicit via restricted XPath
- explicit via full XPath

Which one is better for XACML? this is a main open question. 

Ernesto: you need full XPath if you want to impose a condition on a part of the context to select another one for using in the predicates. But operators like ".." and functions can be dangerous as different XPaths may return the same value.

Polar made the point that we probably want to say things
such as the "principal that is the Doctor cannot be the same principal that
is the Pharmacist". So, we are forced to use "../" on the XPATH selection of the
"role" Attribute, but compare the names that are superior on the selection
path. 
An example could be:
<notEquals>

<Principals/SimplePrincipal/Attribute[@AttributeName="Role" and
@AttributeValue="Doctor"]/../PrincipalName>

<Principals/SimplePrincipal/Attribute[@AttributeName="Role" and
@AttributeValue="Parmacist"]/../PrincipalName>

</notEquals>

Hal: We need also to leave XPath core function; otherwise where would low level processing of values go?
Carlisle: Besides this, what is the rationale of not allowing full Xpaths? 
Tim, Hal: mainly simpler implementation.
Tim, Ernesto: Regardless our choice on XPath, anyway, we will need to specify normalization conventions in our Schema specification.

There is general consensus on the decision of supporting full XPaths, so implicit type coercion will be XPath's and if the policy writer does not  like it, you can use the XPath 1.0 core functions to pre-process context nodes' contents before comparing them to literals in the policies. The issue, anyway, may need further discussion as we may discover XPath functionalities that are not really needed in XACML and their mandatory support could add to complexity of the implementation.Also, it is agreed that we need to provide guidelines about how to perform comparisons using XPath in order to obtain the desired results.

Michiharu: We need to consider XPath 2.0. It is coming on fast but it is still in its infancy. It will be any way quite different from XPath 1.0.

Hal: This may be  a nuisance for us. Could an expression be syntactically valid in both versions but have two different semantics?

Michiharu: yes, for example order matters in XPath 2.0 but not in XPath 1.0; I will give a general report on this.

Anne: To address this problem, we should specify the version of XPath used in the policy.

There seem to be general consensus of this.

Tim: anyway, we should not be tying a version of XACML to a version of XPath.


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


Powered by eList eXpress LLC