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: Prelim minutes of 7/13 teleconf


Prelim minutes attached.

Due to the large number of ponts being raised by the various 
proponents,  I might have not captured some of the  points  properly.

Please review these minutes and provide corrections to the entire list 
before monday morning.

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Minutes of OASIS WS-RX Teleconference

Prelim Minutes of OASIS WS-RX Teleconference

July 13, 2006

 

Start Time:4:00 PM Eastern Daylight Time

 

Sanjay acted as chair.

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi:

 

Over 2x of 4x voting members, meeting is quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda:

Dial-in details (thanks to Novell):

US Toll Free: 1-888-791-6044

US Toll/International: 1-210-234-0004

Passcode: 15457

Mute/Unmute: *6

 

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

 

Agenda    

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the Jul 6th, 2006 meeting minutes

http://www.oasis-open.org/committees/download.php/19082/MinutesWSRX-070606.html

 

4) Sponsors for conf-call facilities for upcoming weeks

 

5) AI Review

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

 

6) New issues since last conf-call

Watch for Marc’s email

 

7) Issue Discussion:

a> i122 security profiles

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

b> i124 security composition policy

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

c> i123 security profile agreement

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

d> i139 Inappropriate Fault destination

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

e> i113 Tightening up the state tables

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

f> i147 Extensibility (or not) of the Protocol Elements

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

g> i140 add sub-headings to fault descriptions

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

h> i143 messages have to be received for them to be examined

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

i> i144 RMS MessageNumberRollover behavior unclear

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

j> i145 Implications of Sequence Expiration not specified

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

8) Any other business

 

Tom R: the differences in the two proposals are subtle.  We would like another week to consult with our security experts before there is a vote on i122-i123. 

 

Sanjay: we should spend time today, with time limit.  Give 60 minutes for the three issues.

3         Approval of the 7/6 minutes;

 

http://www.oasis-open.org/committees/download.php/19082/MinutesWSRX-070606.html

 

Tom moved, Paul K seconded to approve 7/6 minutes.

 

§    No objection minutes for 6/29 meeting approved.

 

4         Sponsors for conf-call facilities for upcoming weeks

 

Gill , BEA volunteered for a call.

 

Tibco , volunteered for a call.

 

Bob F , Hitachi, volunterred for a call.

 

Paul K, Nortel volunteered for a call.

 

 

 

5         AI Review

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

 

#0102: Marc G will prepare to start an issues list for Public review comments

Owner: Marc Goodner

Status: Open

Assigned: 2006-05-22

Due: ---

 

--------------------------------------------------------------------------------

 

#0106: Bob address polling in the state tables (once the first round of state table changes are stabilized)

Owner: Robert Freund

Status: still open,  Bob updated the non polling tables to use as a basis.

Assigned: 2006-07-03

Due: ---

 

--------------------------------------------------------------------------------

 

#0107: Bob and Anish to develop proposal for i140 resolution

Owner: Robert Freund

Status: Still Open

Assigned: 2006-07-03

Due: ---

 

--------------------------------------------------------------------------------

 

 

6         New issues since last conf-call

 

None.

7         Issue Discussion:

7.1      Security i122-124

a> i122 security profiles

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

 

b> i124 security composition policy

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

 

c> i123 security profile agreement

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

 

Sanjay: Two issues, from Microsoft, and Oracle/SAP have been proposed.  Gill added another for ssl which would work for either.

 

Gil: There are three proposals, Microsoft, with BEA amendment, and ORACLE /SAP, and Doug B to close with no action.   The difference is how the STA is bound to the sequence.  The differences have impact on which layers do the most work.

 

Sanjay: BEA amendment is applicable to both.

 

Tom: I have a compromise to standardize on the common feature of both proposals, but do not standardize how to bind the str to the sequence.

 

Sanjay: are there problems with using the ppt from SAP as a basis for discussion.

 

Marc G: I think this is an implementation level discussion which forwards a particular implementation approach.

 

Sanjay: I not Marc G objection, but we can proceed.

 

Anish: the proposals which have not be on earlier calls should warrant discussion.

 

Sanjay: we can start with the two proposals from Microsoft, and Oracle/SAP.

 

Gil: my proposal is applicable to both proposals.

 

Bob: I suggest the two major proposals followed by a vote.

 

Paul C: I think we can start with the new proposal first.

 

Marc G: the Gill proposal applies to both equally.

 

Sanjay: Oracle/Sap, then BEA, then Microsoft proposal, then SUN proposal.

 

Prateek: on the Oracle/SAP proposal. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00075.html  The core idea is to build on the WSS standard.  It uses the usage attribute of the str.

 

Tony (IBM): I am concerned with the assumption of security layer handoff.  This would require a total replacement of existing wss implementations to be made to work.

 

Tony: there is no way to ask the wss stack to hold that attribute during the session.

 

Martin R: While there may be some implementations that may be able to do that, but it is puzzling that an implementation would get rid of that attribute information.  Our implementation makes this available.

 

Tony: there is no requirement in WSS that it be able to hold any attribute that it may pass.  Maybe you should take that requirement back to the WSS.

 

Marc G: the most recent proposal took the str from the root of the wss header.  You have added requirements for wss to understand wsrm.

 

