Discussion regarding policy framework choices

I think we need to have a discussion regarding the choice of policy framework for standardization.

So far I've seen four options in the working group

1) Simple markup with clear separation of trust from decision

as in Nokia position paper, http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-0012/SecurityPolicy_09.pdf

2) Profile of XACML 2.0

To be defined, but use XACML 2.0 standard as base

3) New markup as submitted by BONDI, similar to  XACML 2.0 but different in schema and processing rules 

http://dev.w3.org/2009/dap/policy/Profile.html

4) No policy language at all.

Now I think we've agreed that no matter which approach, we are going to clearly separate trust from decisions, as in the Nokia position paper.

I think this has advantages. If you look at what we've been calling the Profile document, you see that most of the attribute tables deal with common names of certificates and so on. Thus it is mostly about trust decisions, and perhaps we do not need to specify XACML-like rules for determining trust from certificates if a few clear trust domains could be defined. It seems like a lot of overhead to say, untrusted, mydomain, or abcdomain.

I think before we proceed we need to understand why once trust is separated we need the full power of XACML like processing, and if we do, why we cannot profile XACML 2.0. This would have the benefits of leveraging experience, open source, and understanding of XACML. Creating something similar but different seems open to confusion. What are the technical reasons for not profiling XACML 2.0? Based on experience, how much of XACML-like processing is really needed?

I note that there are differences, including the elimination of XACML Obligations, profiling targets out of rules, not defining effect, including policy sets in policy sets, to mention a few. However before working through all the details, we should ask what the benefits are, and is a simpler approach more appropriate. Note also that if it is not a profile, then every detail dealt with in XACML would need to be reconsidered and specified. I am asking for help to understand why this is not a profile and where the biggest benefits have been found.

>From a WG perspective the simpler we make our specifications the easier it will be to understand correctness,  for implementation, testing and exiting CR.

I'd like to discuss this tomorrow , as well as how to progress regarding FPWD for policy.

regards, Frederick

Frederick Hirsch
Nokia

Received on Tuesday, 22 June 2010 21:16:51 UTC