How to move forward

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

Colleagues,

I would like to start a discussion of the practicalities of moving 
forward with a standard for a "domain-independent policy assertion 
language".  Here are some possibilities as I see them, with their pluses 
and minuses.

1. Start a new OASIS TC for DIPAL.

PLUSES: The TC could focus on identifying or developing the best 
language for the job.

MINUSES: We have a chicken and egg problem: until one or more domains 
use DIPAL for expressing their policies, organizations can't justify 
spending resources to standardize it.  But until it is standardized, no 
domains are able to use it.  Most organizations are already strained for 
resources to cover the various web services standards being developed, 
so it is not clear that we could get enough people to staff a new OASIS 
TC even if many organizations would like to see such a standard developed.

2. Move DIPAL forward in the OASIS XACML TC.

PLUSES: if we use WS-PolicyConstraints, or something similar, it is 
already XACML-based.  XACML needs a profile for expressing authorization 
policies for web services, so the work could be justified.  Applications 
to other domains could be done via white papers, conference papers, etc. 
  XACML TC members already understand the constraint-based approach to 
policy expression.

MINUSES: XACML's charter is limited to authorization and access control. 
  Based on earlier votes objecting to the scope of WSPL, a DIPAL spec in 
the XACML TC could use only authorization and access control examples. 
This makes it look like a one-domain language and makes it harder to 
"sell" for other domains.  Also, the XACML TC is a small group, and 
might not have enough bandwidth to take this on without new members to 
champion the work.

3. Include DIPAL as an option in WS-Policy standardization.

PLUSES: This would make clear how DIPAL is used for multiple domains, 
and would allow close integration of DIPAL with WS-Policy syntax.

MINUSES: There has been no official interest in DIPAL from the WS-Policy 
sponsors.  WS-Policy has still not been submitted to a standards group, 
and this may reflect enough internal conflict among its sponsors that 
they are unlikely to agree on adding yet another component.

4. Include DIPAL as an option in another standard.

PLUSES: Could fit with WS-Agreement, or could be standardized along with 
the policy schema for some particular domain.

MINUSES: As with the XACML TC option, this risks making DIPAL look like 
a one-domain language.  No other standards WG or TC has indicated 
interest in taking on DIPAL.

Thoughts?  Suggestions?

Regards,
Anne
-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA