OASIS eXtensible Access Control Markup Language (XACML) TC

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
________________________________________
  

  


Thanks Jan,


I will go through all this next week. I won't have the time to do it
this week.


Best regards,

Erik


On 01/05/2010 05:34 PM, Jan Herrmann wrote:

  
  
  
  

  
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

________________________________________
  

  
  

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

  


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:

  
  
  
  

  
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.



  

  

  
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.



  

  

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



  

  

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



  

  

  

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

  


I'm cleaning up the examples.



  

  
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