|
From the
proposal:
Mandatory RM extension elements are presumed to somehow modify the
semantics of other RM Components. Therefore, for every mandatory RM extension
recieved by an RM node, the receiving node MUST either process the element or
not process the element at all, and instead generate a
wsrm:MustUnderstandFault.
Tagging RM extensions as mandatory thus assures that such modifications will not
be silently (and, presumably, erroneously) ignored by the RM nodes that recieve
the messages containing extended RM
Components.
-
gp
They
would be handled at the WS-RM layer, only whether or not they were understood
would be handled by the SOAP layer. The converse, and what you are seem to be
arguing for, is to push the mU semantics up into the WS-RM layer. That seems
more problematic to me. How much of the message now gets processed before you
find the mU indicating you shouldn’t have processed any of
it?
From: Gilbert Pilz
[mailto:Gilbert.Pilz@bea.com]
Sent: Thursday, May 25, 2006 3:23
PM
To: Christopher B Ferris; tom@coastin.com
Cc:
wsrx
Subject: RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf
call
This
means that you need to register every WS-RM must-understand extension with the
general SOAP processor. You're coupling your SOAP configuration (via the
Qname of the header that refers to the extension) to the internal details of
the messages (e.g. a particular extension to CloseSequence) that will be
carried within SOAP. Extensions to WS-RM-defined messages should be handled at
the WS-RM layer and not surfaced to the general SOAP
processor.
-
gp
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.
|