Re: Behaviour of WS-Policy aware clients

Fabian,

Yes I think the discussion needs to continue about capabilities.
And I think we did agree at the F2F to "beef up" the security 
considerations section, so hopefully the guidance
will be able to include references to the "cautions" in the spec as well.

Maryann



Fabian Ritzmann <Fabian.Ritzmann@Sun.COM> 
Sent by: Fabian.Ritzmann@Sun.COM
09/20/2006 09:36 AM

To
Maryann Hondo/Austin/IBM@IBMUS
cc
Sergey Beryozkin <sergey.beryozkin@iona.com>, public-ws-policy@w3.org
Subject
Re: Behaviour of WS-Policy aware clients






Maryann, your explanations make a lot of sense when a provider indicates 
a constraint as you were saying. But I'm missing a discussion of 
policies that indicate capabilities instead of constraints.

I believe you were already saying this, but one more thing that I think 
is important to keep in mind is that it is the responsibility of the 
entity that the policy is applied to to enforce that policy. In the 
common case of a provider with a policy and a requester that wants to 
interact with that provider, it is the responsibility of the provider to 
enforce its policy. The requester may send any message it likes, it just 
shouldn't expect a sensible response if these messages don't comply with 
the provider's policy. One should not forget that the requester may well 
be a hostile entity that sends invalid messages on purpose.


Fabian


Maryann Hondo wrote:
> Sergey,
> We're currently working on clarifying the text.
> In the interim, I'll give you my opinion.
> 
> First of all, the goal of policy is to have assertions define the 
> capabilities and constraints of an "entity" ( we are working on changing 

> "requestor" and "provider" to "entity" with an e.g, requestor/provider) 
to 
> enable interoperability of web services.
> 
> So, if a "provider" indicates a constraint ( let's assume its " all 
> messages to me must be signed") and you don't know what that means, then 

> chances are any attempt to send a message to the provider will fail.  If 

> you're really, really lucky, and you always sign all your messages maybe 

> you'll guess right on the algorithm and other metadata about signing, 
but 
> its kind of a long shot.
> 
> For 2, again, the idea here is if you are the "provider of a service" 
you 
> probably want people to get messages to you (othewise, why expose a 
> service?).
> If you support a whole bunch of options, but don't tell anyone about it, 

> chances are a few people may try, but if they try and fail, not many 
> people are going to keep trying to send you messages with every possible 

> alternative configuration.
> Maybe you have something that people can't live without and they're 
> willing to try, try again, but I find there's a point at which they will 

> move on to someone who is clear about their expectations thus increasing 

> their chance of success.The intent of web services is to enable 
> interoperability, if you want to hide why bother exposing your services?
> 
> In order to demonstrate interoperability there are some requirements:
> 
> A requester may choose any alternative since each is a valid 
configuration 
> for interaction with the service, but a requester MUST choose only a 
> single alternative for an interaction with a service since each 
represents 
> an alternative configuration.
> 
> If an assertion in the normal form of a policy expression contains a 
> nested policy expression, the nested policy expression MUST contain at 
> most one policy alternative 
> 
> but there is not currently normative text that I'm aware of that says "A 

> client MUST not send a message" because I'm not sure how anyone would 
> enforce this.
> 
> Maryann
> 
> 
> 
> 
> 
> "Sergey Beryozkin" <sergey.beryozkin@iona.com> 
> Sent by: public-ws-policy-request@w3.org
> 09/19/2006 12:29 PM
> 
> To
> "Sergey Beryozkin" <sergey.beryozkin@iona.com>, 
<public-ws-policy@w3.org>
> cc
> 
> Subject
> Behaviour of WS-Policy aware clients
> 
> 
> 
> 
> 
> 
> Hello
> 
> A couple of questions on the expected behaviour of a WS-Policy aware 
> client.
> 
> 1. Suppose we have a policy with a *single* alternative which a 
> policy-aware client can not support
> due to the fact it does not *recognize* its assertions (no intersection 
is 
> involved).
> Is it expected to fail ? Can it attempt to initiate a communication with 

> the provider ?
> 
> 1. Suppose we have a policy which a policy-aware client can not support
> due to the fact an intersection produced an empty set.
> Is it expected to fail ? Can it attempt to initiate a communication with 

> the provider ?
> 
> Thanks, Sergey Beryozkin
> Iona Technologies