RE: [xacml-comment] XACML 1.0 Committee Specification Comments

["Chopra, Dipak" <dipak.chopra@sap.com>]

Anne,

Thanks for your response.

Here are my comments.
> 2. What is the commonality between different Policy elements
 > in the same Policy Set? The requirement on line #354 seems to
 > indicate that the merging of different Policy elements into
 > Policy Set is governed by "a given action". Does it mean that
 > the cardinality between Policy Set and Action is 1 to 1? It
 > seems confusing as schema does not suggest that.
It is not "governed by" a given action.  The Policy elements in a
Policy Set will be evaluated "based on" the action that a
requester is attempting to make (as well as on attributes of the
subject and the resource), and the results of that evaluation are
merged using the policy-combination mechanisms in XACML.
I think changing the term "action" here to "access request" might
be more clear.
<dc>When I read the line #354, 355, I got the impression that this is about creating policy sets, but this is about combining rules and policies to evaluate authZ decision. I think changing the term "action" to "access request" makes it clear. At the same time, the objective of combining rules and
policies is to evaluate the consolidated authorization decision and not to create a policy set(?). I would say statement like "To provide a method for combining individual rules and policies to evaluate authZ decision that applies to a given access request" is more clear. Lines #400-403 indicate the
same.</dc>

 > 3. As Target can have multiple Resource and Action elements,
 > not every Action is valid for each Resource. But the current
 > schema allows to provide more non-existent access to
 > resources.

I don't know what "more non-existent access to resources" means.
Could you please clarify?

Yes, it is true that not every Action will apply to every
Resource in a Target.  The Target is designed to facilitate
indexing based on either Subject, Resource, or Action, and not on
combinations of Subject, Resource, and Action.  The "Condition"
element may be used to express relationships between particular
Resource attributes and particular Action attributes.

<dc>Yes I meant the same thing thing that not every Action will apply to every Resource in a Target. Thanks for the explanation.</dc>

> 9. There are two different types of resources. Functionality
 > resource and data-instance resource. For example, ManagePO
 > resource can be used to create/delete/modify an instance of
 > PO. So ManagePO is a type of functionality type resource and
 > instance of PO is a data-instance type resource. If we need to
 > mandate that this action of this data-instance type resource
 > can only be permitted by this functionality-type resource, how
 > do we enforce that?

If I am understanding you correctly, this could be enforced by
having the ManagePO "resource" be expressed in the Action element
of the Request, and the "PO" be expressed in the Resource element
of the Request.  In other scenarios, it might make sense for the
ManagePO "resource" to be an attribute of the PO resource.

<dc>Your solutions make sense. Although I got the idea. I just want to be sure, so here is my understanding of your solutions. 
a. If we have the ManagePO "resource" expressed in Action element, and then the corresponding "Rule" must have "Condition", which checks the existence of two "ActionAttributeDesignator" elements, for example "createPO and ManagePO", "deletePO and ManagePO", "modifyPO and ManagePO". 
b. In the other solution, where ManagePO "resource" is expressed as an attribute of PO resource, "Condition" must check the existence of "ActionAttributeDesignator" and "ResourceAttributeDesignator", for example "createPO and managePO" etc.
To check the existence of two attributes, we can use the logical function "present". The "Condition" can enforce that "present" function result on both attributes is same.</dc>

 -----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Tuesday, December 10, 2002 6:39 AM
To: Chopra, Dipak
Cc: XACML COMMENT; XACML TC
Subject: Re: [xacml-comment] XACML 1.0 Committee Specification Comments


Dipak Chopra,

Thank you very much for reviewing the XACML Specification and
submitting comments.  I have answered a few of them below, and I
have questions about a few of them, which I hope you will answer.

Anne Anderson

On 9 December, Chopra, Dipak writes: [xacml-comment] XACML 1.0 Committee Specification Comments

 > 1. Can PAP and PDP exchange Policy Set? Based on the Section
 > 3.1 Data Flow Model, it seems like only Policy can be
 > exchanged. If that is the case, how can PDP evaluate Policy
 > Set as mentioned in Section 7.7 Policy Set Evaluation?

