- From: Hugo Haas <hugo@w3.org>
- Date: Thu, 19 Jun 2003 16:10:23 +0200
- To: Francis McCabe <fgm@fla.fujitsu.com>
- Cc: www-archive@w3.org
Hi Frank.
Following our IRC conversation yesterday, I have separated policy and
negotiation.
See below:
----------------------------------------------------------------------
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
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.
The features expressed in policies can be of different natures. Examples
are:
- Security: expressing requirements for an interaction to be considered
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. ]
There are two kinds of policies: permissive and obligatory. (see
below)
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
policy set used by the requester and provider (reference to
AR020.5[1]).
= 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 =
There may be some negotiation over policies. In order to interact and
have a service performed, agents need to agree on a common set of
required features.
What is the relationship between description and policy? Is a
description derived from the negotiation of a policy between agents or
legal entities?
What is the relationship between choreography and policy? Obligation
and permission can be seen as an ordering like one which would appear
in a choreography.
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
------>8----
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 Thursday, 19 June 2003 10:10:30 UTC