From: Patil, Sanjay
[mailto:sanjay.patil@sap.com]
Sent: August 7, 2006 7:04 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Issues for discussion
on the 8/10 conf-call
Let
us try to resolve the following issues that were accepted on the last call
(8/3). The Issues List hasn't been updated yet. So I have
also copied the full description of the issues below.
-- Sanjay
Proposed-01
- MsgNumRollover Fault is too restrictive
Proposed-03 - RMS and RMD should not both use same STR when sending
Proposed-04 - New section 6 wording too specific
Proposed-05 - Possible interop issue with WS-Addressing
------------------------------------------------------------------------------
Proposed-01
- MsgNumRollover Fault is too restrictive
Description:
After this week's f2f MsgNumRolloverFault now says that " The RM Source
MUST NOT send any new messages" upon receipt of this fault. I think this
is too restrictive. One possible recovery algorithm could be for the RMS to
negotiate with the RMD for a larger # for this sequence - and then continue to
use the sequence. This applies to cases where we didn't reach
9,223,372,036,854,775,807.
Proposal:
Remove this sentence.
Remove the "Rollover" column from the RMS state table since fixing
this would make this column the exact same as the "Created" one.
Proposed-03 - RMS and RMD should not both use same STR when sending
*Description*
The current WD[1] describes a single STR for use in both directions.
However, two systems should never share private keys or other asymmetric
security claims. Such sharing is unfortunately necessary for both to
demonstrate proof of possession of the same tokens.
When the
WS-RM protocol and a request / response MEP are used together for example, the
WSS[2] implementation at the recipient verifies claims
(tokens)
but does not use the same claims to secure the response.
*Justification*
Use of same STR for offered Sequence weakens the security of the WSS / WS-RM
solution. The current approach also introduces a special case for offered
Sequences where the two directions are otherwise closely aligned.
*Target*
core
*Type*
technical
*Proposal*
* Remove the clause "(and, if present, the offered)" where it
appears (twice) in lines 1270-1271.
* Duplicate lines 1266-1308, with appropriate (request -> response,
created -> offered) substitutions, to allow inclusion of an
<wsse:SecurityTokenReference> and <wsrm:UsesSequenceSTR> in the
Create Sequence Response message.
The addition above could introduce fault cases I (at least) don't know how to
handle: How to handle mustUnderstand faults a SOAP response causes? May be best
to limit use of an STR in the Create Sequence Response to those where the
Request message included a <wsrm:UsesSequenceSTR>. Not sure if the
<wsrm:UsesSequenceSTR> element would then be needed in the Create
Sequence Response.
*References*
[1] Latest WS-RM WD
<http://www.oasis-open.org/committees/download.php/19430/wsrm-1.1-spec-wd-15.pdf>
[2] WSS 1.1 core OS
<http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
Proposed-04
- New section 6 wording too specific
*Description*
The current WD[1] mentions (line 1272) "demonstrate proof-of-rights to the
referenced key" but "The <wsse:SecurityTokenReference> element
provides an extensible mechanism for referencing security tokens and other key
bearing elements." according to [2] (lines 829-830). Security tokens, in
turn, include any "claims" such as username / password pairs. The WD
wording is thus too specific.
*Justification*
Should support any WSS profile defined now or in the future. Therefore, should
word WS-RM as generally as WSS.
*Target*
core
*Type*
Editorial though the text appears normative
*Proposal*
change line 1272 to read "demonstrate proof-of-rights to the referenced
*claim*"
*References*
[1] Latest WS-RM WD
<http://www.oasis-open.org/committees/download.php/19430/wsrm-1.1-spec-wd-15.pdf>
[2] WSS 1.1 core OS
<http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
Proposed-05
- Possible interop issue with WS-Addressing
Description:
The
WS-Addressing WSDL wsaw:Anonymous element indicates whether or not the use of
the anonymous URI is optional, required or prohibited. This causes a problem
for MakeConnection since it doesn't use the WSA anonymous URI - instead it
defines it own. Which means that an endpoint compliant to WSA may reject a use
of the RM anon URI not because it doesn't support MakeConnection but rather
because the definition of this WSDL element doesn't allow for other specs to
define their own anon URIs.
Proposal:
The
RX TC, thru its connections with the WS-Addressing WG, should see if its
possible to modify the language of this element such that it doesn't tie itself
to just the one anonymous URI defined by WSA, rather phrase its requirements
more broadly, saying that this element indicates whether or not a URI referring
to the transport-specific back-channel is optional, required or forbidden. This
would allow for other specs to define their own anon-like URI (like RM did) but
still, in essence, mean the transport back-channel.