W3C home > Mailing lists > Public > public-ws-policy@w3.org > November 2006

Re: Policy alternatives (Was : Clarify usage...)

From: Sergey Beryozkin <sergey.beryozkin@iona.com>
Date: Tue, 7 Nov 2006 09:12:33 -0000
Message-ID: <011101c7024c$dc187970$3901020a@sberyoz>
To: "Frederick Hirsch" <frederick.hirsch@nokia.com>
Cc: "Hirsch Frederick" <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>

"If a provider specifies TLS in a policy alternative, doesn't choosing
that alternative mean that TLS will be used since the provider
requires it in that alternative?"

Has I suggested something different to what you said above ?

Cheers, Sergey

----- Original Message ----- 
From: "Frederick Hirsch" <frederick.hirsch@nokia.com>
To: "ext Sergey Beryozkin" <sergey.beryozkin@iona.com>
Cc: "Hirsch Frederick" <frederick.hirsch@nokia.com>; <public-ws-policy@w3.org>
Sent: Monday, November 06, 2006 11:13 PM
Subject: Re: Policy alternatives (Was : Clarify usage...)


If a provider specifies TLS in a policy alternative, doesn't choosing
that alternative mean that TLS will be used since the provider
requires it in that alternative?

Shouldn't understanding on the client's side must match requirements
on the provider side, when an alternative is chosen?

regards, Frederick

Frederick Hirsch
Nokia


On Oct 26, 2006, at 7:12 AM, ext Sergey Beryozkin wrote:

