- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 20 Feb 2007 12:29:54 -0800
- To: "Frederick Hirsch" <frederick.hirsch@nokia.com>
- Cc: <public-ws-policy@w3.org>
> -----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