Re: [xacml] review of the XACML 3.0 core draft 15

[Erik Rissanen <erik@axiomatics.com>]

Hi Jan,

Here is a list of all your comments and what I did about them:

Comment j1: I added a link to XACML 2.0.

Comment j2: this is just a non-normative example in the introduction. We don’t need to make normative references here.

Comment j3: I don’t want to add any more combining algorithms at this stage, especially when no user has requested one.

Comment j4: this is just a non-normative example of one way to do it. We don’t need to expand it to cover all conceivable ways of achieving the same effect.

Comment j5: I agree that this statement has unclear meaning. It is not needed, so I am removing it.

Comment j6: I have added the patient email and the current time to the request.

Comment j7: I have kept it as “false”. Since it is a single decision request, the PEP will know that the answer applies to the resource it sent in the request.

Comment j8: Yes, we should use the new content-selector instead of the resource-id. I have updated this.

Comment j9: Yes, we could do that, but I am keeping the example as it is, which also works.

Comment j10: Yes, I will do so.

Comment j11: I did not add a note since this is just an example in the introduction, where we don’t need to make all normative specifications.

Comment j12: See comment 9.

Comment j13: Yes, I have changed it to content-selector.

Comment j14: I think the text is better as it is, so I am not adding the quotes.

Comment j15: I am keeping the text as it is since this is an example of just one way to do things.

Comment j16: Yes, I have added it.

Comment j17: Yes, I agree. “True” makes more sense for an obligation.

Comment j18: I think the text is ok as it is, so I did not change it.

Comment j19: If we would do that, the core schema would need to have lots of extension points in it all over the place. We chose to put the stuff needed by the current profiles directly in the schema. I am not changing that at this stage.

Comment j20: I updated the text as you proposed.

Comment j21: No, this should not be deleted. This is what defines how the construction is done.

Comment j22: I am keeping it as it is, as I think we agreed on the call last week.

Comment j23: ??

Comment j24: It means that the namespace prefixes valid at this element are used to resolve prefixes in the xpath expression.

Comment j25: It could be optional, but we want to avoid schema defaults, so it seems cleaner to have it mandatory, rather than optional.

Comment j26: I agree. I changed it to “The <Content> element has exactly one arbitrary type child element.”

Comment j27: I removed this text altogether since I don’t see why we should specifically point to the resource, in favor of subject, action, etc, which also influence the result.

Comment j28: ??

Comment j29: Well, maybe, but it’s too late to do that now in the 3.0 scope, so I am making no changes.

Comment j30: Yes, I agree. I don’t think that an attribute selector must be restricted to leaf nodes, so I am deleting “leaf”.

Comment j31: yes, I agree and I am making this change.

Comment j32: yes, the paragraph cross reference was wrong. I did not change the text otherwise though.

Comment j33: I am keeping the conformance clauses as they are since there has not been any decision to change the. I would prefer to keep them as they are, rather than to delay this any further.

Comment j34: The resource-id is still there, so I am not changing this. Content-selector is defined in the hierarchical profile.

Comment j35: I added the target-namespace identifier to the conformance section as “O”.

Comment j36: No change is required. This behavior is already defined by the way the stand alone XML data structure is constructed.

Comment j37: I am keeping this order. It works as well.

Comment j38: see j34

Comment j39: ??

See some other comments inline:


On 2010-01-05 17:34, Jan Herrmann wrote:

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

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…

 

 

I will handle all the above when I do Paul's suggested rewrite and you will see the result then. Paul already posted some comments to this, and I agree with him.

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

 

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.

I did open up this issue once, but I changed my mind. Although there are some cases where it would be nice to send obligations, or at the minimum advice, with a NotApplicable, with some more thought, it turns out to be dangerous because a response of NotApplicable with obligations is a contradiction in terms. On the other hand it says "does not apply" and on the other hand it says "you must do XYZ". Policies can get mixed up in unexpected ways, especially in combination with delegation, where a policy is not necessarily trusted.

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

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

Nobody has requested for this, so I think it is too late for it now. I am not changing anything for the next draft.

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

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

It's a data type hierarchy where the three latter inherit from the former. I'm sure it could be done differently, but I don't see any reason to change this now.

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

 

Not to forget:

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

 

I'm cleaning up the examples.

3A36AACFA94C4CF9B6AD4A87FC793BE8@lapschlichter55" type="cite">

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
________________________________________

 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php