> Hi,
> If a client select an alternative it means that a client  understands all assertions/vocabulary within that alternative.
> If a client chooses an alternative which contains TLS it doest mean  that this client will be using TLS. It does not mean that 
> that a  provider does not uses WSS at the same time with a different  consumer. Irrespectively of the alternative chosen the 
> provider  retains the capability "being secure". The provider offers a choice  to different categoroes of requesters by providing 
> diff alternatives.
>
> Thanks, Sergey
>
>
> Sergey
>
> Is this what is meant by policy alternatives?
>
> For example, if one alternative uses message security and the other
> TLS, wouldn't a client expect the security mechanism outlined in the
> alternative to be used, and not the other?
>
> For example, what if the client does not support WSS, but does
> support TLS. Then wouldn't picking the alternative with TLS suggest
> not the use of WSS as offered in the other alternative?
>
> This seems different than what you mention in your message.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Oct 25, 2006, at 11:53 AM, ext Sergey Beryozkin wrote:
>
>> Hi
>>
>> I'd also like a primer clarifying and explaining what does it  mean,  from a requester's point of view, to work with different 
>> policy  alternatives.
>> For ex, at the moment, if we have a policy like this :
>> <wsp:Policy>
>>    <ExactlyOnce>
>>        <!-- alt1 -->
>>        <All>
>>           <foo/>
>>        </All>
>>        <!-- alt2 -->
>>        <All>
>>            <bar/>
>>        </All>
>>    </ExactlyOnce>
>> </wsp:Policy>
>>
>> then one interpretation can be that by selecting a first   alternative a requester is choosing to work with a provider which 
>> has no <bar/>.
>> The primer should explain that two alternatives are two different   policy micro-vocabulary instances and that, by choosing the 
>> alternative the requester just chooses the vocabulary it   understands/prefers.
>> From a provider's perspective,  a policy vocabulary is the one   which combines the vocabularies of all alternmatives. That is it 
>> supports all assertions, even if this assertion is not present in   the alternative chosen by a given requester.
>> For ex:
>> <wsp:Policy>
>>    <ExactlyOnce>
>>        <!-- alt1 -->
>>        <All>
>>           <sp:MessageSecurity/>
>>        </All>
>>        <!-- alt2 -->
>>        <All>
>>            <sp:TransportSecurity/>
>>        </All>
>>    </ExactlyOnce>
>> </wsp:Policy>
>>
>> Irrespectively of the alternative chosen the provider retains the   'being secure' capability. Likewise if we have two service 
>> endpoints, with one endpoint being annotated with a policy   alternative (service metadata) and the other one being not, the 
>> second endpoint still posesses the same capabilities as the first   endpoint, it's just thes capabilites will have to be 
>> discovered  out- of-band for the the second endpoint.
>>
>> Another example :
>>
>> <wsp:Policy>
>>    <ExactlyOnce>
>>        <!-- alt1 -->
>>        <All>
>>           <sp:MessageSecurity/>
>>        </All>
>>        <!-- alt2 -->
>>        <All>
>>            <sp:TransportSecurity/>
>>        </All>
>>        <!-- alt3 -->
>>        <All>
>>            <oasis:free/>
>>            <ExactlyOnce>
>>              <All>
>>                  <sp:MessageSecurity/>
>>              </All>
>>              <All>
>>                  <sp:TransportSecurity/>
>>              </All>
>>             </ExactlyOnce>
>>         </All>
>>    </ExactlyOnce>
>> </wsp:Policy>
>>
>> 3 vocabularies are presented. Irrespectively of the alternative/  vocabukary chosen, a service provider retains the capability of 
>> being free and secure.
>>
>> Thanks, Sergey
>>
>> Hi
>>
>> "Can you formulate your required example even in outline form?"
>>
>>
>> Example. A service has a capability to keep the clients' info   confidential. This capability has no behavioral requirements on 
>> the client and has no wire representations. It wishes to advertize  this  capability such that those requesters which understand 
>> what  it  means can use it during the intersection stage or as part of  a  search as a base for choosing this service among 
>> similar ones.
>>
>> Additionally, this service wishes to make itself available to  those  requesters which has no a priori knowledge of this 
>> assertion due to  the safe-to-ignore properties of this capability.
>>
>>
>> <wsp:Policy>
>>
>>    <wsp:ExactlyOnce>
>>
>>         <contoso:infoConfidential wsp:optional="true"/>
>>
>>    <wsp:ExactlyOnce>
>>
>> </wsp:Policy>
>>
>>
>> "I assume you want this text in the primer and/or guidelines  doc.   Is that correct?
>>
>>  If so can you offer proposed text?"
>>
>>
>> I'd like to see a clarification in the wsp:optional wording which   clearly states that wsp:optional is not optional for a 
>> provider  and  that wsp:optional is a hint to a requester that an assertion   identifies a requirement which is optional for a 
>> requester to do   something about it. In case of <contoso:infoConfidential   wsp:optional="true"/> it's a requirement to 
>> understand what  contoso:infoConfidential means.
>>
>>
>> I'd like to the terminology be updated such that a   <contoso:infoConfidential wsp:optional="true"/> does not turn  from  a 
>> capability in a compact form into a requirement in the  normal  form. Any assertion when looked from a provider's side is  a 
>> capability.  Any provider's assertion when looked from a   requester's side is a requirement on the requester (to understand 
>> it, to do something about it).
>>
>> If the group agrees with the above then I'd ask editors for help  in  presenting the text in a more readable way.
>>
>>
>> "Can you please clarify what you mean by “so that a policy author   can use wsp:optional as a recognized but not a workaround to 
>> mark   such assertions”? "
>>
>>
>> Thanks, Sergey
>>
>>
>> >1. Add an example to a primer and/or policy guidelines
>>
>>
>>
>> Can you formulate your required example even in outline form?
>>
>>
>>
>> >2. Explain why policy authors should make such assertions optional
>> for those requesters which are not aware of them.
>>
>>
>>
>> I assume you want this text in the primer and/or guidelines doc.    Is that correct?
>>
>>
>>
>> If so can you offer proposed text?
>>
>>
>>
>> > 3. Make any necessary changes to the wsp:optional related wording
>> so that a policy author can use wsp:optional as a recognized but   not a workaround way to mark such assertions.
>>
>>
>>
>> Can you please clarify what you mean by “so that a policy author   can use wsp:optional as a recognized but not a workaround to 
>> mark   such assertions”?
>>
>>
>>
>> Are you saying the Framework should warn policy assertion authors   from using wsp:optional to describe “assertions with no 
>> behavioural  requirements on the requester”?
>>
>>
>>
>> /paulc
>>
>> Paul Cotton, Microsoft Canada
>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>> Tel: (613) 225-5445 Fax: (425) 936-7329
>> mailto:Paul.Cotton@microsoft.com
>>
>>
>>
>>
>> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-  request@w3.org] On Behalf Of Sergey Beryozkin
>> Sent: October 6, 2006 6:27 AM
>> To: Sergey Beryozkin; public-ws-policy@w3.org
>> Subject: Re: NEW ISSUE :Clarify usage of assertions with no   behavioral requirements on the requeste
>>
>>
>>
>> Hello,
>>
>>
>>
>> This is the resolution I think would adequately address this issue :
>>
>>
>>
>> 1. Add an example to a primer and/or policy guidelines
>> 2. Explain why policy authors should make such assertions  optional  for those requesters which are not aware of them.
>> 3. Make any necessary changes to the wsp:optional related wording   so that a policy author can use wsp:optional as a recognized 
>> but   not a workaround way to mark such assertions.
>>
>>
>>
>> Thanks, Sergey
>>
>>
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789
>>
>> Target : WS-Policy Framework and policy guidelines
>>
>> Justification :
>>
>> There's a class of policy assertions which have no behavioral   requirements on the requester but can be still usefully processed 
>> by
>> requesters which are aware
>> of what assertions mean.
>> For example : <oasis:Replicatable/>
>>
>> An assertion like this one can be a useful source of information   for requesters. Providers having expected properties like
>> <oasis:Replicatable/> can be chosen/searched.
>> At the same time, given the fact assertions like  <oasis:Replicatable/>
>> have no behavioral requirements on the provider it's important to   ensure
>> policy-aware clients which have no knowledge of these assertions   can proceed
>> consuming the service advertsing this assertion.
>>
>> Currently the way to advertise such an assertion is to use a  normal  form with two policy alternatives(simple case), with only 
>> one
>> alternative containing this assertion thus making it optional,  or,  in other words, giving a chance to requesters to ignore it.
>> Such normal form expression is equivalent to a compact form with   the optional assertion marked with wsp:optional attribute with 
>> a
>> value 'true'.
>>
>> However, at the moment the primer recommends using wsp:optional   when one needs to mark asssertions which identify optional
>> capabilities/requirements with behavioral requirements on a   requester should the requester wishes to use it.
>>
>> Thus marking assertions like <oasis:Replicatable/> with   wsp:optional is considered to be a wrong approach.
>>
>> Proposal :
>>
>> Clarify the text describing the optionality in the policy   guidelines and in the Framework spec on how a policy author should 
>> use
>> assertions like
>> <oasis:Replicatable/>.
>> It's important that assertions like these can be usefully   interpreted by knowledgeble requesters and safely ignored by 
>> requesters
>> unaware of them.
>>
>>
>
Received on Tuesday, 7 November 2006 09:12:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:43 GMT