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 5/25 ws-rx conf call


Prelim minutes 5/25 attached.

Please post any corrections to 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

May 25, 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 32 of 46 voting members, meeting is quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda    

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the May 18, 2006 meeting minutes

http://www.oasis-open.org/committees/download.php/18295/MinutesWSRX-051806.html

 

4) AI Review

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

 

5) New issues since last conf-call

Watch for Marc’s email

 

6) Review of changes due to i093

http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html

http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html

 

7) Issue Discussion:

a> i121 security threats and requirements

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

b> i122 security profiles

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

c> i124 security composition policy

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

d> i123 security profile agreement

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

e> i115 "must understand" attribute for extensions to RM components

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

8) Any other business

 

Marc G asked about issue 119.  Also 125 seems ready. 

 

Sanjay: Doug D is not on the call, but since 125 was not included I would put it at end.

 

Marc: could 115 be put before the security issues?

 

No objections to place 115 before security issues.

 

3         Approval of the 5/18 minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18243/MinutesWSRX-051106.html

 

Tom moved, Marc G seconded to approve 5/18 minutes.

 

§    No objection minutes for 5/18 meeting approved.

 

4         AI Review

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

 

#0100: Tom Rutt & Bob volunteered to work on state table revisions with Jacques

Owner: Jacques Durand

Status: Still Open

Assigned: 2006-05-09

Due: ---

 

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

 

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

Owner: Marc Goodner

Status: Still Open

Assigned: 2006-05-22

Due: ---

 

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

 

#0103: Paul F will address Marc G concerns and interop concerns in a next version of schedule, including the member ballot

Owner: Paul Fremantle

Status: Still Open

Assigned: 2006-05-22

Due: ---

5         New issues since last conf-call

none

 

6         Review of changes due to i093

http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html  

http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html  

 

Sanjay: there was considerable discussion on the list about this.

 

http://lists.oasis-open.org/archives/ws-rx/200605/msg00263.html

 

Doug B: There seems to be agreement on a small number of changes to satisfy Marc G.  I propose we accept Gils document with the small number of changes Marc G and I agreed on, and include this as our base document.

 

Anish: I have a preference for an alternative proposal that I sent.  It might be better to not use the MUST/MAY OPTIONAL keywords.  

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00266.html

I have an alternate proposal:

 

Replace the offending parts with assertions that do not contain any 2119

key words --

The cardinality of this [element|attribute] is [zero or more|one or

more|exactly one].

 

-Anish

 

Gil: I agree with Anish, we can use xml schema language for cardinalities, avoiding the rfc 2119 keywords.

 

Marc G: this is inconsistent with the rest of the document. It would suggest multiple changes elsewhere.  I prefer the proposal from myself and Doug.  The text that Doug and I propose continues to describe the elements themselves, without cardinality.

 

Anish: you can just get rid of existing improper 2119 terms, and replace with simple cardinality statements in English.

 

Doug B moved to accept proposal from Marc and himself, Marc Seconded.

 

Anish: speaks against it, since it states conformance constraints twice.

 

Doug B: in a particular change around wsrm:acksTo, the rfc 2119 language is about actions rm source must do and constraints on the type.  It is also about how the rm destination must respond.  They are not about cardinality.

 

Vote:

13  Yes

6  No

 

§    Motion passed to accept proposal from Marc and Doub F to close Issue 093.

 

Discussion on availability of Next working draft.

 

Gil: if we do not include issues we resolve today, we can be ready soon.

 

Sanjay: It should be ok to not include issues resolve on today’s call.

 

Marc G: the next wd will include all pending issues.

 

Bob F: also must include issue 93.

 

Gil: we should have one available by cob Tuesday.

 

Anish: do we have exact text for Issue 96.

 

Bob: issue 113 is based on an interim spec from Gil. 

 

Tom: those state tables came from an email from the Face to Face, from Matt.

 

Bob F: Jacques and I are eagerly awaiting a new draft which resolves closed issues, to insert clause numbers in the state table.

7         Issue Discussion:

 

7.1      I 115

 

Gil: an updated proposal from may 3 is at: http://lists.oasis-open.org/archives/ws-rx/200605/msg00025.html

 

Gil: if other side does not understand the extension, the sender must know that.  We need some inditcation.  This proposal defines a wsrm specific attribute, to be used at the top level (only) of an extension element, and we define a wsrm:mustunderstand Fault to use if the receiver does not understand that extension.  I added a statement that the attribute cannot be used below the top element.

 

Paul C: I am opposed to this.  Soap already has a must understand model, and having wsrm add this is not the way to go.  I would rather add a soap header which states there is an extension element being used, with a soap:mustUnderstand attribute.

 

Anish: I disagree that this is not independent of the soap processing model.  This wsrm:mustUnderstand attribute is checked after the soap model does what it does.

 

Gil: I have a problem with a new empty soap header, with a reference to an extension used in another place.  I think putting wsrm semantics into the soap processing layer is not valid.  It is semantically wrong to use soap must understand, since there is nothing wrong at the soap leve.  The processing is better done at the WSRM level.

 

