[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 70: Clarify relationship between extensibilitymodel and policy intersection
> 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]