Perhaps a more complete answer is that WSN can and should
compose with WS-Security, and this will handle some cases. However,
it's not realistic or even feasible to require that all such
scenarios involve WS-security.
The usual (but not sole) justification for double opt-in is email.
There may well be value in a random consumer (in the commercial sense)
authorizing a bot to find interesting things to subscribe to. In this
case,
- The consumer signs up for a bot service on a secure web page. As
of this writing, that consumer can't be expected to have any
significant kind of security setup beyond being able to use HTTPS
through a browser.
- The bot goes off and looks for stuff to subscribe to. Ideally
before too long, at least some of this will be managed via WSN. That
is, the bot will find a NotificationProducer and set it a Subscribe
message with the consumer's email as consumer ERP.
- Even if the NotificationProducer only talks to trusted bots with
the right tokens, the consumer may not be interested in everything the
bot finds -- even if the consumer knows and trusts the producer. Nor
can the consumer lock down subscription up front: the whole point is
that the consumer does not know in advance what subscriptions it wants.
- It's also conceivable that an NP may not want to
restrict access to known subscribers (bot or not). It may want to get
as many subscriptions as possible and welcome all comers. This case is
particularly open to abuse, but must be supportable -- it already
exists, and is already kept under control through double-opt-in.
- In any case, double-opt-in allows the producer to find out
whether the consumer is interested before opening up the pipe.
In other words, full WS-Security will be too heavyweight for some
reasonable applications, both in the sense of requiring higher-powered
security tools and in the sense of requiring more security than desired.
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.
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.
|