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

 

> -----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 11:43 AM
> To: Yalcinalp, Umit; Fabian Ritzmann; public-ws-policy@w3.org
> Subject: RE: RE: RE: NEW ISSUE (3639) Which policy 
> alternative was selected?
> 
> 
> > a logical endpoint which would normally have multiple 
> alternatives will
> > essentially get deployed to multiple endpoints with a 
> single alternative
> > assigned to each
> 
> You can still have multiple alternatives for a given 
> endpoint.  Those alternatives just need to be unambiguous.  
> For example, you can use a transaction header to figure out 
> if you are using an alternative that requires transactions.

Yes, you are right. I should have qualified the description. I should
have said that the alternatives are expressed in different endpoints if
the messages are not self describing to ensure that ambiguity does not
arise. 
 
> 
> Daniel Roth

--umit

> 
> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Wednesday, October 04, 2006 11:40 AM
> To: Daniel Roth; Fabian Ritzmann; public-ws-policy@w3.org
> Subject: 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 20:29:53 UTC