[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsn] Use case for double opt-in and other mechanisms for pre ventingunwanted subscriptions
Sanjay's first paragraph is a clearer explanation of my concern.
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
"Patil, Sanjay"
<sanjay.patil@sap
.com> To
"'David Hull'" <dmh@tibco.com>
11/22/2004 05:33 cc
PM wsn@lists.oasis-open.org
Subject
RE: [wsn] Use case for double
opt-in and other mechanisms for pre
venting unwanted subscriptions
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.
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.
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.
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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]