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

[Jacques Durand <JDurand@us.fujitsu.com>]

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:Anne.Anderson@sun.com]
Sent: Friday, December 02, 2005 6:44 AM
To: dipal-discuss@lists.oasis-open.org
Subject: [dipal-discuss] Introduction to dipal-discuss

Welcome to the dipal-discuss@lists.oasis-open.org 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: Anne.Anderson@Sun.COM
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: dipal-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dipal-discuss-help@lists.oasis-open.org