From: Christopher B Ferris
[mailto:chrisfer@us.ibm.com]
Sent: Thursday, May 25, 2006 3:04 PM
To: tom@coastin.com
Cc: wsrx
Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
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.