Martin R: a simple query to the wss layer would allow its implementation.

 

Marc G: I do not see the problem with putting the wss schema in the body of the create sequence, rather than requiring a query.

 

Anish: the only problem would be if a WSS implementation made a decision not to implement the usage attribute, or to not make it available to other layers in an api.

 

Chris F:: giving the RM layer xpath access to all headers in the security layer will not always be a reasonable approach.   Putting it in the xm layer in the Create Message is appropriate.

 

Tony: there are no requirements in wss spec that these attributes be saved, once they are processed for sending.  It may not be available for callback.  The ORACLE/SAP proposal assumes a particular implementation for the WSS stack.

 

Martin R: I would like to use the slide set for guide discussion.

 

Sanjay: is there objection to going thru slides.

 

Umit: I prefer to do that.

 

Marc G: I disagree on the level of implementation discussion for this issue. 

 

Chris F: I object to using those slides.  Has the proposal that ORACLE/SAP proposal been implemented and shown interop with another implementation.

 

Martin R: our proposal is based on implementations.

 

Prateek: usage attributes and working with them is part of our implementation. However ORACLE and SAP have not demonstrated interop in the context of WSRM.

 

Martin R:  presented slide set: http://lists.oasis-open.org/ws-rx/200607/msg00067.html

slide 1: abstraction between layers of oracle/sap proposal is cleaner.

 

Paul C: step 3 of the slide 2 giving description.  How does security layer know how to do that.

 

Martin R: there is policy in place stating that the createSequence must be signed. Any proposal would need to deal with that.

 

Martin R: query for the usage attribute should be an easy thing to do.

 

Prateek: if the usage attribute cannot be accessed, there is an error in WSS.

 

Paul C: the RM layer has to have access to complete soap envelope, to do xpath?

 

Martin R: you need security context corresponding to this uri.

 

Marc G: I understand the usage attribute for only with the WSS layer, and not available outside.

 

Marc G: question, in step 3 there is a signature to sign createSequence element.  I do not see that requirement in the actual text of the proposal.  The message example shows that, but it is not specifiec in the text that you have to sign the createSequence Element.

 

Martin R: both proposals need to be more explicit on that.

 

Marc G: in our proposal it is not specified, since the str is in the body of the message.

 

Prateek: this would be a consequence of a policy being available.  If the policy does not require signing, that is also allowed.

 

Gil: given the model of multiple rms nodes using a single sequence.  Each rms node authenticates individually.   Then all the RMS that share a sequence share another context.  The CreateSequence might be signed multiple times with different tokesn.  In the Oracle/Sap proposal how does the rms indicate to security layer which context is wishes to use to protect the sequence.

 

Prateek: I do not see how that can be avoided in any proposal.

 

Gil: if it is in the createSequence message it is unambiguous.  It is not obvious in the Oracle proposal step three which context is used to protect sequence.

 

Prateek: the rm layer give info to security layer to select token to use.

 

Gil: then you state this communication is out of scope of standard.

 

Prateek: you need to specify only as much as you must.  The More we hardwire does not further what we are trying to do.

 

Tony: external str has its own semantics outside wss spec.  There are other use cases.

 

Chris F: how does an existing wss stack recognize a createSequence body element, and know which token to use.  This implies wss has knowledge about wsrm.

 

Prateek: the wsrm does not have to be security aware.  It has no knowledge that we are processing a createSequence.  There are seven slides here, and we should consider them forward.

 

Doug B: we are running out of time.  The separation of contexts goes beyond our requirements as a tc. That was presented in my email http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00088.html .

 

Martin continued with presenting the rest of his slides.

 

Chris F from chat: The RM layer does NOT have to be a security processor... all it needs to do is say to the security layer: does the message carry proof of possession of this token (the one that was carried in the CS)

 

Discussion on the implementation of each proposal ensued.

 

From Chat:

chris: I'm going to repeat my point that the RM layer need not implement ANY STR "processing" what-so-ever that is left to the WSS layer

Gil: I would hope the WSS layer knows how to handle STR's (in all their admitted complexity)

 

 

Marc G: we have had interop on the Microsoft Proposal.

 

Jeff M: the proof of interop is whether someone can read spec, implement it and interop with other implementation of spec.  One needs to look at implications of implementing a specific architecture.

 

Marc G: With regard to simplicity, the ORACLE proposal just moves the str to header.  In our proposal we are using a pattern in WS-SX.  I suggest they get their proposal adopted in a TC relevant to Security.

 

Martin R: Secure conversation is emerging within the next year or so.   This is one possible solution to do that.  There are issues around this pattern in the WS-SX TC at this time.

 

 

7.2      Issues not discussed due to lack of time

d> i139 Inappropriate Fault destination

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

 

e> i113 Tightening up the state tables

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

 

f> i147 Extensibility (or not) of the Protocol Elements

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

 

g> i140 add sub-headings to fault descriptions

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

 

h> i143 messages have to be received for them to be examined

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

 

i> i144 RMS MessageNumberRollover behavior unclear

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

 

j> i145 Implications of Sequence Expiration not specified

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

 

8         Any other business

none

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


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