The policy oriented model, and capabilities and requirements

This email fulfills my action item from the face-to-face meeting:

  ACTION: Hugo to review our doc and propose how WS constraints and
  capabilities should be addressed in our doc. Due 17 October.

First, what are capabilities and requirements, and why do we need to
model them?

The Web and Web services being an extensible, distributed environment,
each service provider and requester supports a certain set of
features, and may require the use of another set of features.

In a Web services interaction, each party (service requester and
service provider) may wish to make or check assertions about its
capabilities or requirements. The purpose of these assertions is to be
able to match the capabilities of one party to the requirements of the
other party, and vice versa, to determine: (a) whether they are
compatible to interact; and (b) under what conditions would they be
compatible to interact.

Obviously, for two parties to interact, the requirements of one must
be capabilities of the other. Note that this is tightly related to
SOAP's extensibility model and the mustUnderstand attribute.

I believe that the 3 paragraphs above could be used as introductory
material for the policy oriented model.

A policy, as we define it, is[1] a "constraint on the behavior of
agents", which "may be described in a machine processable form". I
believe that we should be clearer and say that a policy is a set of
assertions defining capabilities and requirements of an agent, which
constrain the behavior of agents.

We define two types of policies: permissions and obligations. I am
going to go over each one of them.

Permission[2] is defined as "a kind of policy that relates to the
allowed actions and states of an agent and/or resource". This seems to
me a mix of choreography ("allowed actions and states" vs. "sequence
and conditions") and of declaration of capabilities by one agent to
the other. I believe that the former is covered by choreography, and
that policies need to cover the latter. If not, I think that we need
to clarify how the two concepts relate/differ. This is why I think
that permission should be renamed "Capability".  Also, I think that
"Capability" is an assertion part of a policy rather than a policy by
itself, changing the description to "an assertion that an agent
support a feature".

Similarly, an obligation[3] is defined as "a kind of policy that
relates to the required actions and states of an agent and/or
resource". I believe that the same comment as above applies here, and
that this should probably be renamed "Requirement", and that it also
an assertion rather than a policy, updating the description to "an
assertion that an agent requires the use of a feature".

I hope that this still is along the lines of what Frank had in mind.

Now, what do assertions apply to exactly? This isn't clear in our
current text.

We say:

  a policy may reference
    resources, actions and agents

Assertions can apply to a service, a service operation, a service
interface, and in the case of the requester, an agent, which I think
is useful to specify in order to understand their granularity. We
should add this relationship:

  a policy may apply to
    a service
  a policy may apply to
    a service operation
  a policy may apply to
    a service interface
  a policy may apply to
    an agent

I am wondering how putting constraints on a resource puts constraints
on the behavior of agents. I think that this is the targetResource
problem. I have the feeling the policy oriented model could be
simplified and not talk about resources, and that the relation between
agents and resources issues need to be dealt with in service oriented
model, the resource oriented model not answering this question.

Comments?

Regards,

Hugo

  1. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.72&content-type=text/html;%20charset=iso-8859-1#policy
  2. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.72&content-type=text/html;%20charset=iso-8859-1#permission
  3. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.72&content-type=text/html;%20charset=iso-8859-1#obligation
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/