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: 
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692