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

I agree with Frederick.  If a client selects an alternative that
includes TLS he is committing to use TLS.  Otherwise, why is he
selecting that alternative?

All the best, Ashok
 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Monday, November 06, 2006 3:14 PM
> To: ext Sergey Beryozkin
> Cc: Hirsch Frederick; public-ws-policy@w3.org
> 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 Monday, 6 November 2006 23:27:02 UTC