[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [REV 2] WS-RX TC Weekly Meeting Minutes Aug 3rd 2006
|
From: Marc Goodner 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: 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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]