review of the XACML 3.0 core draft 15

Hi Erik, *,

great job Erik incorporation all the things we discussed in the last weeks.

I added some suggestions, bugfixes etc. in the document.

Further I like Pauls simplifying proposal for the AttributeSelector stuff. Additionally Eriks remarks should be incorporated. Further I would change the following 4 sentences:

> Category [Required]

> This attribute SHALL specify the Attributes category of the <Content>

> element containing the XML from which nodes will be selected.

> It also indicates the Attributes category containing the applicable

> ContextSelectorId Attribute, if the element includes a

> ContextSelectorId xml attribute.

change the last sentence to:

If the element includes a ContextSelectorId xml attribute than it indicates the Attributes category containing the applicable ContextSelectorId Attribute.

> 2. Select a context node for xpath processing from this data structure.

> If there is a ContextSelectorId attribute, the context node shall be

> the node selected by applying the XPath expression given in the

> attribute value of the designated Attribute (in the Attributes

> category given by the AttributeSelector Category attribute). It shall

> be an error if this evaluation returns no node or more than one node.

> If there is no ContextSelectorId, the document node of the data

> structure shall be the context node.

replace the last two words by:

…one and only child of the corresponding <content> element.

> 4. Convert the text value of each selected node to the desired

> datatype, as specified in the DataType attribute.

delete: the text value of !!!! In GeoXACML a whole set of nodes is used to instantiate a attribute of DataType Geometry (e.g. <gml:Point><coordinates>…</gml:Point>)

> Each value shall be

> constructed using the appropriate constructor function from [XF]

> Section 5 listed below, corresponding to the specified datatype.

change to:

In case of XACML predefined Datatypes each value…

Further suggestions:

- maybe a little note should be added explaining why some text is printed in bold font.

Questions:

- why can’t obligations be associated with not-applicable decisions (c.p. line 1503)? E.g. assume users are not allowed to see the rules in general. In order to inform a user how to change a denied request it might be helpful for him to let him know how a certain rule looks like. The rule could be forwarded through an obligation in case of a not-applicable decision. Knowing the rule might help him reformulate his query is a policy conformant way.

- the PolicyIndetifierList mechanism might also be valuable for rules (i.e. RuleIdentifierList) – at least for testing purposes.

- CombinerParamters exist a a gerneral form (c.p. 5.17) and as ruleCombinerParameters(c.p.5.18), PolicyCombinerParameters (5.19) and PolicySetCombinerParameters (c.p. 5.10). why are different CombinerParameters elements needed.

Not to forget:

- namespace definitions in examples and in line 131 needs to be updated..

Final comments on the Mult and Hier. profiles follow tomorrow.

Best regards

Jan

________________________________________

Jan Herrmann
Dipl.-Inform., Dipl.-Geogr.

wissenschaftlicher Mitarbeiter

Technische Universität München
Institut für Informatik

Lehrstuhl für Angewandte Informatik / Kooperative Systeme

Boltzmannstr. 3
85748 Garching

Tel: +49 (0)89 289-18692
Fax: +49 (0)89 289-18657

Raum:
www11.informatik.tu-muenchen.de
________________________________________

xacml message