RE: [ws-sx] Issue 70: Clarify relationship between extensibility model and policy intersection

["Martin Gudgin" <mgudgin@microsoft.com>]

Ashok,

I'm not sure that a given services will support the myriad of options that would result in the combinatorial explosion you are worried about. I can envisage a given endpoint allowing little variability and publishing one or some small number of policy alternatives.

That said, I don't actually see the combinatorial explosion as being problematic. While a naïve implementation would, I suppose, do the full expansion to normal form of all policy alternatives and then perform n-squared matching, many opportunities exist for optimization.

Gudge


> -----Original Message-----
> From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
> Sent: 26 May 2006 16:04
> To: Martin Gudgin; Marc Goodner; Prateek Mishra; 
> ws-sx@lists.oasis-open.org
> Cc: ramana Turlapati
> Subject: RE: [ws-sx] Issue 70: Clarify relationship between 
> extensibility model and policy intersection
> 
> I understand this position.
> 
> The problem with it, though, is that it leads to a combinatoric
> explosion of alternatives.  Hal sent out mail with several option
> for username token.  If you also want encryption there are similarly
> many options for where the keys are obtained from etc.  If you want
> both username token and encryption the policy will need to encompass
> a very large number of alternatives.  You get the idea.
> 
> We need a better approach.
> 
> All the best, Ashok
>  
> 
> > -----Original Message-----
> > From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> > Sent: Friday, May 26, 2006 2:14 AM
> > To: Marc Goodner; Prateek Mishra; ws-sx@lists.oasis-open.org
> > Cc: ashok Malhotra; ramana Turlapati
> > Subject: RE: [ws-sx] Issue 70: Clarify relationship between 
> > extensibility model and policy intersection
> > 
> > I think we discussed this a little on the call, but my 
> > understanding is that the service would publish a policy 
> > along the lines of;
> > 
> > <sp:SupportingToken>
> >  <wsp:Policy>
> >   <sp:UserNameToken>
> >    <wsp:Policy>
> >     <orcl:IncludesPassword wsp:Optional='true' />
> >    </wsp:Policy>
> >   </sp:UserNameToken>
> >  </wsp:Policy>
> > <sp:SupportingToken>
> > 
> > which is effectively two policy alternatives, one with and 
> > one without the orcl:IncludesPassword assertion.
> > 
> > Gudge
> >  
> > 
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > Sent: 17 May 2006 14:56
> > > To: Prateek Mishra; ws-sx@lists.oasis-open.org
> > > Cc: ashok Malhotra; ramana Turlapati
> > > Subject: [ws-sx] Issue 70: Clarify relationship between 
> > extensibility 
> > > model and policy intersection
> > > 
> > > Recorded as issue 70.
> > > 
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/
> > > 
> > > -----Original Message-----
> > > From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
> > > Sent: Tuesday, May 16, 2006 6:50 AM
> > > To: ws-sx@lists.oasis-open.org
> > > Cc: Marc Goodner; ashok Malhotra; ramana Turlapati
> > > Subject: [ws-sx] NEW ISSUE: Clarify relationship between 
> > extensibility 
> > > model and policy intersection
> > > 
> > > *PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON 
> > THREAD UNTIL 
> > > THE ISSUE IS ASSIGNED A NUMBER.  *
> > > 
> > > *The issues coordinators will notify the list when that has 
> > occurred.*
> > > 
> > > * *
> > > 
> > > Protocol:   ws-sp
> > > 
> > > docs.oasis-open.org/ws-sx/200512/ws-securitypolicy
> > > 
> > > Artifact:   policy
> > > 
> > >  
> > > 
> > > Type:
> > > 
> > > design
> > > 
> > >  
> > > 
> > > Title:
> > > 
> > > Clarify relationship between extensibility model and policy 
> > > intersection
> > > 
> > >  
> > > 
> > > Description:
> > > 
> > > Section 11 of the WS-SecurityPolicy draft provides clear 
> > guidance on 
> > > extending existing  policy assertions  or  defining new ones.
> > > However, the policy assertion matching rules  (Section 
> 3.1.3) raise 
> > > some questions about the use of assertions with extensions, 
> > > specifically lines 364-365:
> > > 
> > > [quote]
> > > An assertion with an empty nested policy does not intersect 
> > with the 
> > > same assertion without nested policy.
> > > [quote]
> > > 
> > > If a server offered a service with policy expression:
> > > 
> > > 
> > > <sp:SupportingToken>
> > >   <wsp:Policy>
> > >       <sp:UserNameToken/>
> > > </wsp:Policy>
> > > <sp:SupportingToken>
> > > 
> > > <>
> > > 
> > >  and the client policy includes nested policy assertion <orcl: 
> > > IncludesPassword> as in:
> > > 
> > > <sp:SupportingToken>
> > >   <wsp:Policy>
> > >       <sp:UserNameToken>
> > >           <wsp:Policy><orcl:IncludesPassword></wsp:Password>
> > > </wsp:Policy>
> > > <sp:SupportingToken>
> > > 
> > > Then should not the two policy expressions match? As things 
> > stand, the 
> > > two expressions will not match even though the client is 
> > fully able to 
> > > satisfy the server's expectations.
> > > 
> > > 
> > > Related issues:
> > > 
> > >  
> > > 
> > > Proposed Resolution:
> > > 
> > > It seems to me there are two outcomes here:
> > > 
> > > (1) Retain current model but add text to Section 11 
> explaining the 
> > > relationship between extensibility amd matching. 
> Personally I find 
> > > this troubling, as it suggests that we will often have 
> > false negatives 
> > > during
> > > 
> > > policy matching.
> > > 
> > > (2) Extend the current model to accommodate a more refined 
> > notion of 
> > > policy matching. I can make a proposal but it may be better 
> > to first 
> > > get a sense of the TCs position on this issue.
> > > 
> > >  
> > > 
> > > 
> > > 
> > 
> > 
> 
>