W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

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

From: Daniel Roth <Daniel.Roth@microsoft.com>
Date: Thu, 28 Sep 2006 08:53:44 -0700
To: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <E2903CF1E4B5B144B559237FDFB291CE10E46EC5@NA-EXMSG-C117.redmond.corp.microsoft.com>

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.

Received on Thursday, 28 September 2006 15:53:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:15 UTC