- From: Anthony Nadalin <drsecure@us.ibm.com>
- Date: Wed, 28 Feb 2007 10:00:37 -0600
- To: <public-ws-policy@w3.org>
- Message-ID: <OF2DFFCB9C.C6CE3CC6-ON86257290.00575057-86257290.0057F2AF@us.ibm.com>
Is this really what we want ? How does one know what the choices are to enumerate ? There should be a way that one does not have to enumerate all choices as this could be a nightmare with all the alternatives that we have in security policy "Yalcinalp, Umit" <umit.yalcinalp@s ap.com> To Sent by: <public-ws-policy@w3.org> public-ws-policy- cc request@w3.org Subject Action 216 Proposal for Addition to 02/19/2007 07:00 Guidelines Document on Nested PM Policy Expressions Folks, The following text is my recommendation for the guidelines document for resolution of 4212/Action 216. This is proposed as an addendum to Section 4.4, preferably to Section 4.4.2. We may decide to update the defn of httpsToken to be nested (following the latest Ws-SecurityPolicy). Many thanks to Dan Roth who has reviewed and provided constructive changes to the text. Please do note that I have designed the example using our interop scenerios, Round 3. --umit --------------------------- Assertion authors should note the effect of nested policy expressions on policy intersection in their nested policy design. The result of intersecting an assertion that contains an empty nested policy expression with an assertion of the same type without a nested policy expression is that the assertions are not compatible. Therefore, when providers require dependent behaviors these behaviors should be explicitly specified as assertions in a nested policy expression. When the definition of an assertion allows for nested dependent behaviors, but the use of the assertion only contains an empty nested policy expression, this specific use indicates the specification of no nested dependent behaviors. This use must not be interpreted as being compatible with "any" of the nested dependent behaviors that are allowed by the assertion, unless otherwise specified by the assertion definition. As an example, WS-Security Policy defines sp:HttpToken assertion to contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a policy expression by a provider, it will indicate that none of the dependent behaviors namely authentication or client certificate is required. <sp:TransportToken> <wsp:Policy> <sp:HttpsToken> <wsp:Policy/> </sp:HttpsToken> </wsp:Policy>A non-anonymous client who requires authentication or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone. } [Issue 4212] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212 [Action 216] http://www.w3.org/2005/06/tracker/wspolicy/actions/216 ---------------------- Dr. Umit Yalcinalp Research Scientist SAP Labs, LLC Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 -------- "Nearly all men can stand adversity, but if you want to test a man's character, give him power." Abraham Lincoln. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Attachments
- image/gif attachment: pic13794.gif
- image/gif attachment: ecblank.gif
Received on Thursday, 1 March 2007 05:30:53 UTC