Re: Issue 7970

Wu,

The ability to implement what you refer to as "the common IP blocking 
implementation" cannot be a requirement of a SOAP-level spec; there are 
at least two layers of independence between WS-Eventing and IP. This is 
not to say that you cannot place such constraints on your own 
implementation, but you cannot ask the WS-RA WG to adopt them because 
they are not generally applicable.

- gp

On 10/26/2009 12:34 PM, Chou, Wu (Wu) wrote:
> Doug,
>  
> Please see the comments in line.
>  
> Thanks,
>  
> - Wu Chou.
>
> ------------------------------------------------------------------------
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Monday, October 26, 2009 10:51 AM
> *To:* Chou, Wu (Wu)
> *Cc:* Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org
> *Subject:* Re: Issue 7970
>
>
> Wu,
>   could you elaborate a bit on your thinking here.  If we went with 
> the 2nd option (which seemed to be preferred on the call):
>    A Web service that accepts requests to create subscriptions for
>   a certain set of notification that might be generated.
>
> what woud need to change in your implementation or what would break in 
> any existing implementation?  
>  
>  *<**Wu: The security and trusted event source will be affected and 
> break. Since the notification source is unknown,  the common IP 
> blocking implementation cannot be used to protect the event sink.  The 
> event subscriber cannot be sure if the event notification is from a 
> trusted endpoint . Moreover, the event subscriber cannot be sure if it 
> can receive event notification after a successful event subscription, 
> because if the notification  is from some unknown suspicious host not 
> permitted by firewall filter, it will be blocked by firewall.**>* 
>
>  <*Wu:  **In * *WS-E**, it describes a model that event source 
> indicates its event notification operations in its wsdl (or its 
> notification wsdl to be BP compliant). * *Not clear if it is 
> appropriate** **t**hat* *operations on the event 
> source endpoint wsdl are not its own operations but 
> operations **f**r**om* *some unknown* *endpoint.* *This change to the 
> fundamental concept of WS-E may take time to learn its full impact, 
> and we prefer not changing it.>* 
>
> Also, your point #3 actually might not be true.  If WS-Eventing 
> doesn't define an Event Source to allow for other components (anything 
> other than the _one_ event source) to send Notifications then an 
> extension spec can't do it either since it would be contradicting the 
> base spec.  
>
> *<Wu: It could work, since the base spec says the notification is from 
> the event source, and the extension spec says an event source can be a 
> proxy that forwards the event notification to the sink. From the 
> subscriber perspective, it is the bas**e* * spec, and from the event 
> source perspective, it allows an notification source to establish a 
> proxy relation and allow subscribers to subscribe events from its 
> proxy.  In short, an extension service can allow introducing 
> additional entities and in this case, an extended event sender does 
> not need to correspond to any concepts in WS-E.**>*
>
> As it currently stands we have an inconsistency in the spec - if Event 
> Sources are the only things that can send Notifications, then when we 
> use a pull-style model we're broken because in those cases the 
> Subscription Manager is the one that sends the Notifications.   
>
>  *<**Wu: No, in  ws-eventing, subscription manager and event source 
> can be the same endpoint. It should work for your case.** Allowing the 
> new changes as in the proposal may actually break a pull-model, as the 
> event sender can be some unknown thing other than the event source and 
> subscription manager. In this case, the event sink does not know where 
> to pull event from.**>* 
>
>  I don't think the above proposal would break anyone, nor even require 
> a coding change.  Rather its just an admission that our WS-* specs 
> only control what goes on the wire and we can't control what happens 
> behind the scenes.  How people choose to implement this stuff is up to 
> them.  For example, there is nothing inWS-Addressing that requires the 
> sender of an async response to be the same entity as the one that 
> received the request and this is no different.  Do we really need to 
> say that the entity that sends the SubscribeResponse MUST be the same 
> one the receives the SubscribeRequest?   
>
>  <*Wu: One difference is: in ws-eventing, the event source has 
> notification operations in its wsdl (or its notification wsdl) and the 
> subscriber subscribes to that service from that (event source) 
> endpoint.  I**t** is true that WS-A does not prohibit a reply comes 
> from somewhere other than the receiver, but the WS-A only specifies 
> how a receiver  formulates a reply message (WS-A core section 3.4). It 
> seems other use cases are extensions.**>* 
>
>  And what does "same one" mean?  In a clustered environment things get 
> a bit complicated.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *"Chou, Wu (Wu)" <wuchou@avaya.com>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 10/26/2009 10:23 AM
>
> 	
> To
> 	"Bob Freund" <bob.freund@hitachisoftware.com>, 
> <public-ws-resource-access@w3.org>, 
> <public-ws-resource-access-request@w3.org>
> cc
> 	"Li, Li (Li)" <lli5@avaya.com>
> Subject
> 	Issue 7970
>
>
>
> 	
>
>
>
>
>
> Bob,
>
> We see some problems with issue 7970 [1] and we share our thoughts below.
>
> 1) Current WS-Eventing is based on a set of well-defined web services 
> (source, sink, subscriber and subscription manager). If there is some 
> entity that interacts with WS-Eventing services, it should be either 
> defined in the spec, or it should be out of scope. This proposal 
> involves interactions with some entity whose behavior is not defined 
> in the spec.
>
> 2) By allowing an unknown third-party (instead of event source) to 
> send notifications to event sink complicates security checks against 
> attacks to the event sink. For example, IP blocking would not work 
> since the true notification senders are unknown, even after the 
> subscription.
>
> 3) Current WS-Eventing architecture can handle this use case by having 
> the event source forward notifications (from other senders) to the 
> sinks. Therefore, alternative approaches should be treated as extensions.
>
> Thanks,
>
> - Wu Chou/Li Li,
>
> [1] _http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970_
>
>
>  
>