Yes, the PAP and the PDP may exchange Policy Set.  The term
"policy" in this section is a generic term for both "Policy" and
"Policy Set".  This should probably be made more clear.

 > 2. What is the commonality between different Policy elements
 > in the same Policy Set? The requirement on line #354 seems to
 > indicate that the merging of different Policy elements into
 > Policy Set is governed by "a given action". Does it mean that
 > the cardinality between Policy Set and Action is 1 to 1? It
 > seems confusing as schema does not suggest that.

It is not "governed by" a given action.  The Policy elements in a
Policy Set will be evaluated "based on" the action that a
requester is attempting to make (as well as on attributes of the
subject and the resource), and the results of that evaluation are
merged using the policy-combination mechanisms in XACML.

I think changing the term "action" here to "access request" might
be more clear.

 > 3. As Target can have multiple Resource and Action elements,
 > not every Action is valid for each Resource. But the current
 > schema allows to provide more non-existent access to
 > resources.

I don't know what "more non-existent access to resources" means.
Could you please clarify?

Yes, it is true that not every Action will apply to every
Resource in a Target.  The Target is designed to facilitate
indexing based on either Subject, Resource, or Action, and not on
combinations of Subject, Resource, and Action.  The "Condition"
element may be used to express relationships between particular
Resource attributes and particular Action attributes.

 > 4. What is the significance of an Obligation with
 > FulfillOn="Deny"? Which use case needs this feature?

A use case is where the PEP has an obligation to "Log denied
access attempt" in the case of a Deny.

 > 5. Line #2675, scope can be "Descendants" or "Children" as
 > mentioned on lines #2907, 2908 in the case of multiple
 > results.

You are correct.  Line 2675 should be changed to include both
"Descendants" and "Children".

 > 6. Section 7.6 Policy Evaluation. The table should be Policy
 > truth table.

You are correct.  This change should be made.

 > 7. Section 7.7 Policy Set Evaluation. The table should be
 > Policy Set truth table.

You are correct.  This change should be made.

 > In this table, what is the meaning of
 > "Effect" of Policy. As far as schema is concerned, Policy does
 > not have this attribute. Only Rule has Effect
 > element. Probably the right statement "At least one policy
 > value has the calculated effect value".

The term "result" rather than "effect" should probably be used
here.  "Effect" can be only "Permit" or "Deny", while a result
may be "Permit", "Deny", "Indeterminate", or "NotApplicable".

 > 8. Line #2907, 2908. It seems like authorization decision MAY
 > include multiple results based on the structure of resource
 > sub-tree. I think this mechanism provides more information
 > than requested. PEP is requesting if this subject(s) has the
 > specified access (actions(s)) on the specified resource and
 > its child nodes. The response should be one result. Why would
 > PEP want to get detailed result information for each sub-node
 > under resource? PEP must know about the structure (if there is
 > any) of the requested resource and accordingly request for
 > authorization decision from PDP. Based on that response, PEP
 > should be able to allow or disallow the request.

Use case: the resource is a patient record.  Administrative
requesters are allowed to see the sub-elements of the resource
that contain patient name, date-of-birth, social security number,
etc., but are not allowed to see elements pertaining to
diagnosis, prognosis, or medical history.  This is the intent of
providing multiple decisions pertaining to various sub-elements
of a resource.

 > On line
 > #2968, it says only one Decision element, which is not right
 > based on lines #2907, 2908.

You are correct.  Theree may be multiple Decision elements, each
contained in a different Result element.  This should be
corrected.

 > 9. There are two different types of resources. Functionality
 > resource and data-instance resource. For example, ManagePO
 > resource can be used to create/delete/modify an instance of
 > PO. So ManagePO is a type of functionality type resource and
 > instance of PO is a data-instance type resource. If we need to
 > mandate that this action of this data-instance type resource
 > can only be permitted by this functionality-type resource, how
 > do we enforce that?

If I am understanding you correctly, this could be enforced by
having the ManagePO "resource" be expressed in the Action element
of the Request, and the "PO" be expressed in the Resource element
of the Request.  In other scenarios, it might make sense for the
ManagePO "resource" to be an attribute of the PO resource.

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>