RE: [dipal-discuss] all policies are non-functional?

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

Title: RE: [dipal-discuss] all policies are non-functional?

Without having spent as much time on this as some on this list, (translate: my comments may seem naïve to some but I am aware of this ;-) it appears to me that the three notions:

- policy
- capability
- agreement
share evidently some common constructs, and Hal's comments below suggest that capability (policy type #2) is a kind of policy.

But can they still all be reduced to a single notion of "policy"?
Is an agreement "some" combination/intersection of two or more policies? Or something more?
Is a capability a set of policy "patterns"?
It seems to me that answering these questions is part of defining the requirements for a policy language, if only because they relate to the concrete applications of policies that - I assume - we have in mind.

Jacques

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Thursday, February 02, 2006 9:12 AM
To: Xinyu Zhou; dipal-discuss@lists.oasis-open.org
Subject: RE: [dipal-discuss] all policies are non-functional?

For several years I have been presenting an abstract policy model in
which there are (potentially) three different sets of policies
associated with every message flow. This means, for example, that for
the request/response pattern, there are potentially six.

The three types are as follows:

1. Policies advertised by a Receiver. These could potentially describe
properties required of messages to be processed by the Receiver. They
might also contain other sorts of policies, such as commitments by the
Receiver to future actions (e.g. keep data private) however these are
not of interest in the present discussion. This category is optional, in
the sense that Receivers for one reason or another (e.g. lack of
standards) may choose not to advertise any policies.

2. Policies about what the Sender is willing to do to the message to
make it acceptable to the Receiver. I maintain that these policies
always exist although they may be implicit in code or configuration.

3. Policies enforced by the Receiver. These are the policies used by the
receiver to determine if and how a received message should be processed.
In general, these policies will not necessarily be the same as those in
#1. For example, they might be more detailed or more lenient. It could
be debated how important it is that they be expressed in the same
language as those of #1. As in the case of type #2 these are always
present although they may be implicit.

Notice that these policies are not limited to Access Control, although
is may be simplest to think of them as such. For example, WS-RM
specifies an way of expressing type #1 policies relating to reliable
message sequences.

Given these types, the processing model is as follows:

A. The Sender obtains the type #1 policies which apply to a Receiver to
which it intends to send a message.

B. The Sender intersects these policies with its own type #2 policies.
There are three possible outcomes.

    1. There is no intersection. This produces a local error. No message
is sent.
    2. The intersection results in exactly one policy set. This set is
chosen to be applied.
    3. The intersection results in multiple policy sets. The Sender must
select one set to apply, based on information in the policy or
elsewhere.

C. The Sender prepares the message according to the chosen policy.

D. The Sender sends the message to the Receiver.

E. The Receiver uses the policies of type #3 to decide if and how to
process the message.

This model implies that there are the following policy processing
functions, with the following inputs:

Discovery(Receiver) {Step A.}
Intersection(Type #1 policies, Type #2 policies) {Step B.}
Selection(Intersection(), priority info) {Step B.3}
Evaluation and Enforcement(policies, context) {Steps C & E)

As Anne has pointed out, Evaluation and Enforcement are pretty well
understood. The options for Discovery are limited by environmental
constraints and thus likely to be the same regardless of the policy
language. Therefore, the focus of this list is (rightly) on Intersection
and perhaps Selection.

Hal

> -----Original Message-----
> From: Xinyu Zhou [mailto:xinyu.zhou@asu.edu]
> Sent: Tuesday, January 31, 2006 7:01 PM
> To: dipal-discuss@lists.oasis-open.org
> Subject: [dipal-discuss] all policies are non-functional?
>
> Dear all:
>
> Ever since I joined the list about 1 month ago, I have benefited a lot
> from
> the discussion here. Actually, I have spent much time on policy
research
> prior to join the list.
>
> What's interesting to me is the functional policy. In other words, the
> "Policy Engine" should have a "policy decision point" or a "policy
> monitor"
> to monitor the dynamically changing environment.
>
> So far, I have seen a lot of non-functional policies here. These
policies
> are mainly used to establish the agreement before two (Web Service)
> endpoints begin to interoperate with each other. However, not too many
> discussions about the functional policies have been proposed here. One
> week
> ago, Anne Anderson mentioned the paper "WS-Policy for Service
Monitoring",
> http://www.elet.polimi.it/upload/baresi/papers/TES2005.pdf
>
> This paper is interesting because the authors claim that they can do
both
> non-functional policy checking and functional policy checking. But,
the
> authors did not show us a functional policy checking as an example.
>
> In my opinion, the functional policy checking mainly relies on the
> capability of POLICY ENGINE. For example, I figure that the policy
engine
> of
> WS-Policy framework can only do text-level operation, because the
policy
> engine does not know about the semantic of the policy vocabulary.
Maybe
> all
> policy engines of domain-independent policy languages are not
powerful.
> That
> might be a trade-off.
>
> By the way, it would be highly appreciated if somebody can tell me
where I
> can find some materials about implementing policies on globus toolkit.
I
> have interests in this. I only see one project called gridshib
> http://gridshib.globus.org/
>
>
> Correct me if I wrong. I am not sure if it is appropriate to post my
> thoughts here.
>
> Regards, xinyu.
>
> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@sun.com]
> Sent: Monday, January 30, 2006 12:41 PM
> To: Frank McCabe
> Cc: dipal-discuss@lists.oasis-open.org
> Subject: Re: [dipal-discuss] How to move forward
>
> Francis,
>
> WS-PolicyConstraints
>
(http://research.sun.com/projects/xacml/ws-policy-constraints-current.pd
f)
> 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.
>
> Regards,
> Anne
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
dipal-discuss-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
dipal-discuss-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dipal-discuss-help@lists.oasis-open.org