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

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

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