[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Updated Change Requests list
Ann, After some consideration I'd like to take issue 38 (xacml attr semantics) off the list. Simon ----- Original Message ----- From: "Anne Anderson" <Anne.Anderson@Sun.com> To: "XACML TC" <xacml@lists.oasis-open.org> Sent: Monday, September 09, 2002 10:38 AM Subject: [xacml] Updated Change Requests list > Title: Change Requests > Author: Anne Anderson > Version: 1.5, 02/09/09 (yy/mm/dd) > Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeReq uests.txt > > ACTION ITEMS > ============ > 0008. [Anne] resubmit with current list of mandatory functions. > 0017. [Anne] draft "open world/closed world" text. > 0019. [Polar] review and recommend action. > 0022. [Hal, Konstantin] include in Primer. > 0023. [Anne] review XPATH 2.0 function specifications. > 0026. [Michiharu] update and resubmit. > 0031. [Michiharu] consider further and resubmit. > 0032. [Michiharu] revise and resubmit. > 0033. [Tim] Add text about "complex" example to Example 2. > 0035. [Michiharu] Revise and resubmit. > 0038. [Simon] Provide use case where subject-class really *required* > > LEGEND > ====== > NQ=no quorum; official vote required > > SUMMARY > ======= > 0001. [Daniel] Add AttributeValue element to support sequence-of values > STATUS: REJECTED (NQ) 9/9 (use sequence-* functions instead) > 0002. [Anne] Add mandatory action-id attribute > STATUS: APPROVED 8/29 (QUORUM) > 0003. [Anne] Add optional action-namespace attribute > STATUS: APPROVED 8/29 (QUORUM) > 0004. [Anne] Add optional action:implied-action identifier > STATUS: APPROVED 8/29 (QUORUM) > 0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId > STATUS: APPROVED 8/29 (QUORUM) > 0006. [Anne] Add missing-attribute identifier for StatusCode > STATUS: APPROVED 8/29 (QUORUM) > 0007. [Anne] Make context Resource Attribute minoccurs=1 > STATUS: REJECTED 9/5 (NQ, BUT ANNE CONCURS) > 0008. [Anne] list mandatory vs. non-mandatory functions > STATUS: POSTPONED (Anne to resubmit with current list) > 0009. [Daniel] Function naming convention > STATUS: REJECTED 8/29 (QUORUM) > 0010. [Anne] allow more than two arguments to "add" > STATUS: APPROVED 8/29 (QUORUM) > 0011. [Carlisle] state *Match is matched against AttributeValue > STATUS: APPROVED 8/29 (QUORUM) > 0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional] > STATUS: APPROVED 8/29 (QUORUM) > 0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max > STATUS: APPROVED 9/5 (NQ) maxOccurs="unbounded", but minOccurs="0" > 0014. [Carlisle] 10. "Security and Privacy Considerations" > STATUS: APPROVED 9/5 (NQ) > 0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > 0016. [Carlisle] 10. "Policy Integrity": rule => policy > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > 0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit > STATUS: POSTPONED 9/9 (Anne to draft "open world/closed world" text) > 0018. [Carlisle] C.3 use "First Applicable" > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > 0019. [Carlisle] C. consistent error behavior > STATUS: POSTPONED 9/9 (Polar to review and recommend action) > 0020. [Michiharu] B.10: Resource Attributes scope value > STATUS: APPROVED 9/9 (NQ) Add new attribute identifier below. > 0021. [Michiharu] 8.1 Operational Model: PDP description change > STATUS: APPROVED 9/9 (NQ) > 0022. [Michiharu] 8.1 Operational Model: New sections > STATUS: REJECTED 9/9 (to be included in Primer) > 0023. [Daniel, Polar] function names, types, semantics > STATUS: POSTPONED 9/9 (Anne to review XPath 2.0 specifications) > 0024. [Anne] Make "gregorian" functions non-mandatory > STATUS: APPROVED 9/9 (NQ) > 0025. [Anne] remove NOTATION from supported types; remove assoc. functions > STATUS: APPROVED 9/9 (NQ) > 0026. [Michiharu] Add XPath functions as non-mandatory > STATUS: POSTPONED 9/9 (Michiharu will update and resubmit) > 0027. [Michiharu] Change resource-uri to resource-id > STATUS: APPROVED 9/9 (NQ) > 0028. [Michiharu] Add identifier for resource:syntax > STATUS: REJECTED 9/9 (use DataType="<syntax>" instead) > 0029. [Michiharu] Add identifier for resource:scope > STATUS: CLOSED 9/9; DUPLICATE of #20. > 0030. [Michiharu] Add identifier for resource:target-namespace > STATUS: APPROVED 9/9 (NQ) > 0031. [Michiharu] Type of XPathVersion element from string=>anyURI > STATUS: POSTPONED 9/9 (Michiharu to reconsider and resubmit) > 0032. [Michiharu] Schema change of AttributeSelector > STATUS: POSTPONED 9/9 (Michiharu to revise and resubmit) > 0033. [Michiharu] Example two to separate document > STATUS: REJECTED 9/9 (but add "this is a complex example" to intro) > 0034. [Polar] Target Match Semantics Section 4 & 5 > STATUS: APPROVED 9/9 (NQ) > 0035. [Michiharu] AttributeSelectorIndirect > STATUS: POSTPONED 9/9 (Michiharu will restate and resubmit) > 0036. [Michiharu] DataType attribute required? > STATUS: APPROVED 9/9 (NQ) (Remove DataType in Policy; keep in Context) > 0037. [Michiharu] Add normalized-string-match function > STATUS: APPROVED 9/9 (NQ) > 0038. [Simon] Extending XACML semantics with subject-class > STATUS: POSTPONED 9/9 (Simon to submit use case where *required*) > > DETAILS > ======= > 0001. [Daniel] Add AttributeValue element to support sequence-of values > http://lists.oasis-open.org/archives/xacml/200208/msg00047.html > http://lists.oasis-open.org/archives/xacml/200208/msg00140.html > > STATUS: REJECTED (NQ) 9/9 (use sequence-* functions instead) > > 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> > ------------------------------------- > >2. Adding a separate construct to XACML policy schema to represent > >sequences of attribute values, such that you cannot create sequeences of > >sequences. > > As an alternative to my proposal to modify schema element <attributevalue>, > I propose to define standard core function collection > > <type>-sequence > > of undefined arity, that takes arguments of singleton <type> kind and return > a sequence<type> value, a sequence of its argument values. > > In this case, when a literal sequence definition is needed, this funciton > can be used. No schema modification is needed. > > The drawback is that it can not be used to specify an argument of > sequence<type> kind for predicate functions that can be used in <Match> > elements. > > 0002. [Anne] Add mandatory action-id attribute > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: REJECTED 9/5 (NQ, BUT ANNE CONCURS) > > 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 > > STATUS: POSTPONED (Anne to resubmit with current list) > > 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: > > [complete list of functions in e-mail] > > 0009. [Daniel] Function naming convention > http://lists.oasis-open.org/archives/xacml/200208/msg00071.html > > STATUS: REJECTED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 8/29 (QUORUM) > > 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 > > STATUS: APPROVED 9/5 (NQ) maxOccurs="unbounded", but minOccurs="0" > > 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 > > STATUS: APPROVED 9/5 (NQ) > > 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 > > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > > 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 > > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > > 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 > > STATUS: POSTPONED 9/9 (Anne to draft "open world/closed world" text) > > 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 > > STATUS: APPROVED 9/9 (NQ) (editorial, so vote not required) > > 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 > > STATUS: POSTPONED 9/9 (Polar to review and recommend action) > > 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 > > STATUS: APPROVED 9/9 (NQ) Add new attribute identifier below. > > 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'. > > New identifier is: urn:oasis:names:tc:xacml:1.0:resource:scope > > 0021. [Michiharu] 8.1 Operational Model: PDP description change > http://lists.oasis-open.org/archives/xacml/200208/msg00112.html > > STATUS: APPROVED 9/9 (NQ) > > 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 > > STATUS: REJECTED 9/9 (to be included in Primer) > > 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/msg00181.html > > STATUS: POSTPONED 9/9 (Anne to review XPath 2.0 specifications) > > Daniel and Polar have developed a list of functions and > their semantics, attached to the above > e-mail. (XACML_functions0.8.DOC) > > CR#8 should be updated based on the final list of functions > to show which are mandatory-to-implement. > > 0024. [Anne] Make "gregorian" functions non-mandatory > http://lists.oasis-open.org/archives/xacml/200208/msg00137.html > > STATUS: APPROVED 9/9 (NQ) > > Text Changes: > Section 11.1.4(?) [Conformance] Functions > Remove "M" from left column of > urn:oasis:names:tc:xacml:1.0:function:gregorian-equal > Rationale: > We already support xs:date, so support for Gregorian is icing > on the cake. Also, I haven't found a standard for "gregorian", > so it is hard to develop tests for it. > > 0025. [Anne] remove NOTATION from supported types; remove assoc. functions > http://lists.oasis-open.org/archives/xacml/200208/msg00138.html > > STATUS: APPROVED 9/9 (NQ) > > Text Changes: > Section 11. Conformance, DataTypes, remove: > line listing "xs:NOTATION" > > Appendix A.1. Functions, remove: > function:NOTATION-equal > function:NOTATION-not-equal > > Rationale: > XML Schema says > "It is an error for NOTATION to be used directly > in a schema. Only datatypes that are derived from NOTATION by > specifying a value for enumeration can be used in a schema. > > For compatibility NOTATION should be used only on attributes." > > Also, QName-equal and QName-not-equal can be used to compare > such data types if necessary. > > I'm on thin ground here, since I don't know enough about XML > Schema to be sure I am interpreting the impact of this > correctly. > > 0026. [Michiharu] Add XPath functions as non-mandatory > http://lists.oasis-open.org/archives/xacml/200208/msg00142.html > > STATUS: POSTPONED 9/9 (Michiharu will update and resubmit) > > [See referenced e-mail for function definitions] > > I propose to include the following functions (all relevant to XPath) in the > spec as non-mandatory to implement functions. The original proposal (a > little different from this proposal) was posted on 29th July and it > described more in detail. > http://lists.oasis-open.org/archives/xacml/200207/msg00162.html > > function:general-string-equal xs:boolean object(*1) object A > = B > function:node-boolean xs:boolean object > function:node-match xs:boolean object object > > ======================== > (*1) "object" type is defined in Introduction section of [2] as: > > "... object, which has one of the following four basic types: > node-set (an unordered collection of nodes without duplicates) > boolean (true or false) > number (a floating-point number) > string (a sequence of UCS characters)" > > [1] XQuery 1.0 and XPath 2.0 Data Model, > http://www.w3.org/TR/xquery-operators/ > [2] XPath 1.0, http://www.w3.org/TR/xpath > > 0027. [Michiharu] Change resource-uri to resource-id > http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (A1) > > STATUS: APPROVED 9/9 (NQ) > > urn:oasis:names:tc:xacml:1.0:resource:resource-uri > ==> > urn:oasis:names:tc:xacml:1.0:resource:resource-id > > 0028. [Michiharu] Add identifier for resource:syntax > http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B1) > > STATUS: REJECTED 9/9 (use DataType="<syntax>" instead) > > urn:oasis:names:tc:xacml:1.0:resource:syntax > > This identifier indicates the syntax of the resource-id > (urn:oasis:names:tc:xacml:1.0:resource:resource-id). The valid values are > either 'String', 'URI' or 'XPointer'. If this attribute is omitted, > 'String' syntax is assumed. 'URI' indicates that the syntax of the > resource-id is URI format. 'XPointer' indicates that the syntax of the > resource-id is XPointer format proposed in > http://www.w3.org/TR/2001/CR-xptr-20010911/. > > 0029. [Michiharu] Add identifier for resource:scope > http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B2) > > STATUS: CLOSED 9/9; DUPLICATE of #20. > > urn:oasis:names:tc:xacml:1.0:resource:scope > > This identifier indicates the scope of the resource. The valid values are > either 'Immediate', 'Children', or 'Descendant'. When 'Immediate', it > indicates that the scope of the resource is a target value specified by > urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute. When > 'Children', it indicates that the scope of the resource is a target value > specified by urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute > and its children resource. When 'Descendant', it indicates that the scope > of the resource is a target value specified by > urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute and all the > descendant resources. > > 0030. [Michiharu] Add identifier for resource:target-namespace > http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B3) > > STATUS: APPROVED 9/9 (NQ) > > urn:oasis:names:tc:xacml:1.0:resource:target-namespace > > This identifier indicates the target-namespace of the requested XML > document, that is a namespace URI associated with the root element of the > XML document. > > 0031. [Michiharu] Type of XPathVersion element from string=>anyURI > http://lists.oasis-open.org/archives/xacml/200208/msg00144.html > > STATUS: POSTPONED 9/9 (Michiharu to reconsider and resubmit) > > Schema change request > <xs:element name="XPathVersion" type="xs:string" substitutionGroup > ="xacml:AbstractDefaults"/> > ==> > <xs:element name="XPathVersion" type="xs:anyURI" substitutionGroup > ="xacml:AbstractDefaults"/> > > [Simon] this would require type of AbstractDefaults to be > changed to anyURI. Possibly OK, but need to evaluate impact. > > 0032. [Michiharu] Schema change of AttributeSelector > http://lists.oasis-open.org/archives/xacml/200208/msg00145.html > http://lists.oasis-open.org/archives/xacml/200208/msg00146.html (example) > http://lists.oasis-open.org/archives/xacml/200208/msg00149.html (correction) > http://lists.oasis-open.org/archives/xacml/200208/msg00150.html (Simon) > > STATUS: POSTPONED 9/9 (Michiharu to revise and resubmit) > > I propose to change the AttributeSelector element. The reason of this > change is described in a separate mail titled "[xacml] AttributeSelector > example". > > <xs:complexType name="AttributeSelectorType"> > <xs:attribute name="RequestContextPath" type="xs:anyURI" use="required"/> > <xs:attribute name="DataType" type="xs:anyURI" use="required"/> > <xs:attribute name="XPathVersion" type="xs:anyURI" use="optional" default > ="http://www.w3.org/TR/1999/Rec-xpath-19991116"/> > </xs:complexType> > > ==> > > <xs:complexType name="AttributeSelectorType"> > <xs:element ref="xacml:XPathNamespace" minOccurs="0" maxOccurs > ="unbounded"/> > <xs:choice> > <xs:attribute name="RequestContextPath" type="xs:anyURI" use > ="optional"/> > <xs:attribute name="RequestContextId" type="xs:string" use="optional"/> > </xs:choice> > <xs:attribute name="DataType" type="xs:anyURI" use="optional"/> > <xs:attribute name="XPathVersion" type="xs:anyURI" use="optional" default > ="http://www.w3.org/TR/1999/Rec-xpath-19991116"/> > </xs:complexType> > > <xs:element name="XPathNamespace" type="xacml:XPathNamespaceType" > substitutionGroup="xacml:AbstractDefaults"/> > <xs:complexType name="XPathNamespaceType"> > <xs:attribute name="NamespaceURI" type="xs:anyURI"/> > <xs:attribute name="Prefix" type="xs:string" use="optional"/> > </xs:complexType> > > Scope of the XPathNamespace for AttributeSelector element: > 1. AttributeSelector element that includes XPathNamespace element, > XPathNamespace elements in PolicyDefaults or PolicySetDefaults elements > that include the AttributeSelector element. > > For the precedence, > 1. XPathNamespace elements in AttributeSelector take precedence over > XPathNamespace elements in PolicyDefaults in Policy element.. > 2. XPathNamespace elements in PolicyDefaults in Policy take precedence over > XPathNamespace elements in PolicySetDefaults in PolicySet element.. > 3. If there are two or more identical prefixes are specified under an > AttributeSelector, a PolicyDefaults or a PolicySetDefaults elements, the > last prefix takes precedence over the previous prefixes. > > Others: > 1. Global xmlns attribute is not used for resolving namespace-prefix pair > specified in XPath expression. > 2. If no XPathNamespace element is found in valid scope, it means no > namespace-prefix pair is defined. > 3. If Prefix attribute is missing, it means that default namespace is > defined. > > Text change request > In Section 5.3, Element <PolicySetDefaults>, line 1487-1489, > > <AbstractDefaults>[Any Number] > > This is the head of substitution group to specify default parameters. The > elements in this substitution group defined at this time are <XPathVersion> > element and <XPathNamespace> element. > > 0033. [Michiharu] Example two to separate document > http://lists.oasis-open.org/archives/xacml/200208/msg00147.html > > STATUS: REJECTED 9/9 (but add "this is a complex example" to intro) > > After looking at line 589-1102, I think that Section 3.2 > policy specification in Example two is too complicated for > average readers. While my preference is to hold this example > in the spec, most readers would feel that XACML is difficult > to read and understand when they try to go through this > example. Besides, this example requires expertise about XPath > syntax and its data model that is basically different from > this specification. Honestly speaking, it is a little > difficult even for me... :-). So my suggestion is to move > this section to a separate document (say Primer document or > Use Case document). > > [We decided to keep the example, but revise the introduction > slightly to make it clear that this is a very complex example > intended to illustrate various features of the XACML > language. The functions also need to be updated. Polar will > do that.] > > 0034. [Polar] Target Match Semantics Section 4 & 5 > http://lists.oasis-open.org/archives/xacml/200208/msg00188.html > [long set of specific text changes included in e-mail] > http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction) > > STATUS: APPROVED 9/9 (NQ) > > The semantics for the Target need to be updated. It doesn't seem to > describe how "Match" or "No-Match" are derived at. The document mentions > logical-AND and logical-OR, and they are not defined for Match and > No-Match. Also, we need to resolve the discovery and issue of the > inconsistency between the evaluation of Target and Condition with respect > to Indeterminate and NotApplicable, now that we are making progress on the > "functions" document. > > I feel that if we refer to the Target evaluations with the same semantics > as Condition, we can leverage the use of True, False, and Indeterminate > that we have already defined, and then we can use the notions of > conjunctive sequence and disjunctive sequence as combinators of our > boolean values (true, false, indeterminate) with the normative > specifications of our functions "function:and" and "function:or" for the > combining rules. This will take care of the normative handling of error > conditions in the evaluation logic. > > When the XACML Data Types, Functions, and Semantics gets put in the > document, I suggest making the following changes. Some changes are > editorial. > > Note: There is some issue about <Target> and <Condition> of where they say > that they possible to be "empty", but I'm not sure if that means "omitted" > (i.e. minOccurs="0"), or <Target/>, or <Condition/>. > > 0035. [Michiharu] AttributeSelectorIndirect > http://lists.oasis-open.org/archives/xacml/200208/msg00190.html > http://lists.oasis-open.org/archives/xacml/200208/msg00201.html (followup) > http://lists.oasis-open.org/archives/xacml/200209/msg00016.html (more) > http://lists.oasis-open.org/archives/xacml/200209/msg00024.html (Polar) > http://lists.oasis-open.org/archives/xacml/200209/msg00030.html (Michiharu) > http://lists.oasis-open.org/archives/xacml/200209/msg00031.html (Polar) > http://lists.oasis-open.org/archives/xacml/200209/msg00035.html (Daniel) > http://lists.oasis-open.org/archives/xacml/200209/msg00036.html (Daniel) > http://lists.oasis-open.org/archives/xacml/200209/msg00040.html (Polar) > http://lists.oasis-open.org/archives/xacml/200209/msg00042.html (Daniel) > > STATUS: POSTPONED 9/9 (Michiharu will restate and resubmit) > > Based on the discussion on Monday call, Simon and I agreed to changing the > schema to support an AttributeSelectorIndirect element to retrieve a XPath > expression from the context. > > 0036. [Michiharu] DataType attribute required? > http://lists.oasis-open.org/archives/xacml/200208/msg00192.html > > STATUS: APPROVED 9/9 (NQ) (Remove DataType in Policy; keep in Context) > > DataType attribute in AttributeDesignatorType is 'required'. But in most > cases, AttributeDesignator is used below the matching function (e.g. > string-match) and that function is type-specific. So I think "DataType" > attribute is not required. I propose to change it to "optional". > > <xs:complexType name="AttributeDesignatorType"> > <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> > <xs:attribute name="DataType" type="xs:anyURI" use="required"/> > <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> > </xs:complexType> > > [should be] > <xs:complexType name="AttributeDesignatorType"> > <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> > <xs:attribute name="DataType" type="xs:anyURI" use="optional"/> > <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> > </xs:complexType> > > 0037. [Michiharu] Add normalized-string-match function > http://lists.oasis-open.org/archives/xacml/200209/msg00056.html > > STATUS: APPROVED 9/9 (NQ) > > - Handling whitespace > > XPath 1.0 (and 2.0) has a function called normalize-space() that strips > leading and trailing whitespace and replacing sequences of whitespace > characters by a single space. Some people suggests to use this function > whenever string equality is checked on a XML document. That hides subtle > issues like how to handle whitespace in XML. However, some applications may > need non-normlized string comparison. > > So my suggestion is to support two kinds of string-equal functions: > string-equal and normalized-string-equal. The string-equal does not > normalize the string and the normalized-string-equal works as if it invokes > normalize-space() function internally before comparison is made. The > normalized-string-equal function is necessary if a user need to specify > this function in MatchId attribute. When string-equal is used, any > whitespace handling specifier "xml:space" attribute on XACML Request > Context will be ignored except for the element inside the ResourceContent > element. > > - Semantics of the string comparison > > XPath 2.0 defines xf:compare function instead of defining xf:string-equal > function. The xf:compare has an optional argument called "collation" that > specifies Unicode collation algorithm. The draft says, if it is omitted, > the default collation is used (but its rule is TBD). Then, if we assume > that there is a default collation for XACML, the function:string-equal is > defined as "it returns true depending on the value of the first string is > equal to the value of the second string according to the rules of the > collation that is used. Otherwise, false is returned". We may add "if > either argument is the empty sequence, it returns false". Default collation > in XACML would be "comparison on each character of the string using > integer-equal". > > 0038. [Simon] Extending XACML semantics with subject-class > http://lists.oasis-open.org/archives/xacml/200209/msg00052.html > > STATUS: POSTPONED 9/9 (Simon to submit use case where *required*) > > Currently there is no semantics associated with the 'subject' > and 'resource' definition in the 'target' of a rule. The > only thing we do is match attribute designator with attribute > value. > > Although there was a decision made not to have such > semantics, I find it limiting. > > I propose to allow new elements in the rule target that > convey semantics of an attribute. > > It is accomplished by wrapping subject-match with > <subject-class> element, like this: > > <rule> > <target> > <subjects> > <subject> > <subject-class > class-id="urn:oasis:names:tc:xacml:1.0:subject:class:group"> <-- this line is new > <subject-match match-id="function:string-equal"> > <subject-attribute-designator attribute-id="security-role" > category="urn:oasis:names:tc:xacml:subject:access-subject"/> > <attribute-value>admin</attribute-value> > </subject-match> > </subject-class> > </subject> > </subjects> > .... etc ... > </target> > </rule> > > This syntax allows us to reason about a subject of a > rule. (Same applies to resource). It states not only how to > match subject attribute, but also what this attribute is, > namely a group. > > I hope this proposal did not come too late, but if it did, we > can consider it for xacml 1.x > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC