Policy alternatives (Was : Clarify usage...)

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 Thursday, 26 October 2006 11:11:16 UTC