WS-XACML Issues: 55,56,57,59,60

The following issues were supposed to be reviewed by the TC by today,
but I forgot to bring them up in today's meeting, and we really didn't
have time.  Could we put them on the agenda for the 1 Feb meeting, and
could everyone review them before then?  I am the Champion for all and
all are currently OPEN.  #58 is not included because I am on the hook
for proposing a solution, and have not yet done so.

55. WS-XACML: Address policy references in a Requirements element
containing a PolicySet

Working Draft 8 does not address how policy references are to be
handled. Some options: 1) Disallow them. 2) Say they must be expressed
in a resolvable format (e.g. a URL that resolves to the instance of the
policy being referenced). 3) Add an element for including referenced
policies and require that all referenced policies must be included in
this element. 4) Say it is up to the policy matcher to know how to
retrieve any referenced policies (this violates the goal of having
XACMLAssertions be matchable using a generic policy engine). [Anne] I
prefer 2) or 3).

56. WS-XACML: Add optional "Preference" XML attribute to Apply element

An Apply element may accept more than one value for a given Attribute
(e.g. subset, greater-than). Two such elements, when intersected, can
still yield more than one acceptable value (e.g. x
> 5, x
> 8 => x
> 8).
If the generic policy engine had a hint as to which end of a range, or
which element in a set is most preferred by the entity for which the
intersection is being done, then the generic engine could select
particular values for use in a Web Services interaction. This could be
implemented as having values of "greater" or "lesser", where "greater"
means greater or later (for time or date values), and closest to the end
of a set of elements (treated as ordered for this purpose). "lesser"
means less or earlier (for time or date values) and closest to the
beginning of a set of element (treated as ordered).

57. WS-XACML: Restrictions on XPath expression to support matching
Attribute references

It is impossible to tell in general whether two XPath expressions refer
to the same nodeset. For example //A/B[2] may or may not refer to the
same nodeset as //A/B[@test="true"]. In order to match policy
constraints in two XACMLAssertions, it is necessary to tell whether the
constraints apply to the same nodesets. The current draft proposes
restricting XPath expressions to absolute paths that do not contain
query operators. Is this sufficient or not? Is it overly restrictive?

59. WS-XACML: Allow restricted regular expression functions in
XACMLAssertion

Allowing the Apply elements used in an XACMLAssertion to use regular
expression functions would be a very useful and powerful mechanism. The
first problem is that it is impossible to intersect unrestricted regular
expressions - they must be limited to those that are equivalent to a
classic finite automaton. The second problem is that intersection of
even such limited regular expressions can be a somewhat expensive
operation. Is it worth trying to include this?

60. WS-XACML: Remove "XACML Authorization Token" and "Conveying XACML
Attributes in a SOAP Message"?

Most of the Web Services Profile of XACML (WS-XACML) is devoted to the
XACMLAssertionAbstractType and the two derived Assertion types:
XACMLAuthzAssertion and XACMLPrivacyAssertion. There are two small
sections of the profile that were included because they relate to the
use of XACML in a Web Services context, but require no new schema
elements, no restrictions on XACML, etc. - they are just "how to"
guides. Would it make sense to remove those sections from WS-XACML? This
would focus the document and make it easier for readers to understand
what it is about.

Regards,
Anne

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