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

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

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