W3C home > Mailing lists > Public > public-ws-policy@w3.org > February 2007

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

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 20 Feb 2007 14:11:41 -0500
Message-Id: <27EE24CF-D091-4C8B-8040-B853B7D92ACC@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>
To: "ext Yalcinalp, Umit" <umit.yalcinalp@sap.com>

(1) Would it be correct and clearer to replace

"it will indicate that none of the dependent behaviors namely  
authentication or client certificate is required"

with

"it indicated that none of the specified authentication mechanisms  
(sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and  
sp:RequireClientCertificate) are to be used, and will not be  
compatible with an assertion containing these nested assertions."

(2) Also, shall we change "This use must not be interpreted as being"  
to "By default, this use MUST NOT be interpreted as being"

(3) The meaning of the last sentence is not clear, since it isn't  
clear what it means to ignore incompatible policies and to proceed:

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

Perhaps we should replace this sentence with the following

"A client that requires authentication, as indicated by nested  
authentication assertions, will not be able to find a compatible  
assertion intersection with a provider that specifies an empty set of  
nested assertions. In this case the provider and/or client will need  
to offer alternatives to make a compatible set of assertions possible."

regards, Frederick

Frederick Hirsch
Nokia


On Feb 19, 2007, at 7:00 PM, ext Yalcinalp, Umit wrote:

>
> 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 Tuesday, 20 February 2007 19:12:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:47 GMT