[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Change Request list
A list reflecting the decisions we made at the 9/26/02 TC conference call is attached. -- 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
Title: Change Requests Author: Anne Anderson Version: 1.9, 02/09/26 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests.txt This version reflects all decisions made on Change Requests. All Change Requests in this list have been resolved by quorum votes. ACTION ITEMS ============ None LEGEND ====== NQ=no quorum; official vote required Q=quorum SUMMARY ======= 0001. [Daniel] Add AttributeValue element to support sequence-of values STATUS: REJECTED (NQ 9/9;Q 9/12) Use sequence-* functions instead. 0002. [Anne] Add mandatory action-id attribute STATUS: APPROVED (Q 8/29) 0003. [Anne] Add optional action-namespace attribute STATUS: APPROVED (Q 8/29) 0004. [Anne] Add optional action:implied-action identifier STATUS: APPROVED (Q 8/29) 0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId STATUS: APPROVED (Q 8/29) 0006. [Anne] Add missing-attribute identifier for StatusCode STATUS: APPROVED (Q 8/29) 0007. [Anne] Make context Resource Attribute minoccurs=1 STATUS: REJECTED (NQ 9/5;Q 9/12) 0008. [Anne] list mandatory vs. non-mandatory functions STATUS: APPROVED (Q 9/26) New list in v17.doc; all except XPath mandatory. 0009. [Daniel] Function naming convention STATUS: REJECTED (Q 8/29) 0010. [Anne] allow more than two arguments to "add" STATUS: APPROVED (Q 8/29) 0011. [Carlisle] state *Match is matched against AttributeValue STATUS: APPROVED (Q 8/29) 0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional] STATUS: APPROVED (Q 8/29) 0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max STATUS: APPROVED (NQ 9/5;Q 9/12) maxOccurs="unbounded", but minOccurs="0" 0014. [Carlisle] 10. "Security and Privacy Considerations" STATUS: APPROVED (NQ 9/5;Q 9/12) 0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required. 0016. [Carlisle] 10. "Policy Integrity": rule => policy STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required. 0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit STATUS: APPROVED (Q 9/26) Use Anne's draft below, with some edits. 0018. [Carlisle] C.3 use "First Applicable" STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required. 0019. [Carlisle] C. consistent error behavior STATUS: APPROVED (Q 9/26) Use Polar's text below. 0020. [Michiharu] B.10: Resource Attributes scope value STATUS: APPROVED (NQ 9/9;Q 9/12) Add new attribute identifier below. 0021. [Michiharu] 8.1 Operational Model: PDP description change STATUS: APPROVED (NQ 9/9;Q 9/12) 0022. [Michiharu] 8.1 Operational Model: New sections STATUS: REJECTED (NQ 9/9;Q 9/12) But to be included in Primer. 0023. [Daniel, Polar] function names, types, semantics STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=. 0024. [Anne] Make "gregorian" functions non-mandatory STATUS: APPROVED (NQ 9/9;Q 9/12) 0025. [Anne] remove NOTATION from supported types; remove assoc. functions STATUS: APPROVED (NQ 9/9 Q 9/12) 0026. [Michiharu] Add XPath functions as non-mandatory STATUS: WITHDRAWN (9/19) Replaced by #47. 0027. [Michiharu] Change resource-uri to resource-id STATUS: APPROVED (NQ 9/9;Q 9/12) 0028. [Michiharu] Add identifier for resource:syntax STATUS: REJECTED (NQ 9/9;Q 9/12) Use DataType="<syntax>" instead. 0029. [Michiharu] Add identifier for resource:scope STATUS: CLOSED (NQ 9/9;Q 9/12) Duplicate of #20. 0030. [Michiharu] Add identifier for resource:target-namespace STATUS: APPROVED (NQ 9/9;Q 9/12) 0031. [Michiharu] Type of XPathVersion element from string=>anyURI STATUS: WITHDRAWN (9/12) 0032. [Michiharu] Schema change of AttributeSelector STATUS: ACCEPTED (Q 9/12) 0033. [Michiharu] Example two to separate document STATUS: REJECTED (NQ 9/9;Q 9/12) But add "this is a complex example" to intro. 0034. [Polar] Target Match Semantics Section 4 & 5 STATUS: APPROVED (NQ 9/9;Q 9/12) 0035. [Michiharu] AttributeSelectorIndirect STATUS: WITHDRAWN (9/19) Replaced by #47. 0036. [Michiharu] DataType attribute required? STATUS: APPROVED (NQ 9/9;Q 9/12) Remove DataType in Policy; keep in Context. 0037. [Michiharu] Add normalized-string-match function STATUS: APPROVED (NQ 9/9;Q 9/12) 0038. [Simon] Extending XACML semantics with subject-class STATUS: WITHDRAWN (9/9) 0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector STATUS: ACCEPTED (Q 9/12) 0040. [Michiharu,Simon] Semantics of sequences STATUS: WITHDRAWN. REPLACED BY #42-#46. 0041. [Polar] Target Match Truth Table STATUS: APPROVED (Q 9/19) 0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function STATUS: APPROVED (NQ 9/16;Q 9/26) 0043. [Michiharu] XACML supports unordered set that is called a "bag" STATUS: APPROVED (NQ 9/16;Q 9/26) 0044. [Michiharu] XACML distinguishes singleton data from bag type STATUS: APPROVED (NQ 9/16;Q 9/26) 0045. [Michiharu] XACML supports higher-order bag functions STATUS: APPROVED (NQ 9/16;Q 9/26) 0046. [Michiharu] XACML supports operators for computing on bag types. STATUS: APPROVED (NQ 9/16;Q 9/26) 0047. [Michiharu] Function specification for XPath handler STATUS: APPROVED (Q 9/26) Functions specified in XACML_functions v13 0048. [Simon] subject-category value must be unique in given context STATUS: APPROVED (Q 9/26). 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;Q 9/12) 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 (Q 8/29) 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 (Q 8/29) 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 (Q 8/29) 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 (Q 8/29) 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 (Q 8/29) 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 (NQ 9/5;Q 9/12) 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: APPROVED (Q 9/26) New list in v17.doc; all except XPath mandatory. All functions in XACML_functions.doc v13 are mandatory, with the exception of the three XPath functions at the end. 0009. [Daniel] Function naming convention http://lists.oasis-open.org/archives/xacml/200208/msg00071.html STATUS: REJECTED (Q 8/29) 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 (Q 8/29) 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 (Q 8/29) 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 (Q 8/29) 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 (NQ 9/5;Q 9/12) 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 (NQ 9/5;Q 9/12) 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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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: APPROVED (Q 9/26) Use Anne's draft below, with some edits. 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. [Anne draft of "Open World/Closed World" considerations] Draft change to "Security and Privacy Considerations" "Resource Matching" section: 1. Change title to "NotApplicable Results" A result of "NotApplicable" means that the PDP did not have a Policy whose Target matched the information in the Request. In some security models, such as is common in many Web Servers, a result of "NotApplicable" is treated as equivalent to "Permit". If "NotApplicable" is to be treated as "Permit", is it vital that the matching algorithms used by the Policy to match elements in the Request are closely aligned with the data syntax used by the applications that will be making the Request. A failure to match will be treated as "Permit", so an unintended failure may allow unintended access. A common example of this is a Web Server. Commercial http responders permit a variety of syntaxes to be treated equivalently. The "%" can be used to represent characters by hex value. In the URL path "/../" provides multiple ways of specifying the same value. Multiple character sets may be permitted and, in some cases, the same printed character can be represented by different binary values. Unless the matching algorithm used by the Policy is sophisticated enough to catch these variations, unintended access may be allowed. It is safe to treat "NotApplicable" as "Permit" ONLY in a closed environment where all applications that formulate a Request are closely aligned with the Policies used by the PDP. In a more open environment, where Requests may be received from applications that are not necessarily closely aligned with the Policies used by the PDP, it is HIGHLY RECOMMENDED that "NotApplicable" NOT be treated as "Permit" unless matching rules have been very carefully designed to match ALL possible applicable inputs, regardless of syntax or type variations. 0018. [Carlisle] C.3 use "First Applicable" http://lists.oasis-open.org/archives/xacml/200208/msg00099.html STATUS: APPROVED (NQ 9/9;Q 9/12) 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: APPROVED (Q 9/26) Use Polar's text below. 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)? [Polar] I agree with Carlisle that the problem he states needs to be reckoned with CR 19. The current algorithm breaks monotonicity in the evaluation of the First Applicable Policy Combining algorithm, as he points out. It should model the rule combinging algorithm. We should modify the current document by replacing the following paragraph: If there is any error evaluating the target or the policy, or a reference to a policy is considered invalid, then the evaluation shall continue looking for an applicable policy, if no applicable policy is found, then the result of the combination is "Indeterminate". with: If there is any error evaluating the target, or while evaluating a specific policy, the reference to the policy is considered invalid, or the policy itself evaluates to "Indeterminate", then the evaluation of the combining algorithm shall halt, and the result shall be "Indeterminate" with an appropriate error status. The pseudo code should say: Decision firstApplicableEffectPolicyCombiningAlgorithm(Policy policy[]) { for( i = 0 ; i < lengthOf(policy) ; i++ ) { Decision decision = evaluate(policy[i]); if(decision == Deny) { return Deny; } if(decision == Permit) { return Permit; } if (decision == NotApplicable) { continue; } if (decision == Indeterminate) { return Indeterminate; } } return NotApplicable; } 0020. [Michiharu] B.10: Resource Attributes scope value http://lists.oasis-open.org/archives/xacml/200208/msg00112.html STATUS: APPROVED (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) But 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 http://lists.oasis-open.org/archives/xacml/200209/msg00134.html (V0.11) STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=. Daniel and Polar have developed a list of functions and their semantics, attached to the above e-mail. 0024. [Anne] Make "gregorian" functions non-mandatory http://lists.oasis-open.org/archives/xacml/200208/msg00137.html STATUS: APPROVED (NQ 9/9;Q 9/12) 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 (NQ 9/9 Q 9/12) 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: WITHDRAWN (9/19) Replaced by #47. [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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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: WITHDRAWN (9/12) 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/200209/msg00078.html STATUS: ACCEPTED (Q 9/12) I propose to change the AttributeSelector element. <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:attribute name="RequestContextPath" type="xs:anyURI" use ="optional"/> <xs:attribute name="DataType" type="xs:anyURI" use="optional"/> </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 is <XPathNamespace> element. 0033. [Michiharu] Example two to separate document http://lists.oasis-open.org/archives/xacml/200208/msg00147.html STATUS: REJECTED (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) 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: WITHDRAWN (9/19) Replaced by #47. 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 (NQ 9/9;Q 9/12) 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 (NQ 9/9;Q 9/12) - 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: WITHDRAWN (9/9) 0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector http://lists.oasis-open.org/archives/xacml/200209/msg00078.html STATUS: ACCEPTED (Q 9/12) I request to remove "XPathVersion" attribute from AttributeSelector element. The reason is that we already allow a default value of XPathVersion in Policy and PolicySet elements. Since the minimum unit of the policy rules are Policy element, I think it is sufficient to specify XPath version information at a policy level, not at each AttributeSelector level. Policy writer who uses AttributeSelector must specify the xpath version in PolicyDefaults or PolicySetDefaults element. The value of XPath 1.0 version is "http://www.w3.org/TR/1999/Rec-xpath-19991116". 0040. [Michiharu,Simon] Semantics of sequences http://lists.oasis-open.org/archives/xacml/200209/msg00071.html STATUS: WITHDRAWN. REPLACED BY #42-#46. As far as I understand, the model for comparing two sequences in function draft 0.8 seems not sufficient for comparison (matching) framework. I am assuming that our data model supports a sequence as a base type. For example, type-member-of function supports only equality comparison but not other kinds of comparison such as string-greater-than etc. My opinion is that we need to specify two things: how to compare two sequences and how to compare each element. Draft documents and more of the proposal included in the e-mail. 0041. [Polar] Target Match Truth Table http://lists.oasis-open.org/archives/xacml/200208/msg00188.html http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction) STATUS: APPROVED (Q 9/19) Text change: 4.3.1.4 Rule evaluation A rule has a value that can be calculated by evaluating its contents. Rule evaluation involves separate evaluation of the rule's target and condition. The result of rule's target and condition are evaluated as if the "function:and" were applied to both results. The rule truth table is shown in Table 1. Target Condition Rule True True Effect True False Not Applicable True Indeterminate Indeterminate False True Not Applicable False False Not Applicable False Indeterminate Not Applicable Indeterminate True Indeterminate Indeterminate False Indeterminate Indeterminate Indeterminate Indeterminate Table 1 - Rule truth table [The subsequent 2 paragraphs after the table are no longer true, and should be removed.] 0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function http://lists.oasis-open.org/archives/xacml/200209/msg00098.html STATUS: APPROVED (NQ 9/16;Q 9/26) In ver 0.8 function draft, string comparison (set against a value) is differently specified in MatchId from Apply. Suppose attribute selector returns a sequence (e.g. "aaa" and "bbb"). In ResourceMatch, function:string-equal is used while in Apply, function:string-member-of is used: <ResourceMatch MatchId="function:string-equal"> <AttributeSelector RequestContextPath="/a/b/c/text()"> <AttributeValue>bbb</AttributeValue> </ResourceMatch> |<Apply FunctionId="function:string-member-of"> <AttributeValue>bbb</AttributeValue> <AttributeSelector RequestContextPath="/a/b/c/text()"> </Apply> We fix the above problem by using the higher-order bag function specified in 0.9 function draft: <ResourceMatch MatchId="function:string-equal"> <AttributeDesignator AttributeId="role1"/> <AttributeValue>bbb</AttributeValue> </ResourceMatch> <Apply FunctionId="function:any-of-each"> <Function FunctionId="function:string-equal"/> <AttributeDesignator AttributeId="role1"/> <AttributeValue>bbb</AttributeValue> </Apply> When we specify policy for MatchId, function:any-of-each is implicitly used for specifying the semantics of the comparison on bags. 0043. [Michiharu] XACML supports unordered set that is called a "bag" http://lists.oasis-open.org/archives/xacml/200209/msg00098.html STATUS: APPROVED (NQ 9/16;Q 9/26) XACML supports an unordered set type and does not support a sequence type because there is few requirement that needs sequence dependent policy specification (e.g. sequence-equal function (or point-wise comparison) in XPath 2.0 draft is one of such requirement but TC members decided that is a lower priority). We rename it from "sequence (unordered set)" to "bag". 0044. [Michiharu] XACML distinguishes singleton data from bag type http://lists.oasis-open.org/archives/xacml/200209/msg00098.html STATUS: APPROVED (NQ 9/16;Q 9/26) XACML has two kinds of functions: a function that defines semantics on singleton data (e.g. function:string-equal), and a function that defines the semantics on bags (e.g. function:any-of-each). This means that XACML distinguishes singleton data from bag type. We don't distinguish them by local name or its prefix. The specification lists function names as text. 0045. [Michiharu] XACML supports higher-order bag functions http://lists.oasis-open.org/archives/xacml/200209/msg00098.html STATUS: APPROVED (NQ 9/16;Q 9/26) XACML supports higher-order bag functions as 0.9 draft describes. 0046. [Michiharu] XACML supports operators for computing on bag types. http://lists.oasis-open.org/archives/xacml/200209/msg00098.html STATUS: APPROVED (NQ 9/16;Q 9/26) Comparison among bag types (e.g. any-of-each) is defined by higher-order bag functions as 0.9 draft describes. 0047. [Michiharu] Function specification for XPath handler http://lists.oasis-open.org/archives/xacml/200209/msg00143.html STATUS: APPROVED (Q 9/26) Functions specified in XACML_functions v13 I propose to add the following two functions. Both are XPath related functions. I attached modified policy specification of Example 1 and 2 (might have mistakes). This proposal has been also agreed by Simon. [A] Request of function additions: - function:xpath-equal comparison on two DOM nodes - function:xpath-match hierarchical comparison on two DOM nodes [B] Function description: - function:xpath-node-equal This function takes two arguments, the first of "xs:string" and the second of "xs:string" and returns an "xs:boolean". Both arguments are valid XPath expressions defined in XPath 1.0 specification [1]. This functions returns true if a set of DOM nodes obtained by applying the first XPath expression on the XACML Request Context includes at least one DOM node that is also obtained by applying the second XPath expression on the XACML Request Context. If the first XPath or the second XPath do not return DOM node set, this function returns false. When XPath expression includes one or more namespace prefix, then it is resolved using XPathNamespace element specified in corresponding Policy element or PolicySet element. For example, the following expression shall return true: <Apply FunctionId="function:xpath-equal"> <AttributeValue>/Request/Subject/Attribute[@AttributeId ="role"]/AttributeValue</AttributeValue> <AttributeValue>/Request/Subject/Attribute[@AttributeId ="role"]/AttributeValue</AttributeValue> </Apply> - function:xpath-node-match: This function takes two arguments, the first of "xs:string" and the second of "xs:string" and returns an "xs:boolean". Both arguments are valid XPath expressions defined in XPath 1.0 specification [1]. This function first extends the first argument to support pseudo hierarchical access control on XML document structure. If "a" is an element node and it is specified as the first argument, the function replace it with "a | a//* | a//@*" meaning that all the element and attributes below the specified element "a". If "a" is an attribute node, then the function does not modify the first argument. Then this function internally calls xpath-equal function and return the identical return value. For example, the following expression shall return true when "urn:...:xpath" attribute returns a md:patient element that is below a md:record element: <Apply FunctionId="function:xpath-match"> <AttributeValue>//md:record</AttributeValue> <Apply FunctionId="function:string-one-and-only> <ResourceAttributeDesignator AttributeId="urn:...:xpath"/> </Apply> </Apply> The above function is internally replaced by: <Apply FunctionId="function:xpath-equal"> <AttributeValue>//md:record | //md:record//* | //md:record//@*</AttributeValue> <Apply FunctionId="function:string-one-and-only> <ResourceAttributeDesignator AttributeId="urn:...:xpath"/> </Apply> </Apply> [C] Modified policy examples: (Besides this proposal, I removed DataType attribute and inserted string-one-and-only function in several places) (See attached file: XACML-SimplePolicy.txt)(See attached file: XACML-Rule2.txt)(See attached file: XACML-Rule3.txt)(See attached file: XACML-rule4.txt)(See attached file: XACML-Rule1.txt) [1] XPath 1.0, http://www.w3.org/TR/xpath 0048. [Simon] subject-category value must be unique in given context STATUS: APPROVED (Q 9/26). In any Request Context, there can be no more than one <Subject> that contains any given value for a subject-category attribute. 0049. [Anne] Remove function:decimal-mod http://lists.oasis-open.org/archives/xacml/200209/msg00170.html STATUS: APPROVED (Q 9/26) Already removed in XACML_functions.doc v13 This function was specified in an early draft, but was dropped in v13. Just a sanity check to be sure this is what we intended. 0050. [Anne] dateTime-add-*Duration and dateTime-subtract-*Duration mandatory http://lists.oasis-open.org/archives/xacml/200209/msg00170.html STATUS: APPROVED (Q 9/26) The dateTime-add-yearMonthDuration, dateTime-add-dateTimeDuration, dateTime-subtract-yearMonthDuration, and dateTime-subtract-dateTimeDuration functions are now mandatory. We had earlier decided they were too hard to implement, but now that we have a function specification that is detailed, we feel they are important and should be mandatory. 0051. [Anne] Use rfc822Name and x500Name rather than *name http://lists.oasis-open.org/archives/xacml/200209/msg00171.html STATUS: APPROVED (Q 9/26) Capitalize "N" in "Name" to be consistent with the other primitive datatypes we picked up from xs: and xf: 0052. [Anne] Remove function:string-regexp-match http://lists.oasis-open.org/archives/xacml/200209/msg00171.html STATUS: APPROVED (Q 9/26) The match functions all have the pattern to match against as the first argument. For consistency, we will use regexp-string-match, which also has the pattern to match against as the first argument. There is a case to be made for supporting arguments in either order, but in order to minimize the list of functions for 1.0, we will not include "pattern second" forms until a later version. 0053. [Anne] Separate attribute values from attribute identifiers in App. B http://lists.oasis-open.org/archives/xacml/200209/msg00175.html STATUS: APPROVED (Q 9/26) But omit example:action:* values. I have put both Attribute Values and Attribute Identifiers into the "Attributes" section, but they should be listed separately (values in association with the identifiers to which they apply). Attribute Identifier Associated Attribute Values ============================== urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:example:action:read urn:oasis:names:tc:xacml:1.0:example:action:xml-ac urn:oasis:names:tc:xacml:1.0:subject-catetory urn:oasis:names:tc:xacml:1.0:subject-category:access-subject urn:oasis:names:tc:xacml:1.0:subject-category:codebase urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine urn:oasis:names:tc:xacml:1.0:resource:xpath 0054. [Anne] Change datatype:ufs-path to resource:ufs-path http://lists.oasis-open.org/archives/xacml/200209/msg00175.html STATUS: APPROVED (Q 9/26) "ufs-path" is listed in Appendix B as a Datatype, but we have no functions that use that datatype. I think it is actually an "Attribute Identifier". It belongs under the resource attributes, so should be called <prefix>:resource:ufs-path 0055. [Anne] Action values do not need identifiers STATUS: APPROVED (Q 9/26) We have reserved <prefix>:example:action: as a prefix to use for example action values where we want those values to be URIs. We should not need designated identifiers. action-id attribute values can actually be any type, and in examples may frequently be strings such as "read". 0056. [Anne] Add resource:xpath attribute-id http://lists.oasis-open.org/archives/xacml/200209/msg00176.html STATUS: APPROVED (Q 9/26) This attribute identifier was omitted in Appendix B. It should be included. 0057. [Anne] Move authn-locality attributes to Subject Attributes http://lists.oasis-open.org/archives/xacml/200209/msg00177.html STATUS: APPROVED (Q 9/26) Section B.2 Authentication locality In Appendix B, there is a separate section for the Authentication Locality identifiers. These actually belong under Subject Attributes, and should be named accordingly. For consistency, they should be renamed "subject:authn-locality:ip-address" and "subject:authn-locality:dns-name". If we had standard DataTypes for ip-address and dns-name, they could be one Attribute Identifier, with distinguished DataTypes, but I think it is too late to define new DataTypes (and the associated -equal and -match functions) now. This will work. 0058. [Anne] Move Access Subject Categories to Subject Attributes http://lists.oasis-open.org/archives/xacml/200209/msg00177.html STATUS: APPROVED (Q 9/26) Section B.3 Access subject categories These should also be moved under "Subject Attributes" as values for the "subject:subject-category" Attribute. 0059. [Anne] Various changes to App. B Datatypes http://lists.oasis-open.org/archives/xacml/200209/msg00177.html STATUS: APPROVED (Q 9/26) Section B.5 Data types - Rename "datatype:x500name" to "datatype:x500Name" - Rename "datatype:rfc822name" to "datatype:rfc822Name" - Remove "datatype:ufs-path". This is a resource attribute, not a datatype. - Remove "datatype:numeric" - Remove "http://www.w3.org/2001/XMLSchema:Gregorian" - Add the other mandatory-to-implement primitive datatypes: xs:string xs:boolean xs:integer xs:decimal xs:date xs:dateTime xs:anyURI xs:hexBinary xs:base64Binary xf:dateTimeDuration xf:yearMonthDuration 0060. [Anne] New section in App. B for Action attributes http://lists.oasis-open.org/archives/xacml/200209/msg00177.html STATUS: APPROVED (Q 9/26) New Section after B.8: Action attributes - Add "action:action-id" - Add "action:action-namespace" 0061. [Michiharu] Change description of <AttributeSelector> http://lists.oasis-open.org/archives/xacml/200209/msg00179.html STATUS: APPROVED (Q 9/26) AttributeSelector, Page 49 <AttributeSelector> [required] MAY be used to identify one or more values in the <Subject> element of <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Subject> element of the <xacml-context:Request> element. ==> <AttributeSelector> [optional] Attribute selector using XPath expression. It MUST contain a legal xpath expression over the <xacml-context:Request> element. This operator returns a bag of string data or a single primitive value. In case of XPath 1.0, an evaluation value of the XPath expression is either a node set, string value, numeric value, and boolean value. When node set is returned, each node may consist of children nodes (structured node). Then each node is converted into a string data by applying a string function defined in XPath 1.0 specification. Then this operator returns a bag of string values. When either string, numeric or boolean value is returned, this operator returns a single primitive value of xs:string, xs:decimal, and xs:boolean type, respectively. When this element is specified, the policy MUST define the version of the XPath specification using <XPathVersion> element. When an xpath expression has one or more namespace prefix, they are resolved using XPath namespace and prefix information specified in the <XPathNamespace> element below this operator. If no such element is specified, then an <XPathNamespace> element in <PolicyDefaults> element in the parent <Policy> (or <PolicySet>) element is used. 0062. [Michiharu] Latest schema and draft do not reflect CR#32 http://lists.oasis-open.org/archives/xacml/200209/msg00179.html STATUS: REJECTED (Q 9/26). v17.doc and 16i.xsd do reflect. The latest draft and schema does not reflect the change request 0032 (Schema change of AttributeSelector). 0063. [Michiharu] Use XPathVersion, not XpathVersion http://lists.oasis-open.org/archives/xacml/200209/msg00179.html STATUS: APPROVED (Q 9/26) XPathVersion, Page 50 In the example, XPathVersion is used but in the text, XpathVersion is used. It should be XPathVersion. [XPathVersion actually has been removed at the specific location cited, but v17 will be consistent in using "XPath", not "Xpath". 0064. [Michiharu] [XQO] is a draft and can not be referenced STATUS: APPROVED (Q 9/26). Use http://www.w3.org/TR/2002/WD-xquery-operators-20020816/ The specification we are citing for xf: and op: data types and functions is a W3C draft specification, so is subject to change. We decided to reference the current snapshot identified as http://www.w3.org/TR/2002/WD-xquery-operators-20020816/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC