OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dipal-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dipal-discuss] How to move forward


might be considered an XACML-based example of a "0.7" spec :-).  Its 
scope is consistent with the proposed scope for the DIPAL TC that 
started this group off:

"The scope envisioned for the proposed OASIS TC is the development of a
domain-independent language for expressing policy assertions, along with
semantics for verifying such assertions, comparing or intersecting
assertions over the same policy item from two different policies, and
selecting preferred values from a set of permitted values.  The language
would provide a generic way of expressing conditions that particular
domain-specific policy items must satisfy.

The language would be designed to express policy assertions for use with
any Boolean web services policy framework.  That is, the language would
express assertions over individual policy vocabulary items, but
combining these assertions into a policy expressing acceptable
combinations and alternatives would be relegated to a framework layer.
The development of a policy framework for combining individual policy
assertions into policies is not within the proposed scope."

Does Fujitsu have an interest in a different scope?

I would be happy to work with any group of "committed folk" to revise 
WS-PolicyConstraints or any other base document in preparation for 
submission to any appropriate standards TC or WG.  I think we need to 
know where we plan to submit the document, however, in order to assess 
the interest of the target group and to target the revisions appropriately.


Frank McCabe wrote:
> It seems that one route to success is to initially develop a version
> 0.8 of a spec off-line before submitting it to any standards group.
> That can be done by a group of committed folk who would not need
> universal approval. Of course, that requires foresight etc on the
> part of the sponsoring companies.
> What do you think would be the scope of an independent DIPAL? The
> answer to that question would be critical, for example, to Fujitsu's
> interest in participation.
> Frank
> On Jan 30, 2006, at 7:35 AM, Anne Anderson wrote:
>> 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
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: dipal-discuss-help@lists.oasis- open.org

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]