OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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 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]