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] | [Elist Home]

Subject: [xacml] 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

 > 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

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

Powered by eList eXpress LLC