[REV 2] WS-RX TC Weekly Meeting Minutes Aug 3rd 2006

[REV
2] Corrected issue numbering, should have started from 151, not 149. Lack of
resolution to discussion of 151 (previously 149) captured. Added issue
description for 155 (previously 153).

 

From: Marc Goodner 

Sent: Thursday, August 03, 2006 3:11 PM

To: [WS-RX]

Cc: 'Paul Fremantle'; 'Patil, Sanjay'

Subject: Prelim WS-RX TC Weekly Meeting Minutes Aug 3rd 2006

 

WS-RX TC Weekly Meeting Minutes

 

Date:  Thursday, 03 August 2006

Time:  01:00pm - 02:30pm PT

 

Event Description:

Dial-in: Thanks to BEA

IRC/Q Mgmt(thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx

 

Agenda:

1) Roll Call

TBD

 

2) Allocation of a minute taker

Marc Goodner volunteered 

 

3) Review and approval of the agenda

Approved.

 

4) Approval of the July 27th meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00184.html

Approved with unanimous consent.

 

5) a) Discussion of the PR schedule (see Sanjay's note) 

 

8/3 – End of conf-call: Cut-off time for resolved issues
that will go into the PR

8/4 - Editors produce a candidate PR draft (version 1). 

8/10 -TC review begins conf-call: TC review of PR
candidate draft (version 1) ends. Disposition of the received comments is
decided on the conf-call

8/11 - Editors produce a new PR candidate draft (version
2)

8/17 - Ballot is conducted on the conf-call to decide
whether the PR candidate draft version 2 should be submitted for public review.

 

Votes will be held on the TC call.

 

Above schedule accepted by TC.

 

 

   b) Update from editors

 

Editors find the above schedule acceptable.

Editors request TC send in editorial comments ASAP,
preferably today.

   

6) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php.

 

PR Issue list.

In progress.

 

State tables, should have been closed.

 

I140 should have been closed.

 

I145 should have been closed.

 

7) New issues since last conf-call

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. 

Accepted as i151.

 

Proposed-02 - Editorial issues with the latest editor's
draft

Log Question on wsaw:Action at end of this list as new
issue i150.

 

Comments on the wsdl file:

This should be pulling in the new WS-A WSDL namespace,
and replace 

wsa:Action with wsaw:Action. That might mean a second
update to the 

namespaces table at the start of the spec. Perhaps we are
waiting for 

this to become a reccomendation?

 

Accepted as i152.

 

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

 

Accepted as i153.

 

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

 

 

Accepted as i154.

 

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.

 

Accepted as i155.

 

8) Issue Discussion: 

 

i146 Need Fault to indicate security constraints have
been violated

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i146

 

New proposal:

 

 

Proposed fault is needed to report that the security is
not correct, could be very helpful in debugging situations.

 

Some concerns expressed that this fault is not needed.

 

Concern that this proposal has an implicit requirement to
use the exact token from the STR, could impact use of derived keys. Proposed
modification to address:

Change proposed text for 6.1 to: Once the association
between a Sequence and a secret has been established, the receipt of any
message using that Sequence and not properly demonstrating knowledge of, or
rights to, the secret MAY be signaled by the RM Source or RM Destination via
the wsrm:SecurityViolation exception. This specification does not mandate that
this fault be returned to the sending party as this could be used as part of a
denial of service attack.

 

Concerns over information disclosure in using this fault,
no impact on receiver, it is an implementation detail.

 

Motion to close with no action, from Chris Ferris,
seconded by Matt Lovett

No objections.

 

i151 - 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.

 

Motion to accept proposal by Chris Ferris, seconded by
Stefan Batres

Discussion of error conditions related to this fault,
renegotiation for new sequences.

Text was added as part of issue 140 on faults.

Motion failed.

 

i152 - Question on
wsaw:Action

Comments on the wsdl file:

This should be pulling in the new WS-A WSDL namespace,
and replace 

wsa:Action with wsaw:Action. That might mean a second
update to the 

namespaces table at the start of the spec. Perhaps we are
waiting for 

this to become a reccomendation?

 

Concern over impact of namespace between CR and REC

Plan to keep namespace stable

No issues logged against spec right now

Concern over syntactic changes that would happen between
CR and REC

 

Motion to replace wsa:Action with wsaw:Action using the
CR namespace, add wsaw to namespace table.

Reopen issue if namespace changes between CR and REC.

Made by Chris Ferris, seconded by Matt Lovett.

No objections.

 

i153 - RMS and RMD
should not both use same STR when sending

not discussed

 

i154 - New section 6
wording too specific

not discussed

 

i155 - Possible
interop issue with WS-Addressing

not discussed

 

9) Interop schedule and next steps

8/4 Candidate PR

8/10 Call, review PR1, decide on actions

8/11 - Editors produce a new PR candidate draft (version
2)

8/17 conf-call:  Ballot to accept PR draft 2 as CD4,
Ballot to accept CD4 as PR

8/21 PR begins

9/11 Interop2 scenarios ready

9/25 Start interop

10/2 Virtual interop day 1

10/3 Virtual interop day 2

10/6 End interop

10/20 PR ends

 

Dug, Eric, Matt and Stefan checking their availability to
work on interop scenarios.

Suggestions to add security, make connection and more
“real world” scenarios.

Counter suggestion made for the mimum required to declare
victory approach.

No objections to covering security, make connection, and
both in combination in this round.

 

 

10) AOB

 

OASIS Kavi web interface for TC mail list works. Sending
directly to list is still broken.

http://www.oasis-open.org/apps/org/workgroup/ws-rx/mail_to_wg.php