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

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.