- From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
- Date: Wed, 28 Feb 2007 19:57:58 +0200
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: ext Maryann Hondo <mhondo@us.ibm.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
Frederick Hirsch wrote: > I'm confused. Doesn't > >> 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, > > this imply that since the assertions are in the vocabulary that none > are allowed since not stated, hence the following sentence is wrong? None of the nested assertions listed above are in the vocabulary of the policy that the proposal gives as an example. Only concrete occurrences of an assertion somewhere in the policy expression are part of that policy's vocabulary. >> it will indicate that none of the dependent behaviors namely >> authentication or client certificate is required. > > it will indicate that none of these are allowed or required? In the context of what I said above, I believe the original statement is correct. And note that the framework does not talk about allowed or required, it only states an indication that the assertion is not applied. Fabian > On Feb 28, 2007, at 11:50 AM, ext Maryann Hondo wrote: > >> >> Umit, >> (comments from Tony Nadalin who doesn't have internet >> access...paraphrased and sent by proxy by Maryann) >> >> It may be necessary to explore how does one find out all the >> alternatives that they have to enumerate or that there are >> alternatives. I can see issues both ways and not sure we have chosen >> the right path. This probably needs some more text to explain why >> security policy chose this way to express its policies, and I will >> try to write up some additional text for this. >> >> Maryann >> >> >> "Yalcinalp, Umit" <umit.yalcinalp@sap.com> >> Sent by: public-ws-policy-request@w3.org >> 02/19/2007 07:00 PM >> >> To >> <public-ws-policy@w3.org> >> cc >> Subject >> Action 216 Proposal for Addition to Guidelines Document on Nested >> 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> >> </sp:TransportToken> >> 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. >> >> >>
Received on Wednesday, 28 February 2007 17:58:09 UTC