RE: [dipal-discuss] Introduction to dipal-discuss

Title: RE: [dipal-discuss] Introduction to dipal-discuss

Thanks Anne for this intro.

To some extent it is certainly possible to model (parts of) most policies in a domain-independent way. Concepts like roles, resources, action, not to mention the logical ways to combine or to condition these (exceptions, dates, frequency, Boolean operators, pre-conditions, etc) appear to be general enough to apply to most case. Such a model would be underlying to the "language" that is mentioned as a target for standardization:

>The goal of the language is to facilitate interoperability and >maintainability of web services policies.  A single policy assertion module >supporting this language should be able to verify, match, intersect, or >perform preferred value selection using any assertions written in the >language, from any domain.

The value in doing so needs be discussed with more details however, as this will impact how far one wants to go in the "domain-independent" direction. I can imagine that over-engineering the model can be counterproductive (e.g. abusing of codelists and so on), while a model that is too light may have little value beyond methodology support for policy designers. 

A key indicator for gauging the value of a policy model, as hinted at in Anne intro, might very well reside in how much of it can be processed by these "policy assertion modules" above, and the value such modules bring compared to an entirely domain-specific processing. 

Besides the gathering of requirements, I'd like to see us always keep an eye on the "processing value", and how "domain-independent" processing can advantageously compose with domain-dependent processing. (I actually see that as just another dimension of the requirements space that motivates this effort...). 

Cheers,

Jacques

-----Original Message-----

From: Anne Anderson [mailto:] 

Sent: Friday, December 02, 2005 6:44 AM

To: 

Subject: [dipal-discuss] Introduction to dipal-discuss

Welcome to the  mailing list!  The

purpose of this list is to discuss a possible new OASIS Technical

Committee to develop a domain-independent language for expressing policy

assertions, including those for web services.

The proposed Domain-Independent Policy Assertion Language (DIPAL) TC 

would develop a language that would layer on top of any Boolean web 

services policy framework, including WS-Policy.  The intent would be to 

make it work with whatever becomes the standard policy framework, 

whether that is WS-Policy or something else.  Therefore, this activity 

addresses a different layer in the policy processing stack from 

WS-Policy and is complementary to such a policy framework language.

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 such a policy framework for combining individual 

policy assertions into policies is not within the proposed scope.

The goal of the language is to facilitate interoperability and

maintainability of web services policies.  A single policy assertion

module supporting this language should be able to verify, match,

intersect, or perform preferred value selection using any assertions

written in the language, from any domain.  This means policy processors

would not need new code modules for each new type of policy assertion

that is required for a system or application.  The policy framework may

make use of policy assertions written in the domain-independent language

as well as assertions written in other domain-specific languages, so the

new language need not conflict with domain-specific Assertions that gain

wide industry acceptance.

If the discussion list ended with a proposal to form a new OASIS TC, we

envision the TC operating under the "RF (Royalty Free) on Limited Terms"

IPR mode as defined in the OASIS Intellectual Property Rights (IPR)

Policy. We also anticipate that one of the input documents to the

proposed TC would be the draft "XACML-based Web Services Policy

Constraints Language (WS-PolicyConstraints)" specification authored by

Sun Microsystems and offered on royalty-free terms.  This draft

specification is available at

http://research.sun.com/projects/xacml/ws-policy-constraints-current.pdf

There are various resources related to the topic of this list at

http://research.sun.com/projects/xacml/, including a slide presentation

with speaker's notes, a short white paper that includes a list of

Frequently Asked Questions, the WS-PolicyConstraints specification, and

an example of applying WS-PolicyConstraints to the types of Assertions

that might be used with WS-Security, developed as a proof-of-concept.

I have volunteered to be the discussion list leader, so please send

questions about the use of the list to me.  We welcome feedback on the

concept of a "domain-independent policy assertion language" as well as

on the specific WS-PolicyConstraints proposal or other proposals that

fit the charter of the proposed TC or on the proposed charter itself. 

We also need to know if there are sufficient volunteers willing to 

participate in such a TC and contribute to the development of this 

language, so if you are interesting in participating, please let us know.

I have been receiving various questions off-list that I think others may 

also be interested in, so I will repost some of those anonymously with 

my answers.

Regards,

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

---------------------------------------------------------------------

To unsubscribe, e-mail: 

For additional commands, e-mail: