Re: [wsn] Use case for double opt-in and other mechanisms for preventing unwanted subscriptions

[David Hull <dmh@tibco.com>]

Patil, Sanjay wrote:

>  
> Hi David,
>  
> Just to be clear -  Are you proposing DOI as a solution for the 
> security concern of Consumer receiving unwanted Notifications. If yes, 
> then I am not sure how it will work. DOI in essence depends upon a 
> discipline followed by the NP to contact Consumer before bombarding 
> it with Notifications. A rouge NP may not heed such a discipline to 
> begin with.

DOI will not stop a rogue NP.  It's really aimed at protecting an honest 
NP from rogue Subscribers.  I think this is why I found Tom's questions 
confusing.  This is all centered around the Subscriber-NP interaction.  
It happens, though, that in some cases the NP will want to discuss the 
matter with the Consumer.  If the consumer doesn't know how to help with 
that, the NP may not be able to approve the subscription.

Let's drop back to current technology.  I register for some subscription 
service from a well-known commercial source, which I trust because it 
has some well-known company's name on it.  Before that well-known 
company starts pumping messages at me, it sends me a test message saying 
"did you really ask for this?".  I send back "yes", and we're off.  If 
someone else had spoofed being me, I would send back "no, sorry, doesn't 
ring a bell" and nothing further happens.

The main difference in the WSN case is that the subscription is done by 
a Subscriber using WSN, instead of ad-hoc registry through some web site.

>  
> On the the hand, DOI seems to be useful for a normal, non-security use 
> case such as - Provide an ability to the Consumer to accept/reject 
> notifications from a NP (for a particular Subscription). The 
> questions in that case will be - how does a Consumer know which NP 
> will provide DOI and which one not.

That's a good point.

In the WS-world, the /consumer/ would have to advertise an "approve 
subscription" request/reply.  Let me work through the original example 
with the two points above in mind.  The NP is taking the view that it 
won't send anything out unless it knows it's really wanted.  So it has 
an array of possible tools, for example:

    * Trust everything because it's a closed network.
    * Trust known subscribers using some form of authentication.
    * Convince itself that the subscriber /is/ the consumer.
    * Look for a certificate from the Subscriber that proves the
      consumer gave its OK (the NP has to have some knowledge of the
      consumer through some other channel).  Note that this is different
      from the Subscriber proving /its/ bona fides to the NP.  In fact,
      the subscriber might be someone off the street, as long as it has
      the right certificate.
    * If the consumer supports "approve subscription" (i.e., DOI), ask
      the consumer and only approve the subscription with the consumer's
      OK.  The NP doesn't have to trust the subscriber at all.
    * And if there is no way to know, fault.

 From a WSN spec point of view, we specify the "Approve Subscription" 
req/rep, and say that consumers MAY support it and NPs MAY use it.  NPs 
MAY also use less formal, existing means (specially formatted email or 
whatever).

The question then is how the subscriber would find out about failure.  A 
truly rogue subscriber doesn't need to be told anything (indeed, maybe 
shouldn't be told anything).  But a legit subscriber might well make an 
unwanted subscription without knowing it, and deserves to get a fault back.

>  
> By the way, the proposed solution for a currently logged issue 
> (WSN2.21: Consumer can not identify the subscription causing 
> notifications) might provide a partial solution here, except that the 
> WSN2.21 resolution depends upon useNotify option and it will require 
> at least one Notification message being sent to the Consumer.

I think this is a separate issue.  This is a case of the NP approving 
the subscription before any notify messages are sent.

