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

 

> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
> Sent: Tuesday, Feb 20, 2007 11:12 AM
> To: Yalcinalp, Umit
> Cc: Frederick Hirsch; public-ws-policy@w3.org
> Subject: Re: Action 216 Proposal for Addition to Guidelines 
> Document on Nested Policy Expressions
> 
> (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."
> 

I am fine with this change. 

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

This reminds me of a discussion with Monica. I am surprised she did not
respond to this. 
I am not sure whether the Guideline document can be positioned to be a
normative specification. 
Thus, I avoided the use of MUST. 

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

The intent of the sentence is to indicate that intersection algorithm is
a first approximation. Thus, if domain specific processing were
involved, the result could be different. 

> 
> 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 20:27:58 UTC