Re: [xacml] Comparing ACME with WS Policy framework

[Anne Anderson <Anne.Anderson@Sun.com>]

[Reference: "A technical comparison of WS-Policy framework and
XACML" attached to
http://lists.oasis-open.org/archives/xacml/200301/msg00021.html]

On 29 January, Tim Moses writes: [xacml] Comparing ACME with WS Policy framework
 > Colleagues - Here are some preliminary thoughts on the relationship between
 > the OASIS standard XACML and the proprietary WS Policy framework.  I am
 > interested in other people's views.  All the best.  Tim.

I finally had time to read this over.  Thanks for doing this
analysis, Tim!  It raises some interesting ideas.

First of all, I have some doubts about how easy it would be to
"extend" XACML to support negotiation/resolution of two sets of
requirements.  XACML wasn't designed for that, but it might be an
interesting research project.

"Policy" means different things in different contexts.  XACML
supports "access control policies".  There are also policies for
provisioning services, policies for management and monitoring of
services, etc.  The requirements of the various "policy" domains
are rather different, as in the present case where "access
control" merely combining Boolean results of sub-policies, but
WS-Policy requires actual "merging" of multiple policies.

Just above the table, the comparison says "...the result of the
[WS-Policy] combining-algorithm is not a Boolean, but a
definitive policy statement that is devoid of options."  I think
the result might include options: for example, if I merge my
preferences with those of my organization, I might get a more
restricted list of "options" that are then merged with my
correspondent's options to return a single choice.  At any step,
the combining-algorithm might need to return a new set of 1st
choice, 2nd choice, 3rd choice, etc.

The comparison suggests that XACML "Policy set" is similar to
WS-Policy "policy inclusion".  Can you explain further?  I would
have thought from the description (policy inclusions [is] a
technique which allows a policy to be referenced from another
policy) that "PolicyIdReference" and "PolicySetIdReference" is
the XACML construct most comparable to WS-Policy "policy
inclusion".

The description of under "XACML Policy" mentions "algorithm to be
used for combining those rules."  I think a more accurate
description is "algorithm to be used for combining the results of
evaluating those rules."  We did not want to tackle "merging"
even of policies that consist of Boolean expressions.  I think
"merging" non-boolean statements might be even harder.

Nevertheless, when I think of the specific "merge" functions
described - OneOrMore, All, ExactlyOne - it seems do-able.  On
the other hand, if the statements are annotated with Required,
Optional, Rejected, Ignored, and Observed, there are more states
to handle.

I agree that there seems to be no real benefit in supporting the
declarative form of statement in WS-Policy.

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