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

> 1.  If you have multiple endpoints, how do you indicate which alternative
> each endpoint supports?
Each endpoint has its own policy.  An endpoint can have multiple alternatives as long as the alternatives are not ambiguous.  For example, in WCF we constrain the bindings that you can configure for an endpoint so that the corresponding alternatives are never ambiguous.  We have found that this is a simple and interoperable way to solve the problem.

> 2.  Is the other protocol you suggest something that the WS-Policy WG
> would endorse?
As we discussed at the F2F, I think implementers are free to add whatever protocol they want using the standard policy extension mechanism.  If your implementation requires additional protocol on the wire, then that protocol should be described by a policy assertion.  However, each new protocol comes with a cost which seems unnecessary when you can just expose another endpoint.

Daniel Roth

-----Original Message-----
From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Thursday, September 28, 2006 9:18 AM
To: Daniel Roth; Fabian Ritzmann; public-ws-policy@w3.org
Subject: RE: NEW ISSUE (3639) Which policy alternative was selected?

Dan:
You said ...

> 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.

Two questions:
1.  If you have multiple endpoints, how do you indicate which alternative each
endpoint supports?
2.  Is the other protocol you suggest something that the WS-Policy WG would endorse?

All the best, Ashok


> -----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 Thursday, 28 September 2006 17:22:23 UTC