RE: [ws-rx] proposal for i122, i123, and i124

["Patil, Sanjay" <sanjay.patil@sap.com>]

+1 to Gil

> -----Original Message-----
> From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
> Sent: Thursday, Jun 08, 2006 16:47 PM
> To: Marc Goodner; Doug.Bunting@Sun.COM; Christopher B Ferris
> Cc: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] proposal for i122, i123, and i124
> 
> I agree wholeheartedly with (b). This is why I think that arguments
> along the lines of "can't we just let the WS-I handle this?" are a cop
> out. There are real issues around how the RMS and RMD identify their
> Sequence peers, how they identify the originator of any WS-RM-related
> messages, and how they agree on how they will do this. I can't see the
> WS-I creating the necessary infrastructure for making this 
> happen. If we
> provide them with a framework, *then* I can see them filling in the
> various bits that make up the nuts and bolts of a profile (to address
> Doug's point about crawling down the profile rat hole) but we have to
> give them something to work with.
> 
> - gp
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > Sent: Thursday, June 08, 2006 4:34 PM
> > To: Doug.Bunting@Sun.COM; Christopher B Ferris
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] proposal for i122, i123, and i124
> > 
> > The primary points I want to make with respect to this 
> > question are that
> > 
> > a) Our proposal here only enables security composition as the 
> > charter for this TC requires. I do not view it as a profile.
> > b) WS-I does not do original work, they only profile existing 
> > specs. So this proposal could not be done at WS-I.
> > 
> > -----Original Message-----
> > From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM]
> > Sent: Thursday, June 08, 2006 3:37 PM
> > To: Christopher B Ferris
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] proposal for i122, i123, and i124
> > 
> > Chris and others,
> > 
> > The question I raised near the end of this call was: One of 
> > the concerns raised with regard to Gil's i122 proposal was 
> > approximately "How does this profile development effort 
> > relate to the work which might happen in the new (and now 
> > publicly-known) Reliable Secure Profile WG[1] at WS-I?"
> > I'd like to ask the same question about this proposal.
> > 
> > MG: I can't speak to how the other proposal would fit there, 
> > this one I believe is complementary. It provides a mechanism 
> > whereby a token can explicitly be related to a RM session. 
> > Without that I think the WS-I RSP WG might have trouble 
> > fulfilling their charter to secure RM sessions using SC as 
> > they would not be able to define things like the assertion or 
> > the header below.
> > 
> > Put another way, should this TC close this issue (i122) or 
> > those issues
> > (i122-124) with no action in light of work happening elsewhere?
> > 
> > MG: I don't think so. This proposal corrects what we saw as a 
> > problem with the original proposal for 122 that 
> > authentication modes for HTTPS.
> > That was a good idea but needed to be done in general, not 
> > just for RM.
> > That is why I opened issue 75 in the SX TC to add 
> > authentication modes to the WS-SP HttpsToken assertion. What 
> > remains in our new proposal here speaks exclusively to RM and 
> > leaves security specific aspects, like token details or 
> > transport authentication modes, to that domain and composes 
> > with them which is what the charter asks us to do with 
> > respect to security.
> > 
> > Going down another level, is this really an alternative to Gil's
> > i122-123 proposals or an additional profile which might be 
> > folded into Gil's mix?  Though doing lots of profiles in this 
> > TC strikes me as a time suck and a significant change in our 
> > priorities, I would like to hear other perspectives.
> > 
> > MG: I think from the explanation above it should be clear 
> > that this is an alternative and not an additional profile. I 
> > don't view this proposal as a profile at all. I would see 
> > something like the WS-I RSP that choose a security mechanism 
> > to use with this, specifically SC, as a profile.
> > This simply enables composition, it does not dictate the specifics.
> > 
> > thanx,
> >     doug
> > 
> > [1]
> > 
> <http://www.ws-i.org/deliverables/workinggroup.aspx?wg=reliablesecure>
> > 
> > On 08/06/06 04:28, Christopher B Ferris wrote:
> > > All,
> > >
> > > IBM and Microsoft would like to submit the following proposal for 
> > > issues i122, i123 and i124 that defines the mechanism that 
> > MAY be used
> > 
> > > to secure an RM Sequence, the means by which the RMS can 
> be assured 
> > > that the RMD will correctly process the extension, and 
> the means by 
> > > which the RMD can advertise support for the extension.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Christopher Ferris
> > > STSM, Software Group Standards Strategy
> > > email: chrisfer@us.ibm.com
> > > blog: 
> http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > > phone: +1 508 377 9295
> > 
>