- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Mon, 6 Nov 2006 18:13:47 -0500
- To: ext Sergey Beryozkin <sergey.beryozkin@iona.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? 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:14:04 UTC