[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] proposal for i122, i123, and i124
+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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]