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: RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf call


But you are effectively *making* it care be requiring the higher-layer to register a unique SOAP header for every mU extension.

- gp 

> -----Original Message-----
> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
> Sent: Thursday, May 25, 2006 4:02 PM
> To: Gilbert Pilz
> Cc: Paul Fremantle; Christopher B Ferris; tom@coastin.com; wsrx
> Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
> 
> The SOAP processor doesn't have to care.
> 
> The point is it doesn't have to know any of that nesting / 
> detailed information, Gil.  The SOAP processor need only care 
> that the named mU header is understood.  "Understood" only 
> has meaning to the handler and could easily mean "I can grok 
> (random) extension foo in element bar when twiddle is false". 
>  Doesn't seem any different from registering the handler for 
> wsrm:CloseSequence in the first place from a SOAP processor 
> perspective.
> 
> thanx,
>     doug
> 
> On 25/05/06 15:55, Gilbert Pilz wrote:
> > When you register the WS-RM headers with the SOAP processor 
> you weren't saying anything about the contents of those 
> headers, only that the SOAP processor should accept them. By 
> surfacing the mU semantics of WS-RM extensions as SOAP 
> headers you are linking the implementation details of a 
> particular SOAP extension to your general SOAP processor.
> >
> > Also, I can't see how extending something like 
> CloseSequence is "extending SOAP" in any meaningful sense. An 
> extended CloseSequence and a non-extended CloseSequence both 
> live inside soap:Body. Why should the SOAP processor care 
> whether a child element of soap:Body has been extended (how 
> would it even know this was an extension w/out access to the 
> schema for that sub-element?) in some "semantically significant" way?
> >
> > - gp
> >
> >   
> >> -----Original Message-----
> >> From: Paul Fremantle [mailto:paul@wso2.com]
> >> Sent: Thursday, May 25, 2006 3:29 PM
> >> To: Gilbert Pilz
> >> Cc: Christopher B Ferris; tom@coastin.com; wsrx
> >> Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
> >>
> >> Gil
> >>
> >> RM already has to "register" headers with the SOAP processor. 
> >> In fact every SOAP header author does. Thats just what it takes to 
> >> write an extension to SOAP. Now you're suggesting that we create a 
> >> new mechanism with exactly the same model - in RM. Hmmm. 
> Its a nice 
> >> model, but I don't like it enough to want it twice.
> >>
> >> Paul
> >>
> >> Gilbert Pilz wrote:
> >>     
> >>> 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_ite
> >> m
> >>     
> >>> s.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#i
> >> 1
> >>     
> >>> 21
> >>>
> >>>     > b> i122 security profiles
> >>>     >
> >>>     
> >>>
> >>>       
> >> 
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> >> 1
> >>     
> >>> 22
> >>>
> >>>     > c> i124 security composition policy
> >>>     >
> >>>     
> >>>
> >>>       
> >> 
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> >> 1
> >>     
> >>> 24
> >>>
> >>>     > d> i123 security profile agreement
> >>>     >
> >>>     
> >>>
> >>>       
> >> 
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> >> 1
> >>     
> >>> 23
> >>>
> >>>     > e> i115 "must understand" attribute for extensions to
> >>>       
> >> RM components
> >>     
> >>>     >
> >>>     
> >>>
> >>>       
> >> 
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> >> 1
> >>     
> >>> 15
> >>>
> >>>     > 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_ite
> >> m
> >>     
> >>> s.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#i
> >> 1
> >>     
> >>> 21
> >>>
> >>>     >
> >>>     > 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#i
> >> 1
> >>     
> >>> 22
> >>>
> >>>     >
> >>>     > 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#i
> >> 1
> >>     
> >>> 24
> >>>
> >>>     > no time to discuss
> >>>     > 7.5 d> i123 security profile agreement
> >>>     >
> >>>     
> >>>
> >>>       
> >> 
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> >> 1
> >>     
> >>> 23
> >>>
> >>>     > 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.
> >>>
> >>>       
> >> --
> >>
> >> Paul Fremantle
> >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >>
> >> http://feeds.feedburner.com/bloglines/pzf
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >>
> >>     
> 


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