[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XACML 1.0 -> 1.1 changes
Here is a summary of the changes I saw between XACML 1.0 and the XACML 1.1 draft. The only error I noticed is that XACML 1.1 does not include the new "ordered-deny-overrides" and "ordered-permit-overrides" rule and policy combining algorithms. I thought these were approved for inclusion in 1.1 on 26 June 03, although the draft minutes do not reflect this. The only nit (which I would not hold up approval for) is that, with the new "type unification" definition, we need a definition for "type expression :-) -Anne - 1.1.1 Glossary, Preferred Terms Added definition: Type Unification - The method by which two type expressions are "unified". The type expressions are matched along their structure. Where a type variable appears in one expression it is then "unified" to represent the corresponding structure element of the other expression, be it another variable or subexpression. All variable assignments must remain consistent in both structures. Unification fails if the two expressions cannot be aligned, either by having dissimilar structure, or by having instance conflicts, such as a variable needs to represent both "xs:string" and "xs:integer". For a full explanation of 'type unification', please see [Hancock]. - 5.1 Element <PolicySet> Policies included in the <PolicySet> element MUST be combined by the algorithm specified by the PolicyCombiningAlgId attribute. [Added:] <PolicySet> is treated exactly like a <Policy> in all the policy combining algorithms. - 5.4 Element <XPathVersion> The <XPathVersion> element is REQUIRED if the XACML enclosing policy set or policy contains <AttributeSelector> elements [added:] or XPath-based functions. - 5.28 Element <SubjectAttributeDesignator> ...such that the value of the element's SubjectCategory attribute matches, by [old: string-equality] anyURI-equality, the value of the <Request> element's subject category attribute. - 5.28 Element <SubjectAttributeDesignator> In two places: Old: urn:oasis:tc:xacml:1.0:subject-category:access-subject New: urn:oasis:names:tc:xacml:1.0:subject-category:access-subject - 5.32 Element <AttributeSelector> Old: If the policy writer intends to select the string value of an element's contents rather than the node representing the element itself, then the XPath expression MUST terminate in "/text()". The resulting sequence of string-data SHALL be converted to a bag of value sof the type that is implied by the type system. New: Each selected node by the specified XPath expression MUST be either a text node, an attribute node, a processing instruction node, or a comment node. The string representation of the value of each selected node MUST be converted to an attribute value of the specified data type, and the result of the AttributeSelector is the bag of the attribute values generated form all the selected nodes. If the selected node is different from the node types listed above, then the result of that policy SHALL be "Indeterminate" with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error. - 5.32 Element <AttributeSelector> Text explanation of "MustBePresent" attribute: Whether or not the designated attribute must be present in the context. [Added all the following:] If the XPath expression selects no node, and the MustBePresent attribute is TRUE, then the result is "Indeterminate" and the status code SHALL be "urn:oasis:names:tc:xacml:1.0:status:missing-attribute". If the XPath expression selects no node, and the MustBePresent attribute is missing or FALSE, then the result is an empty bag. If the XPath expression selects at least one node and the selected node(s) could be successfully converted to a bag of values of the specified data-type, then the result is the bag, regardless of the value of the MustBePresent attribute. If the XPath expression selects at least one node, but there is an error in converting one or more of the nodes to values of the specified data-type, then the result is "Indeterminate" and the status code SHALL be "urn:oasis:names:tc:xacml:1.0:status:processing-error", regardless of the value of the MustBePresent attribute. - 5.36 Element <AttributeAssignment> Append to first paragraph: The <AttributeAssignment> element MAY be used in any way consistent with the schema syntax, which is a sequence of "any". The value specified SHALL be understood by the PEP, but it is not further specified by XACML. See section 7.11 "Obligations". - 6.7 Element <Attribute> In schema fragment: Old: <xs:element ref="xacml-context:AttributeValue" minOccurs="0"/> New: <xs:element ref="xacml-context:AttributeValue"/> [New matches the existing schema] - 6.7 Element <Attribute> Old: <AttributeValue> [Optional] At most one attribute value. New: <AttributeValue> [Required] Exactly one attribute value. The mandatory attribute value MAY have contents that are empty, occur once, or occur multiple times. - 7.10 Authorization decision In this case, the <Status> element MAY list the names and data-types of any attribues of the subjects[" and the resource" changed to], resource, action, or environment that are needed by the PDP to refine its decision. ... it MUST NOT list the names and data-types of any attribute of the subject[" or the resource" changed to], resource, action, or environment for which values were supplied in the original request. - 11. References Added: [Hancock] Hancock, "Polymorphic Type Checking", in Simon L. Peyton Jones, "Implementation of Functional Programming Language", Section 8, Prentice-Hall International, 1987. - A14.13 XPath-based functions The XPath expressions in these functions are restricted to the XACML request context. [Add:] The <xacml-context:Request> element is a context node for every XPath expression. - A.14.13 XPath-based functions Description of "xpath-node-match" Old: This function SHALL first extend the first argument to match an XML document in a hierarchical fashion. If 'a' is an XPath expression and it is specified as the first argument, it SHALL be interpreted to mean match the set of nodes specified by the enhanced XPasth expression "a|a//*|a//@*". In other words, the expression 'a' SHALL match all elements and attributes below the element specified by 'a'. This function SHALL evaluate to "True" if any XML node that matches the enhanced XPath expression is equal according to "op:node-equal" [XF Section 13.1.6] to any XML node from the node-set matched by the second argument. New: This function SHALL evaluate to "True" if either of the following two conditions is satisfied: (1) Any XML node from the node-set matched by the first argument is equal according to "op:node-equal" [XF Section 13.1.6] to any XML node from the node-set matched by the second argument. (2) Any attribute and element node below any XML node from the node-set matched by the first argument is equal according to "op:node-equal" [XF Section 13.1.6] to any XML node from the node-set matched by the second argument. NOTE: The first condition is equivalent to "xpath-node-equal", and guarantees that "xpath-node-equal" is a special case of "xpath-node-match". -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]