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] Updated working drafts posted

Great work, Erik. Thanks.

Some comments inline. 

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Tuesday, December 15, 2009 13:30
> To: xacml
> Subject: [xacml] Updated working drafts posted
> => Regarding the XPath node match, equal and count functions, 
> I cannot think of any simple general transformation into an 
> equivalent attribute selector and I have not received any 
> proposal from other TC members, so I am leaving the xpath 
> node functions as they are.

I did this for xpath-node-count, but haven't yet defined the other two.
I will try to have these defined before the next TC meeting.

> => I have not seen any proposals for names for the new XML 
> attributes in attribute selector, so I am going with this: 
> The old RequestContextPath is renamed to simply "Path" and 
> the new attribute is called "ContextSelectorId".

I had thought that "RequestContextPath" would be retained for backward
compatibility.  The new "Path" attribute would be the preferred synonym.

> => Paul's original proposal contained 
> multiple-content-selectors for all the different categories 
> (resource, subject, action, and so on), so I have allowed the 
> use of the XPath based multiple scheme also for other 
> categories than the resource. I think it may be useful to be 
> able to ask for decisions for multiple subjects where the 
> subjects may be described with XML content.

The result of the discussion was that neither "content-selector" nor
"multiple:content-selector" would be be category-specific, but would
inherit their category from parent::Attributes/@Category.  They can be
used in any category, so Erik has done the right thing.

> => It is unclear to me what should happen with obligations in 
> combined decisions. I thought about it and it doesn't quite 
> make sense to combine the obligations since each obligation 
> is associated with a single decision on a particular resource 
> (and subject, action, etc). For instance, an obligation such 
> as "log-access-to-the-resource" does not make sense for a 
> combined decision since it is not clear how the combined 
> decision relates to the use of any specific resource. So, I 
> made the specification so a combined decision never includes 
> any obligations. If obligations are important, then the PEP 
> has to request the full list of individual decisions with the 
> obligations.

I agree.  The only other way is to allow
"ObligationCombiningAlgorithms", and that would be complicated and
probably not be required for many real-world use cases.

> => Paul posted examples of some clever use of an 
> AttributeSelector. See here for instance:
> http://wiki.oasis-open.org/xacml/XpathDiscussion?action=recall&rev=10
> I think that kind of use is not allowed by the current 
> definition of AttributeSelector since it requires that the 
> xpath selects textual content from a node. See the following 
> piece from the spec:
> --8<--
> Each node selected by the specified XPath expression MUST be 
> a text node, an attribute node, an element node, a processing 
> instruction node or a comment node. The string representation 
> of the value of each node MUST be converted to an attribute 
> value of the specified data-type, and the result of the 
> AttributeSelector is the bag of the attribute values 
> generated from all the selected nodes.
> If the node selected by the specified XPath expression is not 
> one of those listed above (i.e. a text node, an attribute 
> node, a processing instruction node or a comment node), then 
> the result of the AttributeSelector SHALL be "Indeterminate" 
> with a StatusCode value of 
> "urn:oasis:names:tc:xacml:1.0:status:syntax-error".
> --8<--

I don't know what the motivation was for this restriction, but it
appears to be unnecessary.  I suggest revising the first paragraph
(quoted above) to:

=== proposed ===
If the XPath expression selects a sequence of XML nodes (text,
attribute, element, processing instruction, or comment nodes), then the
string representation of the value of each node MUST be converted to an
attribute value of the specified data-type, and the result of the
AttributeSelector is the bag of the attribute values generated from all
the selected nodes.

The XML structure may be just as important as its content, and if you
limit xpath to just node selections you will prevent many useful tests
(e.g., for existence, position, or number of nodes).

Any xpath processor is going to be capable of evaluating non-node xpath
expressions as well as node selectors, so I do not see this as an
implementation barrier.  If AttributeSelector is implemented at all, it
should handle the full range of xpath 1.0 or 2.0.

> Paul's xpath expression on the other hand evaluate to Boolean 
> or integer data types within the xpath language, rather than 
> selecting nodes, so they don't conform to this specification 
> and are not allowed.

All types of xpath expression should be allowed, as described above.

> I thought about dropping this restriction, but when I look at 
> for instance the Java 5 XPath API, it is unclear to me how 
> the more generalized selector could be implemented. The API 
> requires that the Xpath evaluation method is invoked with a 
> parameter which specifies the return type of the xpath 
> expression. There are a couple of supported data types such 
> as node set, string and Boolean. In other words, if the XACML 
> implementation evaluates the xpath expression, it must know 
> beforehand whether it expects a Boolean or a string, which 
> would depend on the form of the expression.

The AttributeSelector must define the expected datatype, so the XACML
application would be able to specify the return type using the Java 5
xpath API.

> I haven't tested, but when I read documentation on the web, 
> it says that the XPath API will throw an exception if the 
> conversion between the actual and expected return type cannot 
> be made. So it seems unclear to me how to fix this, so I am 
> leaving it as it is.

Any errors would be due to defects in the policy or the xml instance.  I
don't see that anything would be underspecified.

It is very important to be able to use general xpath expressions to test
structural as well as content information.  I don't think we should
exclude this functionality.


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