[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml-comment] XACML 1.0 Committee Specification Comments
Dear Dipak Chopra,
The "official" XACML TC response to your comments is in the set
of comment responses I mailed out yesterday. An extract
containing your particular comments and the corresponding
responses is appended. Some are a little different from my
original response, so you might want to see if the official
responses fail to make the issues clear.
It is now too late to make changes to the XACML 1.0 Specification
unless we slip the schedule by a month. Your additional comments
will be considered for the next revision, whenever that is. And
the xacml-comment list continues to be available for asking
questions about the specification and schemas.
I will reply separately to your new questions.
Thank you for your review,
Anne Anderson, Comments Editor
--
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
=============================================================================
0073. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00047.html
Subject: XACML 1.0 Committee Specification Comments
From: "Chopra, Dipak" <dipak.chopra@sap.com>
Date: Mon, 09 Dec 2002 05:44:55 +0100
I reviewed the XACML 1.0 Committee Spec and here is the list of questions/comments.
----------------------------------------------------------------------------------
0073a. 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?
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: Needs clarification.
ACTIONS:
1) In Section 3.1, Figure 1 - Data-flow diagram, change
"1.policy" to "1.policy or policy set"
2) In Section 3.1, step 1 following Figure 1 - Data-flow
diagram, change
1. PAPs write policies and make them available to the PDP. Its
policies represent the complete policy for a specified target.
to:
1. PAPs write policies and policy sets and make them available
to the PDP. Its policies and policies sets represent the
complete policy for a specified target.
----------------------------------------------------------------------------------
0073b. 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.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: Needs to be clarified.
ACTIONS: In first requirement in Section 2.1 Requirements, change
"given action" to "particular decision request."
----------------------------------------------------------------------------------
0073c. 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.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02
RESPONSE: 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.
ACTIONS: No change.
----------------------------------------------------------------------------------
0073d. What is the significance of an Obligation with
FulfillOn="Deny"?
Which use case needs this feature?
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: A use case is where the PEP has an obligation to "Log
denied access attempt" in the case of a Deny.
ACTIONS: No change.
----------------------------------------------------------------------------------
0073e. Line #2675, scope can be "Descendants" or "Children" as
mentioned on lines #2907, 2908 in the case of multiple results.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02
RESPONSE: Needs to be corrected.
ACTIONS: Change line 2675 from
in the request context is "Descendants"
to
in the request context is "Descendants" or "Children"
----------------------------------------------------------------------------------
0073f. Section 7.6 Policy Evaluation.
The table should be Policy truth table.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: Needs to be corrected.
ACTIONS: Change title of table from "Rule truth table" to "Policy
truth table"
----------------------------------------------------------------------------------
0073g. Section 7.7 Policy Set Evaluation.
The table should be Policy Set truth table.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: Needs to be corrected.
ACTIONS: Change title of table from "Rule truth table" to "Policy
Set truth table"
----------------------------------------------------------------------------------
0073h. 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".
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: Change "effect" to "decision"
ACTIONS: Change first entry in 7.7 Policy Set evaluation truth
table from
At least one policy value is its Effect
to
At least one policy value is its Decision.
----------------------------------------------------------------------------------
0073i. 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. On line #2968, it says only one Decision
element, which is not right based on lines #2907, 2908.
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: 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.
ACTIONS: No change.
----------------------------------------------------------------------------------
0073j. 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?
CATEGORY: Unclear.
STATUS: Resolved 12/10/02.
RESPONSE: If we are understanding you correctly, this could be
enforced by expressing ManagePO as the Subject of the Request,
and the PO as the Resource of the Request.
ACTIONS: No change.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC