RE: RE: NEW ISSUE (3639) Which policy alternative was selected?

More specifically, there are two choices:

(a) Remove essentially the alternatives to exist. Assign a different
alternative to a different endpoint. So, a logical endpoint which would
normally have multiple  alternatives will essentially get deployed to
multiple endpoints with a single alternative assigned to each. In
essence, there is no alternative to disambiquate because the presence of
alternatives are removed. 

This is disambiguation by deployment not by runtime. 

(b) Additional protocol headers geared specific to WS-Policy assertion
selection are added (SOAP, etc.) so that in a message exchange these
additional headers disambiquate clearly which alternate is in effect.
 
This is disambiguation by runtime. 


There is no standard protocol headers(or I should say publicized
protocol) that handles (b). 

--umit



> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
> Sent: Wednesday, Oct 04, 2006 10:43 AM
> To: Fabian Ritzmann; public-ws-policy@w3.org
> Subject: RE: RE: NEW ISSUE (3639) Which policy alternative 
> was selected?
> 
> 
> Resending.
> 
> Daniel Roth
> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
> Sent: Thursday, September 28, 2006 8:54 AM
> To: Fabian Ritzmann; public-ws-policy@w3.org
> Subject: RE: NEW ISSUE (3639) Which policy alternative was selected?
> 
> 
> Hi Fabian,
> 
> Thanks for posting your example.
> 
> This is just another example of what we already discussed at 
> the F2F.  The policy combinators (All, ExactlyOne) are very 
> powerful and it is very easy to construct policies that have 
> no reasonable implementation.  When you use multiple policy 
> alternatives it may be ambiguous which policy alternative has 
> been applied.
> 
> There are multiple ways of disambiguating which policy 
> alternative is being used.  Publishing multiple endpoints is 
> one way (this is how we do it in WCF).  Another way is to add 
> another protocol to signal the selected alternative.  What 
> technique you use is implementation specific.
> 
> Daniel Roth
> 
> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Fabian Ritzmann
> Sent: Wednesday, September 27, 2006 4:33 AM
> To: public-ws-policy@w3.org
> Subject: Re: NEW ISSUE (3639) Which policy alternative was selected?
> 
> Here are security policy samples where the applicable policy 
> alternative
> can not be reliably determined from an incoming message. The WSDL with
> the policies is attached. This is in response to action item 115 that
> was assigned to Monica Martin.
> 
> For an incoming message the security layer infers the policy from the
> message. The inferred policy will then be compared against the list of
> available alternatives. A simple example, which attempts to show
> ambiguity in the policy to be selected.
> 
> In the attached example , we have a policy alternative at the binding
> level. Everything is the same except one assertion WSS10 and 
> WSS11.  If
> RequireSignatureConfirmation element under WSS11 assertion is set then
> SignatureConfirmation element must be sent back to the client. If the
> server happen to select the alternative which has WSS10 and Client had
> selected alternative with WSS11 assertion it be an error as the client
> would expect SignatureConfirmation element in the response 
> from the server.
> 
> Fabian
> 
> 
> 
>

Received on Wednesday, 4 October 2006 18:35:04 UTC