[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Initial set of Change Requests
These are the change requests I culled from recent mailings. Please review to be sure I have captured all your change requests accurately. To make future tracking of changes easier, I propose the following procedure: a. All future mailings that request a change MUST have [CR] in the subject line. The remainder of the subject should include enough keywords about the change to identify it. For example, Change Request 0001 below would have been submitted with a subject line of: [CR] Add AttributeValue element to support sequence-of values b. Separate change requests MUST be submitted in separate mailings. c. Responses to change requests MUST keep the same subject line (module Re: [xacml]) so that discussion can be tracked. d. Change requests MUST begin with the exact text proposed. This allows a specific change to be voted on. e. Change requests SHOULD continue with a Rationale explaining why the change is needed. f. Try to be succinct. Anne Title: Change Requests Version: 1.1, 02/08/22 (yy/mm/dd) 0001. [Daniel] Add AttributeValue element to support sequence-of values http://lists.oasis-open.org/archives/xacml/200208/msg00047.html Currently <attributeValue> element is an extension of anyType, with specified DataType. XACML functions arguments are, in general, a sequence of typed elements - as it can be returned by a designator from context. While most accept only single values (sequence of size 1), some set operation functions have an arbitrary length sequence as an argument. We need to provide syntax to express a sequence of values as a literal argument in set operations (like union, member_of, intersection..) I propose adding element Value, of anyType, and defining <AttributeValueType> as sequence of <Value>, with DataType attribute, applicable to all elements in the sequence. It supports 0 size of the sequence, to support empty set in operations <xs:element name="Value" type="xs:anyType"/> <xs:element name="AttributeValue"/> <xs:complexType name="AttributeValueType"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element ref="Value"/> </xs:sequence> <xs:attribute name="name" type="xs:anyURI" use="required"/> </xs:complexType> 0002. [Anne] Add mandatory action-id attribute Create a reserved attribute identifier "urn:oasis:names:tc:xacml:1.0:action:action-id". Make inclusion of an <Attribute> with AttributeId of this identifier mandatory under the <Action> element of the <Request> context. Change minOccurs for <Attribute> under <Action> 1. Rationale: We had previously decided that <Action> would have a single string value that would be the action id. Now we need a specific AttributeId for this. This is consistent with the way resource-id is handled. It provides a consistent, interoperable way of specifying the action. The <DataType> of the <Attribute> can specify whether the action value is a string or URI. 0003. [Anne] Add optional action-namespace attribute Create a reserved attribute identifier "urn:oasis:names:tc:xacml:1.0:action:action-namespace". Make inclusion of an <Attribute> with AttributeId of this identifier optional under the <Action> element of the <Request> context. Rationale: We previously decided that an <Action> value might be associated with a specific namespace, and that an XML attribute was needed to express this. 0004. [Anne] Add optional action:implied-action identifier Create a reserved identifier "urn:oasis:names:tc:xacml:1.0:action:implied-action" to represent the value of an action that is implied by the <Resource> Rationale: We have agreed to this concept, but have not reserved an identifier for it. 0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId Rationale: Since the Request <Resource> identifier is now called resource-id, and can be of any data type, the <Result> should be consistent. 0006. [Anne] Add missing-attribute identifier for StatusCode Rationale: We have values for ok, processing-error, and syntax-error. Although we discussed the use case for missing attributes extensively, we have not defined a standard identifier for this status. 0007. [Anne] Make context Resource Attribute minoccurs=1 Current value is minOccurs=0 maxOccurs=unbounded. Change this to minOccurs=1 maxOccurs=unbounded. Rationale: Since Resource MUST contain a resource-id attribute, minimum value should be 1. 0008. [Anne] list mandatory vs. non-mandatory functions http://lists.oasis-open.org/archives/xacml/200208/msg00069.html Add a list of all functions, with an indicator as to whether the function is mandatory to implement, to the Conformance Section. This list should be updated based on the final resolution of CR#23. Rationale: I forgot to include these when I created the original list. Text to be inserted: M indicates mandatory-to-implement. Function identifier =========================== M function:integer-add M function:decimal-add function:add-yearMonthDuration-to-date function:add-yearMonthDuration-to-date function:add-dayTimeDuration-to-time function:add-yearMonthDuration-to dateTime function:add-dayTimeDuration-to-dateTime function:add-yearMonthDurations function:add-dayTimeDurations M function:integer-subtract M function:decimal-subtract function:date-subtract function:subtract-yearMonthDuration-from-date function:subtract-dayTimeDuration-from-date function:time-subtract function:subtract-dayTimeDuration-from-time function:datetime-subtract function:subtract-yearMonthDuration-from-dateTime function:subtract-dayTimeDuration-from-dateTime function:subtract-yearMonthDurations function:subtract-dayTimeDurations M function:integer-multiply M function:decimal-multiply function:multiply-yearMonthDurations function:multiply-dayTimeDurations M function:integer-divide M function:decimal-divide function:divide-yearMonthDurations function:divide-dayTimeDurations M function:integer-mod M function:decimal-mod M function:round M function:floor M function:abs M function:integer M function:decimal M function:integer-equal M function:decimal-equal M function:boolean-equal M function:string-equal M function:rfc822Name-equal M function:x500Name-equal M function:date-equal M function:time-equal M function:datetime-equal function:yearMonthDuration-equal function:dayTimeDuration-equal M function:gregorian-equal M function:hex-binary-equal M function:base64-binary-equal M function:anyURI-equal M function:QName-equal M function:NOTATION-equal function:numeric-not-equal function:boolean-not-equal function:string-not-equal function:date-not-equal function:time-not-equal function:datetime-not-equal function:yearMonthDuration-not-equal function:dayTimeDuration-not-equal function:gregorian-not-equal function:hex-binary-not-equal function:base64-binary-not-equal function:anyURI-not-equal function:QName-not-equal function:NOTATION-not-equal M function:integer-greater-than M function:decimal-greater-than M function:string-greater-than M function:date-greater-than M function:time-greater-than M function:datetime-greater-than function:yearMonthDuration-greater-than function:dayTimeDuration-greater-than function:integer-less-than function:decimal-less-than function:string-less-than function:date-less-than function:time-less-than function:datetime-less-than function:yearMonthDuration-less-than function:dayTimeDuration-less-than M function:integer-greater-than-or-equal M function:decimal-greater-than-or-equal M function:string-greater-than-or-equal M function:date-greater-than-or-equal M function:time-greater-than-or-equal M function:datetime-greater-than-or-equal function:yearMonthDuration-greater-than-or-equal function:dayTimeDuration-greater-than-or-equal function:integer-less-than-or-equal function:decimal-less-than-or-equal function:numeric-less-than-or-equal function:date-less-than-or-equal function:time-less-than-or-equal function:datetime-less-than-or-equal function:yearMonthDuration-less-than-or-equal function:dayTimeDuration-less-than-or-equal M function:string-match M function:rfc822Name-match M function:x500Name-match M function:and M function:ordered-and M function:or M function:ordered-or M function:n-of M function:not M function:present [where X can be any supported data type] M X-intersection M X-union M X-member-of M X-first M X-rest M X-length 0009. [Daniel] Function naming convention http://lists.oasis-open.org/archives/xacml/200208/msg00071.html Change function names to blah_blah Rationale: Dashes are not always supported. 0010. [Anne] allow more than two arguments to "add" http://lists.oasis-open.org/archives/xacml/200208/msg00090.html Allow function:integer-add and function:decimal-add to take more than two arguments. Rationale: This saves having to write nested statements for these simple operations. 0011. [Carlisle] state *Match is matched against AttributeValue http://lists.oasis-open.org/archives/xacml/200208/msg00094.html In section 5.7 (Element <SubjectMatch>), I think we need to specify that whatever is returned by SubjectAttributeDesignator or AttributeSelector is matched against the value carried in AttributeValue. The same is true for <ResourceMatch> and <ActionMatch> (sections 5.10 and 5.13). Rationale: This behaviour is not spelled out anywhere. (In fact, AttributeValue is not even described in the "list of elements contained in <SubjectMatch>" discussion; it only appears in the schema fragment.) 0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional] http://lists.oasis-open.org/archives/xacml/200208/msg00094.html Make <AttributeSelector> in <SubjectMatch> [optional] rather than [required]. Rationale: Also, in the "list of elements contained in <SubjectMatch>" discussion, why is <AttributeSelector> described as [required]? I thought it was optional. 0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max http://lists.oasis-open.org/archives/xacml/200208/msg00094.html Make minOccurs="1" and maxOccurs="unbounded" for <SubjectMatch> in <SubjectAttributeDesignatorWhere>. Rationale: In section 5.26 (Element <SubjectAttributeDesignatorWhere>), why does the element <SubjectMatch> have minOccurs="0"? If this element was omitted, you wouldn't use SubjectAttributeDesignatorWhere; you would just use SubjectAttributeDesignator. In any case, the verbal description says that SubjectMatch has [Any Number], so I suspect that minOccurs="0" in the schema should be changed to maxOccurs="unbounded". 0014. [Carlisle] 10. "Security and Privacy Considerations" http://lists.oasis-open.org/archives/xacml/200208/msg00096.html Change title of Section 10 to "Security and Privacy Considerations". Rationale: Should this be called "Security and Privacy Considerations" instead of just "Security and Privacy"? 0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies http://lists.oasis-open.org/archives/xacml/200208/msg00096.html In the 10. "Statement Level Confidentiality" section, 1st paragraph, say "... a PRP only needs access to the target elements in order to find the appropriate policies". Rationale: Currently says: "... a PRP only needs access to the target elements in order to find the appropriate rules". Should this say "rules/policies", or just "policies", instead of "rules"? 0016. [Carlisle] 10. "Policy Integrity": rule/policy http://lists.oasis-open.org/archives/xacml/200208/msg00096.html In the 10. "Policy Integrity" section, 4th paragraph, say "The PDP SHOULD NOT request a policy based on who signed the policy...". Rationale: In the "Policy Integrity" section, 4th paragraph, it currently says "The PDP SHOULD NOT request a rule based on who signed the rule...". Should both occurrences of "rule" be "policy"? 0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit http://lists.oasis-open.org/archives/xacml/200208/msg00096.html In 10. "Resource Matching" section, say, 'although the policy result of "Not Applicable" is treated as equivalent to "Permit" by many web servers, this behavior is not recommended.' Rationale: In the "Resource Matching" section, 1st paragraph, it says "... the policy result of "Not Applicable" is treated as equivalent to "Permit" as is common in many web servers". I'm a bit surprised that this is true (although I probably shouldn't be!). In any case, we probably don't want to encourage this behaviour. Should we simply not mention this, or should we at least say that this behaviour is not recommended? Hal's rejoinder: First of all, this is intended as a cautionary example. However, this is a real world problem that affects my product, and all of our compeitors. I can show you security holes posted to BUGTRAQ, for example, where this occurred. We have struggled with it for years. The Not Applicable == Permit behavior is not only standard for web servers, it is embedded in the Java Servlet and JSP specifications. The logic is that only a small portion of the resources on a public web server are protected, so people want to only specify rules for those that are. If the namespace is not conveniencely laid out (as most are not) it may require a number of rules just to specify all the pages that are not protected. 0018. [Carlisle] C.3 use "First Applicable" http://lists.oasis-open.org/archives/xacml/200208/msg00099.html Call Section C.3, "First Applicable" rather than "First Applicable Rule Combining Algorithm". In first sentence of C.3, change "First Determinate" rule-combining algorithm to "First Applicable". Rationale: Section C.3, should this be called "First Applicable" rather than "First Applicable Rule Combining Algorithm"? This would be more consistent with both C.1 and C.2, and would also be more consistent with the fact that C.3 contains both a rule combining algorithm and a policy combining algorithm. The first sentence of C.3 calls it the "First Determinate" rule-combining algorithm; this should be changed to "First Applicable". 0019. [Carlisle] C. consistent error behavior http://lists.oasis-open.org/archives/xacml/200208/msg00099.html Policy combiner should halt and return Indeterminate when an error is encountered. Rationale: The behaviour specified in the policy-combining algorithm when an error is encountered is different from the behaviour specified in the rule-combining algorithm when an error is encountered (the rule combiner says halt and return Indeterminate, whereas the policy combiner says to keep looking for an applicable policy). Is this what we wanted? More importantly, might the policy combiner behaviour not lead to different answers for the same inputs? For example, say there are two policies that are to be combined using this algorithm. Given a particular set of input values, the first policy would return a decision of "Permit" and the second policy would return a decision of "Deny". Now we give all the inputs to two different PDPs. The first PDP retrieves the first policy, gets an answer of "Permit", and returns this to the PEP. The second PDP has trouble retrieving the first policy for whatever reason and, according to the combining algorithm, retrieves the second policy; it then returns a "Deny" to the PEP. Isn't this the sort of result we want to avoid? Wouldn't the behaviour specified in the rule combining algorithm be preferable (that way, the first PDP would return "Permit" and the second would return "Indeterminate", which seems fine to me)? 0020. [Michiharu] B.10: Resource Attributes scope value http://lists.oasis-open.org/archives/xacml/200208/msg00112.html In B.10, the identifier indicates the scope of the request with regard to the resource. When this attribute is specified in the request, the value MUST be either 'Immediate', 'Children', or 'Descendant'. 0021. [Michiharu] 8.1 Operational Model: PDP description change http://lists.oasis-open.org/archives/xacml/200208/msg00112.html 8.1 Policy Decision Point (PDP) Given a valid XACML "Policy" or a "PolicySet", a compliant XACML PDP MUST evaluate that statement in accordance to the semantics specified in Section 4,5, and 6 when applied to a specific input context. The PDP MUST return an output context, with one value of "Permit", "Deny", "Indeterminate", or "NotApplicable". If a permit is returned, the PEP permit access to the requested resource. If a denial is returned, the PEP denies access to the requested resource. If a permit with one or more obligations is returned, the PEP permits access provided that every obligations are fulfilled successfully. If a denial with one or more obligations is returned, the PEP denies access but still fulfills the obligations. In each case, when fulfilling obligations failed, the PEP SHOULD raise an error. How the error is raised is out of the scope of XACML. In any case, the PDP can return additional information in the status code element in the response context. For 'Permit' decision, it MAY specify which rules are used in decision making. If an indeterminate is returned, it means that the PDP could not make decision due to some reason. The PDP MAY return decision of "indeterminate" with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute", signifying that more information is needed. In this case, the decision MAY list the names of any attributes of the subject and the resource that are needed by the PDP to refine its decision. A PEP MAY resubmit a refined request context in response to a decision of "indeterminate" with a status code of "missing-attribute" by adding attribute values for the attribute names that are listed in the response. When the PDP returns an decision of "indeterminate", with a status code of "missing-attribute", a PDP MUST NOT list the names of any attribute of the subject or the resource of the request for which values were already supplied in the request. Note, this requirement forces the PDP to eventually return a decision of "permit", "deny", or "indeterminate" with some other reason, in response to successively-refined requests. If not applicable is returned, it means that the PDP's policy does not cover the request, implying that the PEP should ask another PDP. XACML does not assume how top-level XACML policies should be configured. For example, a top-level policy might be a 'Policy' element containing a target element that matches every request, or it might be a 'Policy' element containing a target element that matches only a specific subject. 0022. [Michiharu] 8.1 Operational Model: New sections http://lists.oasis-open.org/archives/xacml/200208/msg00112.html 8.2 Hierarchical Resource It is often the case that a target resource is organized as a hierarchy (e.g. file system, XML document). Some applications may require access to an entire subtree of the resource. XACML allows the PEP (or Context Handler) to specify whether the access is just for a single resource or for a subtree below the specified resource. The latter is equivalent to repeating a single request for the entire subtree. When a request context contains a resource attribute of 'urn:oasis:names:tc:xacml:1.0:resource:scope' with a value of 'Immediate', or does not contain that attribute in the context, then it means that the access is just for a single resource specified by 'ResourceId' attribute. When 'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a value of 'Children', it means that the access is for both a specified resource and its children resources. When 'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a value of 'Descendant', it means that the access is for both a specified resource and all the descendant resources. In the case of 'Children' and 'Descendant', the access decision may include multiple results for the multiple resources. XACML response can contain multiple result elements. In such case, the status element SHOULD be included only in the first result element (the remaining result elements SHOULD NOT include the status element). Note that the method how PDP finds out whether the resource is hierarchically organized or not is out of the scope of the XACML. 8.3 Propagation through Data Hierarchy When the resource is hierarchically organized, it is often the case that an access control rule associated to a certain node propagates down to the descendant nodes. The XACML core rule combining algorithm does not support such propagation with regard to access control rules. Policy writers who need propagation MUST implement their own local algorithm and specify that algorithm ID in RuleCombiningAlgId in policy element. 0023. [Daniel, Polar] function names, types, semantics http://lists.oasis-open.org/archives/xacml/200208/msg00116.html This change request is a place-holder. I propose that Daniel and Polar come up with a list of functions, semantics, and types table that they BOTH agree on. This will be the Change Request inserted here to be voted on. CR#8 should be updated based on the final list of functions to show which are mandatory-to-implement.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC