Re: Action 216 Proposal for Addition to Guidelines Document on Nested Policy Expressions

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?

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


regards, Frederick

Frederick Hirsch
Nokia


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:01:12 UTC