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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] RE: Proposal for i029 "Remove dependency on WS-Security"


Inline <mg/>

-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Wednesday, August 31, 2005 10:34 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] RE: Proposal for i029 "Remove dependency on
WS-Security"

Sorry, but the working group decided that this is an issue. Let's not
spend time debating something we've already decided on.

<mg>Just because the TC accepted it as an issue does not mean that an
issue is within the scope of the charter. Remember we set a low bar for
accepting issues. Indeed debate on accepting this issue was cut short
specifically so that we could determine the charter scope issues
later.</mg>

Moving on to your excerpt from the charter; "Efficient preservation of
the integrity of reliable contexts by composition with WS-Security or
other SOAP security mechanisms." The "preservation of the integrity of
reliable contexts" part hints at certain threat(s) against the WS-RM
sequence. To date I have not seen anyone other than myself
(http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/20050
8/msg00206.html) present any descriptions of these threats. 

<mg>Read section 5 of the RM specification, particularly starting at
line 807.</mg>

I'm somewhat 
baffled as to why the proponents of linking the WS-RM and WS-Security
specifications together via an STR in the CreateSequence message haven't
explained why this is necessary (to be clear, when I say "explain" I
mean show us the threat model and describe to us how this counters the
threat). Given the current lack of information on this subject, it
appears that we are being asked to support a burdensome feature for no
real benefit.

<mg>Burdensome? How is an optional element burdensome? If a RMD and RMS
don't each support WSS when one of them requires it then they can't
connect. I see no reason to go to lowest common denominator and remove
security especially when the charter specifies that we address
this.</mg>

The "composition with WS-Security or other SOAP security mechanisms"
phrase is interesting. Given that there is no clear definition of what
it means to "compose" one WS-* specification with another this phrase
could mean almost anything. I take it to mean that we should provide
exemplars of how WS-Security should be used to bind the Sequence header
to the SOAP message body such that one cannot be separated from another.
This measure counters a specific threat that I would be glad to discuss
with you. 


<mg>Again, read section 5 of the RM spec where that is covered
explicitly.</mg>

I certainly don't read this phrase to mean that WS-RM must
support a per-message authorization check against an STR that is
provided during sequence creation.

<mg>You are proposing removing existing composability with WSS, how is
that consistent with the charter?</mg>

- g

________________________________

	From: Marc Goodner [mailto:mgoodner@microsoft.com] 
	Sent: Wednesday, August 31, 2005 5:51 PM
	To: Gilbert Pilz; ws-rx@lists.oasis-open.org
	Subject: Proposal for i029 "Remove dependency on WS-Security"
	
	

	This is not an issue. There is no reason we should remove the
STR and the charter of this TC is clear that this is in our scope. 

	 

	Proposal:

	The WS-RX TC charter is clear, "Efficient preservation of the
integrity of reliable contexts by composition with WS-Security or other
SOAP security mechanisms." The specification currently provides such
composition with WSS via the inclusion of the SecurityTokenReference in
the CreateSequenceRequest as well as providing an extensibility point
for other mechanisms. Removing this would be in direct conflict with the
related scope statement in the charter, therefore this issue should be
closed with no action.

	 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]