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

 

> -----Original Message-----
> From: Fabian.Ritzmann@Sun.COM [mailto:Fabian.Ritzmann@Sun.COM] 
> Sent: Wednesday, Feb 28, 2007 9:58 AM
> To: Frederick Hirsch
> Cc: ext Maryann Hondo; Yalcinalp, Umit; 
> public-ws-policy@w3.org; public-ws-policy-request@w3.org
> Subject: Re: Action 216 Proposal for Addition to Guidelines 
> Document on Nested Policy Expressions
> 
> Frederick Hirsch wrote:
> > I'm confused. Doesn't
> >
> >> 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,
> >
> > this imply that since the assertions are in the vocabulary 
> that none 
> > are allowed since not stated, hence the following sentence is wrong?
> 
> None of the nested assertions listed above are in the 
> vocabulary of the 
> policy that the proposal gives as an example. Only concrete 
> occurrences 
> of an assertion somewhere in the policy expression are part of that 
> policy's vocabulary.

This is interesting. 


> 
> >> it will indicate that none of the dependent behaviors namely 
> >> authentication or client certificate is required.
> >
> > it will indicate that none of these are allowed or required?
> 
> In the context of what I said above, I believe the original 
> statement is 
> correct. And note that the framework does not talk about allowed or 
> required, it only states an indication that the assertion is 
> not applied.
> 
> Fabian

Is there a difference of opinion about what constitutes the vocabulary
of an assertion based on type vs instance ? 

We recommend assertions to have a schema and state dependent behaviors
as expressed as nested assertions. From a definition perspective, it is
not about the "instance" as expressed in a document, it is a about the
"type" of the assertion which lists all the dependent assertions. The
type, hence the Qname in advance declares what it is composed of. 

I have regarded that understanding a type would also imply understanding
all possible nested children (close world model) which is not based on a
specific policy expression instance. 


Am I missing sth? 



> 
> 
> > On Feb 28, 2007, at 11:50 AM, ext Maryann Hondo wrote:
> >
> >>
> >> 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.
> >>
> >>
> >>
> 
>

Received on Thursday, 1 March 2007 01:53:41 UTC