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