>  
> Thanks,
> Sanajy
>
>     -----Original Message-----
>     *From:* David Hull [mailto:dmh@tibco.com]
>     *Sent:* Monday, Nov 22, 2004 13:53 PM
>     *Cc:* wsn@lists.oasis-open.org
>     *Subject:* Re: [wsn] Use case for double opt-in and other
>     mechanisms for preventing unwanted subscriptions
>
>     Thanks for the clarification.  I'm still not sure what other
>     message exchanges between NP and consumer there might be.  We only
>     define one, namely notify, and that only if useNotify is true.
>
>     I think the key point of WSN is its third-party nature.  The
>     Subscribe MEP between Subscriber and Producer contains a pointer
>     (EPR) to the Consumer, and the rest of the message flow happens
>     between Producer and Consumer.  Intuitively, this seems different
>     from a case where the Consumer makes a request to the Producer and
>     gets a response.
>
>     Does that apply to what you're saying?  I'm afraid we're going to
>     end up talking in circles around each other if we're not careful.
>
>     Tom Maguire wrote:
>
>>Forgive my tortured english in the last post clarification below.
>>
>>Problems cannot be solved at the same level of awareness that created
>>them.  -Albert Einstein
>>T o m   M a g u i r e
>>
>>STSM, On Demand Architecture
>>Poughkeepsie, NY  12601
>>
>>David Hull <dmh@tibco.com> wrote on 11/22/2004 04:20:07 PM:
>>
>>  
>>
>>>Tom Maguire wrote:
>>>
>>>
>>>
>>>In double opt-in the consumer knows about the subscriber,
>>>    
>>>
>> should have been two sentences; comma should have been a ?
>>
>>so it should have read
>>"In double opt-in the consumer knows about the subscriber?  I believe
>>the consumer would just know about the producer."
>>
>>  
>>
>>>No.
>>>    
>>>
>>agree
>>  
>>
>>>First, DOI is a message exchange between producer and consumer.  The
>>>subscriber is not involved at all.
>>>Second, in the typical use case, the consumer may or may not know
>>>the identity of the subscribing entity.  DOI applies in either case.
>>>I believe it
>>>would just be the producer?
>>>No.  Generally something other than the producer (or consumer) is
>>>making the subscription, and the producer has no way of knowing a
>>>priori whether the subscription is appropriate.
>>>Nevertheless how is this any different from
>>>any other message exchange on the consumer?
>>>
>>>I'm not sure what this means.  In the case I have in mind, the
>>>consumer is not a web service at all in the usual sense (yes, that
>>>is still covered by WSN).
>>>    
>>>
>>
>>What I meant was; why is the 'notify' message exchange being treate
>>differently
>>then any other message exchange between the producer and the consumer
>>w.r.t. auth?
>>
>>  
>>
>>>Tom
>>>
>>>Problems cannot be solved at the same level of awareness that created
>>>them.  -Albert Einstein
>>>T o m   M a g u i r e
>>>
>>>STSM, On Demand Architecture
>>>Poughkeepsie, NY  12601
>>>
>>>David Hull <dmh@tibco.com> wrote on 11/22/2004 03:47:29 PM:
>>>
>>>
>>>Tom Maguire wrote:
>>>
>>>
>>>
>>>Is it not sufficient that security assertions or claims about the sender
>>>handle this?  Why is the 'notify' MEP (as opposed to all the other MEPs
>>>
>>>the
>>>
>>>Notification consumer exposes) given special treatment in this regard?
>>>
>>>I
>>>
>>>do not understand why composition with WS-Security does not handle the
>>>requirement.
>>>
>>>
>>>
>>>What security assertions would handle the case where a consumer does not
>>>even know the subscriber exists?
>>>
>>>
>>>Tom
>>>
>>>Problems cannot be solved at the same level of awareness that created
>>>them.  -Albert Einstein
>>>T o m   M a g u i r e
>>>
>>>STSM, On Demand Architecture
>>>Poughkeepsie, NY  12601
>>>
>>>
>>>
>>>
>>>
>>>
>>>            David Hull
>>>
>>>
>>>
>>>            <dmh@tibco.com>
>>>
>>>
>>>
>>>To
>>>
>>>            11/22/2004 03:07          wsn@lists.oasis-open.org
>>>
>>>
>>>
>>>            PM
>>>
>>>cc
>>>
>>>
>>>
>>>Subject
>>>
>>>                                      [wsn] Use case for double opt-in
>>>
>>>
>>>
>>>                                      and other mechanisms for
>>>
>>>preventing
>>>
>>>                                      unwanted subscriptions
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>The Use Case:
>>>
>>>Because subscriptions may be made by a third party on behalf of the
>>>
>>>actual
>>>
>>>consumer, there must be some means of ensuring that the consumer only
>>>receives notifications it is interested in.  There are many possible
>>>relationships among the subscriber, producer and consumer.  For example
>>>     The subscriber is provably the same entity as the consumer.  The
>>>     producer should accept any subscription from the consumer on its
>>>
>>>own
>>>
>>>     behalf.
>>>     The subscriber, producer and consumer are all in the same isolated
>>>     environment and implicitly trust each other.  Again, there is no
>>>
>>>need
>>>
>>>     to restrict subscription.
>>>     The consumer has supplied the subscriber with a secure token
>>>
>>>(which
>>>
>>>     the NP is able to recognize) authorizing it to subscribe on the
>>>     consumer's behalf.  The NP should reject subscription requests
>>>     without proper authorization.
>>>     The consumer does not know the subscriber even exists, but might
>>>
>>>be
>>>
>>>     interested in some unsolicited subscriptions.  It is thus up to
>>>
>>>the
>>>
>>>     producer to determine interest, generally by sending a test
>>>
>>>message
>>>
>>>     under the double-opt-in pattern.
>>>     Either of the previous cases may apply.  The producer should look
>>>
>>>for
>>>
>>>     the appropriate secure token, and if it's missing, ask the
>>>
>>>consumer
>>>
>>>     via double-opt-in.
>>>     A notification producer may impose a quota on subscriptions
>>>
>>>directed
>>>
>>>     toward a given consumer (perhaps because the consumer asked it
>>>
>>>to).
>>>
>>>     In this case, a given subscription may either succeed or fail
>>>     depending on what other subscriptions are open.
>>>Clearly, many more variants are possible.
>>>Discussion:
>>>In cases where the producer must query the consumer before beginning the
>>>subscription, arbitrarily much time may pass between the subscription
>>>request and the definitive answer.  This asynchronous reply would best
>>>
>>>be
>>>
>>>handled through a callback mechanism, but we would probably rather not
>>>build this into the core subscribe exchange.  In the case of secure
>>>
>>>tokens,
>>>
>>>it might make sense for the subscriber to be able to submit and verify a
>>>token for a particular consumer once (in the context of a secure
>>>connection) instead of passing it with every subscribe request.
>>>
>>>It would be desirable to push all such message exchanges out of the core
>>>Subscribe request/response.  This is one driver behind having the
>>>subscriber and producer be able to first negotiate a "destination"
>>>
>>>cookie
>>>
>>>and then use that cookie in the actual subscribe request.  Naturally,
>>>
>>>this
>>>
>>>is not the only way to cover these use cases.
>>>
>>>
>>>
>>>
>>>>
>>>
>