[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 70: Clarify relationship between extensibility model and policy intersection
The solution space mirrors the problem space. I expect that during interop we will define and publish various policies. But I don't expect that these will be any kind of exhaustive set. Nor do I expect a significant percentage of services "in the wild" to use those policies verbatim. Some may, but many more will use policies that differ to a greater or lesser extent from those which we publish during interop testing. Gudge > -----Original Message----- > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] > Sent: 30 May 2006 14:29 > 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 > > The solution space is very wide and technically challenging. > It would be a service to our user to prioritize it and/or provide > a few cookbook solutions. > > All the best, Ashok > > > > -----Original Message----- > > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > > Sent: Sunday, May 28, 2006 4:27 AM > > 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 > > > > > > > > > -----Original Message----- > > > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] > > > Sent: 26 May 2006 20:51 > > > 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 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? > > > > Why? I wasn't saying that the set of all possible profiles > > was small, but that the set of profiles published by a given > > endpoint might be. > > > > Gudge > > > > > > > > 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]