RE: [ws-rx] Issues for discussion on the 8/10 conf-call

Title: Issues for discussion on the 8/10 conf-call

 

We should. I was planning to reflect that in the agenda 
(which I send out on Wed).

 

-- Sanjay

  

  
  From: Paul Cotton 
  [mailto:] 
Sent: Tuesday, Aug 08, 2006 
  12:38 PM
To: Patil, Sanjay; 
  
Subject: RE: [ws-rx] Issues for 
  discussion on the 8/10 conf-call

  

  

  
Shouldn’t we give 
  higher priority to TC member comments on the candidate CD4 documents during 
  this week’s meeting?

  
 

  
/paulc

  
 

  

  
Paul Cotton, Microsoft 
  Canada
17 Eleanor Drive, Ottawa, Ontario 
  K2E 6A3
Tel: (613) 
  225-5445 Fax: (425) 936-7329
mailto:

  

  

  

  
  

  
From: Patil, 
  Sanjay [mailto:] 
Sent: August 7, 2006 7:04 PM
To: 
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.