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

[Tom Maguire <tmaguire@us.ibm.com>]

In double opt-in the consumer knows about the subscriber, I believe it
would just be the producer?  Nevertheless how is this any different from
any other message exchange on the consumer?

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.
> >
> >
> >
>