[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]