Re: First attempt at characterizing policy in the architecture

Hi Frank.

I did not get the following in your suggestion:

A policy
  is created by
    a policy enactment action

So I didn't include it in my attempt to merge our two visions. I am
still struggling to see if we actually are talking about the same
things or different ones. I think that they are complementary (hence
the merge).

Here is my proposed email to the WG. Let me know if this is good
enough to continue our conversation on www-ws-arch.

Regards,

Hugo

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

All,

There have been talks on several occasions about policies and how they
fit in the architecture, including me.

This topic has become particularly interesting with WSDL 1.2
describing SOAP 1.2's features and properties. The PNF task force has
shown relationships with works such as WS-Policy. In order for those
technologies to all build on the same model, we need to figure out
what policies are, what concepts they're building upon and how they
relate to service descriptions.

The terminology below is the one from:

  http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.27&content-type=text/html

------8<----

= Policy =

+ Summary

A policy exposes capabilities and requirements on an agent's behavior
constraining the interactions between agents, as well as permissions
resulting from those requirements.

+ Relationship to other elements

A policy
  has
    an identifier

A policy
  may be described in
    a machine readable form

A policy
  is a
    constraint on
      the behavior of
        agent | legal entity | TBD:Service

A policy
  has
    an owner

A policy
  leads to
    a contract

policy
  has references to
    a set of features

+ Description

In a Web service interaction, each requester agent and provider agent
has a set of capabilities and requirements.

These capabilities and requirements are expressed as features of the
architecture.

In order to interact, agents need to agree on a common set of required
features.

The features expressed in policies can be of different natures. Examples
are:
- Security: expressing requirements for an interaction to be considered
  as secure.
- Trust: expressing requirements for an agent to trust its peer.
- Privacy: expressing the intended usage of the data collected as a
  result of an interaction.
- Etc.

[ Note: put links to privacy and security sections above. ]

The examination of the parties' policies results in a contract for the
interaction. Should the processing of the request by the service be
delegated in part or completely, the delegation must respect the terms
of the contracts set with the requester (referring to AR020.5[1]).

There are two kinds of policies: permissive and obligatory.

= Permission =

A permission
  is
    a policy

A permission
  enables
    a service or agent
      to perform
        an action
      to access
        a shared resource

A permission
  may be verified by
    a shared mechanism
      that controls
        access to a shared resource

= Obligation =

An obligation
  is
    a policy

An obligation
  requires
    a service or agent
      to use
        a feature
      to perform
        an action

+ Open issues

Relationship between description and policy. Is a description derived
from the negotiation of a policy between agents or legal entities?

Relationship between choreography and policy? Obligation and
permission can be seen as an ordering like one which would appear in
a choreography.

------>8----

The following relationships also need to be documented:

An agent | legal entity | TBD:Service
  may agree to
    a policy

An agent | legal entity | TBD:Service
  may enact
    a policy

Regards,

Hugo

  1. http://www.w3.org/TR/2002/WD-wsa-reqs-20021114#AC020
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Tuesday, 17 June 2003 11:29:28 UTC