Paul F: you could use a separate entity in a soap header.  There could be work around, but the general soap model allows the complex case.  Since I have not yet seen extensions proposed yet, I think this is something for version 2.  I prefer we defer this issue resolution to a future version of the spec.

 

Sanjay: I agree this should be deferred.

 

Doug B: (from chat) concretely: use a soap:mustUnderstand header which is handled using normal SOAP processing model, the given element's qname would be associated with semantics defined in the relevant WS-RM extension, the SOAP processor doesn't have to know the details of this extension just that a handler knows what to do

 

Marc G: I agree with Doug B proposal on chat.

 

Gil: with some of our security extensions, it would be better to not close sequence if the receiver does not understand a requirement needed by the requester for that sequence.  I do not want to tightly couple a general soap processing engine with the wsrm implementation.

 

Sanjay: we should defer this issue since we do not yet have extensions.

 

Umit: I would prefer this issue to be deferred to a later version of the spec.

 

Paul F: Gil stated the security composition profile might need such a mechanism.  Is this intended to be outside the spec.

 

Gil: I want that to be within this spec.

 

Paul F: then I think even more we should defer this.  Why build in features when we do not have a use case in the spec that needs them.

 

Gil: It is unfair to require extensions to already exist before we have such a mechanism.

 

Paul C: I would like to have it be clarified if Gil’s proposal for issue 123 requires this proposed solution.

 

Sanjay: I would like to wait to answer this question until after we discuss issue 123.

 

Sanjay: I propose we defer resolution of 115 until after we discuss the security related issues.

 

 

7.2      i121 security threats and requirements

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

 

Gil: we need to realize that the sequence is a shared resource which is being protected.   I need to make sure the sequence ack comes from the RMD which “owns” that sequence.  This needs to be explained.

 

Gil: the existing text also has unnecessary details.  I just got around to rewriting chaper 5. at: http://lists.oasis-open.org/archives/ws-rx/200605/msg00096.html

 

Gill review the threats which must be dealt with. 

 

Gil: sequence hijacking is not the same as a session identifier.

 

Gil: the text on message correlation threats (in 5.4)  might be better to remove altogether.

 

Paul F: I think this is basically a good rewrite, although I am not a security expert.  It uses terminology “integrity protected”, and it is not clear what this means.  Could that be added to a glossary?

 

Gil: I agree that should be added to a glossary.

 

Paul F: I think we could accept this proposal, with removal of 5.4.

 

Paul C: The 8 requirements in the proposal in 5.5, do not correlate back to the text on the 4 or 5 threats.  If I only want to worry about sequence hijacking, I do not know which of the items in 5.5 apply. 

 

Gil: That is a good point, not everyone is worried about every threat.  The relationship between the threats an security requirements needs to be clarified.  I would like to take an action item to come up with a new version which does that.

 

Ř  Action: Gill will clarify his proposal for i121 to clarify the relationship between requirements and the threats.

Doug D: I am not ready to make a final decision until we see the result of this action item.  I would like perhaps a straw poll on whether Gil should bother to carry out this action item to come up with a new proposal addressing the concerns raised on this call.

 

Sanjay: straw poll  Yes means continue to work, no means to not have Gill Bother to update the proposal.

 

No opposition to having Gil work on action item.

 

Paul C: he has threats, and requirements (solutions).  I would prefer to  have three sections, threats, potential countermeasures, and which countermeasure is used for each threat.  The WSI has a document which demonstrates this.

 

Gil : I agree with Paul C.

 

Sanjay: we should continue post questions to the mail list.

 

 

Gil: it might not be ready by next week call.  The earlier the better for any email to the list.  Two weeks is probable too long a time to wait.  It would be better to be done before the next meeting.

7.3      b> i122 security profiles

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

 

Gil reviewed his proposal posted as http://lists.oasis-open.org/archives/ws-rx/200605/msg00097.html

 

Gil: a profile does several things:

  • How rms and rmd authenticate each other when sequence is created.
  • For every message in sequence (traffic or control) how they know who sent the message or inserted the header.

 

Gil: I see three sets of profiles

  • Tls  and other authendication
  • Tls and tls authentication
  • Ws secure conversation.

 

Gil: there is different concerns about RMS authentication and AS authentication.  I would like other peoples opinion on this proposal.

 

Marc concern on web chat: I don't understand the TLS uris, aren't you already connected over TLS by the time you are signaling you are using it?

 

Marc: why does the RMS need to know whether the security applies to its code or the application’s code.

 

Gil: if RMD is a separate node, it must ensure the identity of AS flows to the AD.  It is necessary for composability.

 

Paul C: This proposal for 122 is used in solution for 123. 

 

Gil: the ability of two ends to know how to protect WSRM is important.  This can be done out of band.  123 is about the run time agreement for those profiles.  122 is just about coming up with a way for two people to agree on that they are using for wsrm.

 

Paul C: these profiles are collections of polices which and be used out of band.  Why not use ws-security policy.

 

Ran out of time.

 

Sanjay: continue to discuss security concerns on the list.

7.4      c> i124 security composition policy

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

no time to discuss

7.5      d> i123 security profile agreement

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

no time to discuss

 

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]