RE: [xacml] Comparing ACME with WS Policy framework

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

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: 

Sun Microsystems Laboratories

1 Network Drive,UBUR02-311     Tel: 781/442-0928

Burlington, MA 01803-0902 USA  Fax: 781/442-1692