Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call

[Christopher B Ferris <chrisfer@us.ibm.com>]

From below:
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

+1

I have tried to make this point repeatedly
in the past. The whole point of the SOAP header
with mU=true is just to test that the
extension is understood. Nothing more, nothing less. It need not
reference an explicit instance of the
extension. It is merely there to say: if the processor doesn't
know what to do with this extension,
DO NOT process this message.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Tom Rutt <tom@coastin.com> wrote on 05/25/2006
05:40:54 PM:

> 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
> 
> 
> 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 reviewcomments 
> 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 ofthe 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 areusing
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.