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