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] review of the XACML 3.0 core draft 15


1. Jan's suggestion is OK, but we must change "it" to "the Category attribute".  (Otherwise the referent of "it" is ambiguous.)
 
2. I do not agree with this suggestion.  The point of this description is to focus on the data structure constructed from the xml content of <Content>.  Step 1 specifies how this data structure is to be constructed.  There should be no further reference to the XACML xml wrapper in this description.
 
3. This would only apply when constructing a primitive XACML type from a node.  If you want to do anything else you must define a custom datatype and a constructor function that takes a nodeset and returns an object of the correct type.
 
4. Yes, this was discussed in the notes recently from Erik and me (http://lists.oasis-open.org/archives/xacml/201001/msg00024.html).  XACML should only specify the behavior for constructing primitive XACML types; and it should state that all other behavior is implementation-dependent.
 
Regards,
--Paul


From: Jan Herrmann [mailto:herrmanj@in.tum.de]
Sent: Tuesday, January 05, 2010 10:34
To: 'XACML TC'
Subject: [xacml] 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:

1.

> 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.

> 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.

 

3.

> 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>)

 

4.

> 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
________________________________________

 



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