[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]