RE: [xacml] Comparing ACME with WS Policy framework

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] Comparing ACME with WS Policy framework

Anne - Thanks for the response.  Your comments are very valuable.  For me, the main "take-away" is that XACML focuses exclusively on one type of policy-consumer - the most important one, of course.  That is the PDP; whose job it is to render a "decision".  I expect that all policy architectures contain a PDP.  But, many policy architectures also contain alternative policy-consumers.  Some of these alternative policy-consumers have to combine policies, not just decisions (as PDPs are required to do).  In the general case, combining policies is not practical.  However, I expect that under carefully-chosen conditions, it IS practical (indeed, the WSS-QoP whitepaper describes precisely how to do this in one circumstance of practical interest).

There is nothing in XACML that inherently prevents it serving this purpose.  To the best of my knowledge it is no more limited in this respect than the other candidate policy languages.  So, it is legitimate to ask "how must XACML adapt to accommodate the requirement to combine policies?"

Prima facie, the changes required are modest: profiles are required that prescribe the large-scale logical structure of a policy statement (e.g. AND of ORs) and the existing combining algorithms have to be extended to describe how policies are combined in these profiles.

I put these thoughts forward in the spirit of fostering debate, not because I am convinced that this is the best way to proceed.  Some of XACML's main strengths are its recognition that combining of some form is required and its rich and well-understood set of operators.  I would hate to see us dismiss it as a basis for solving other problems because we didn't fully appreciate its strengths relative to other proposals.

All the best.  Tim.

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Wednesday, February 05, 2003 3:38 PM
To: Tim Moses
Cc: 'XACML'; Ron Monzillo; Steve Hanna
Subject: Re: [xacml] Comparing ACME with WS Policy framework

[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