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

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

> I can envisage a given endpoint allowing 
> little variability and publishing one or some small number of 
> policy alternatives.

So, shd we publish a set of sanctified or suggested policy profiles?

All the best, Ashok
 

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> Sent: Friday, May 26, 2006 12:26 PM
> To: Ashok Malhotra; 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
> 
> 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.
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>