W3C home > Mailing lists > Public > www-archive@w3.org > June 2003

Re: First attempt at characterizing policy in the architecture

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Fri, 13 Jun 2003 17:12:50 -0700
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, Philippe Le Hegaret <plh@w3.org>, www-archive@w3.org
To: Hugo Haas <hugo@w3.org>
Message-Id: <EF78387F-9DFC-11D7-8EF4-000393A3327C@fla.fujitsu.com>

Hi Hugo.

   I believe that my take on policy is a little different to your  
summary. Here is my go:


A policy has
   an identifier			// Silly question!
A policy is
   a constraint on the behavior of agents and/or services
A policy may be described
   in a machine readable form
policies may be enforced
   by a shared mechanism	(SEE BELOW)
A policy has
   an owner					// Key property ... since someone must enact the policy!
A policy is created by
   a policy enactment action

An agent/service may
   agree to a policy		// Key step
An agent/service may
   enact a policy for resources that it controls


There are two fundamental kinds of policies: permissive and obligatory

A permission is
   a policy
A permission enables
   a service or agent to perform an action, access a shared resource
A permission may be verified by
   a shared mechanism that controls access to a shared resource

An obligation is
   a policy
An obligation requires
   a service or agent to perform an action at some time
An obligation may be verified by
   a shared mechanism that audits the actions of agents and services

Obligations and permissions are related:

An obligation is not consistent if
   there is no corresponding permission

(This last could be much more formally expressed, but the essence  
should be clear)

Examples:

Permissions: to access a file, to create new policies.
Obligations: to inform partners of changes in policies.

Note: There is an entire logic devoted to this topic: Deontic Logic.


On Friday, June 13, 2003, at 04:54  AM, Hugo Haas wrote:

> Hi Frank, Chris, Philippe.
>
> I am sending this to you for a first set of comments before sending it
> to www-ws-arch because:
> - Frank has a good view of the concepts and relationships in our
>   document and has expressed interest in policies.
> - Philippe participated actively in the Properties and Features task
>   force where they discussed this.
> - Chris's name came up when Philippe and I talked with Francisco
>   Curbera in Budapest about aligning the abstract models for WSDL 1.2
>   and the work on policies.
>
> So, I thought I would take a stab at trying to express policies in
> terms of our concepts.
>
> The result is below. It may well be incomplete, which is why I wanted
> to get your early feedback before I send to the WSAWG list.
>
> 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.
>
> + Relationship to other elements
>
> policy
>   has an
>     identifier
>
> policy
>   leads to (I am not sure what relationship should go here...)
>     contract
>
> policy
>   may apply to a(n) (= put constraints on)
>     agent | legal entity | message | TBD:Service
>
> policy
>   has
>     one or more features
>
> + Description
>
> In a Web service interaction, each requester agent and provider agent
> has a set of capabilities and requirements. Those capabilities and
> requirements are expressed as features of the architecture.
>
> In order to interact, agents need to find a set of required features
> that they all implement.
>
> Policies are sets of features that are used to achieve such a result.
>
> 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 the party
> - 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]).
>
> + Open issues
>
> Relationship between description and policy. Is a description derived
> from the negotiation of a policy between agents or legal entities?
>
> This is relation to the Properties and Features Task Force task force
> work.
>
> ------>8----
>
> Note that "good enough to start discussion on www-ws-arch where I will
> send my comments" is a fine answer.
>
> Thanks.
>
> 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 Friday, 13 June 2003 20:14:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:31 GMT