Re: [xacml-comment] Comments on the XACML 3.0 commitee draft 1 (16April 2009) during the public review period

[Erik Rissanen <erik@axiomatics.com>]

Jan,

Thank you for your comments. I am collecting all the comments we have 
received into a single sheet, and I have included yours.

See inline for answers to the questions you had.

Best regards,
Erik

Jan Herrmann wrote:
>
> *Open questions:*
>
> *Q1:*
>
> I am wondering whether it is best practise to put namespace 
> definitions of XML data under a Content element in the first child 
> element of the Content element. Isn’t it maybe more appropriate to 
> include it to the name space definitions of the whole XACML decision 
> request. Doing so might simplify/help validation of the decision 
> request with out of the box tools.
>

It should not matter. XACML is based on XML and the normal processing of 
namespace declarations applies, so you can put your declarations 
anywhere in the file, as long as you follow the XML namespaces rules. It 
might be more efficient to put them at the top level element if the same 
namespace is needed in many places in the same file, so you don't have 
to declare it repeatedly.

> *Q2:*
>
> What is the explanation for the proposed target structure? What were 
> the decision that led to the AND, OR ordering under the target 
> element? Why didn’t you use e.g. CNF?
>

I don't know. 3.0 uses a similar structure as 2.0 (in fact the same I 
think if you take into account that a 2.0 target can contain multiple 
subject categories), but I don't know what the motivation for the 
original form was. I would suspect that in practice this form is more 
comfortable for people to work with since using CNF means negating and 
reordering the conditions, while the current structure keeps each 
subject, resource, etc, together as single unit.

> *Q3:*
>
> 3054: do not make use of the name space axis.. why?
>

The namespace axis has been deprecated in XPath 2.0. I don't understand 
why, but I thought it makes sense to not use a deprecated feature. None 
of the XACML TC members is an expert on XPath so we would appreciate a 
thorough review on this section if you know someone who understand XPath 
really well.

> *Q4:*
>
> 3286: a match –id function should be easily indexable? What is your 
> definition of easily indexable?
>

This is a "SHOULD" statement which suggests that a target should be 
efficient to evaluate. I don't have a good definition, and I don't think 
it matters. What is easily indexable would depend on the context and 
relative to other overheads in a full system.