[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 forpreventing unwanted subscriptions
Tom Maguire wrote:No.In double opt-in the consumer knows about the subscriber, 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. 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.I believe it would just be the producer? 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).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 MEPstheNotification consumer exposes) given special treatment in this regard?Ido 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 12601David Hull<dmh@tibco.com>To11/22/2004 03:07 wsn@lists.oasis-open.orgPMccSubject[wsn] Use case for double opt-inand other mechanisms forpreventingunwanted subscriptionsThe Use Case: Because subscriptions may be made by a third party on behalf of theactualconsumer, 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 itsownbehalf. The subscriber, producer and consumer are all in the same isolated environment and implicitly trust each other. Again, there is noneedto restrict subscription. The consumer has supplied the subscriber with a secure token(whichthe 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 mightbeinterested in some unsolicited subscriptions. It is thus up totheproducer to determine interest, generally by sending a testmessageunder the double-opt-in pattern. Either of the previous cases may apply. The producer should lookforthe appropriate secure token, and if it's missing, ask theconsumervia double-opt-in. A notification producer may impose a quota on subscriptionsdirectedtoward a given consumer (perhaps because the consumer asked itto).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 bestbehandled through a callback mechanism, but we would probably rather not build this into the core subscribe exchange. In the case of securetokens,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"cookieand then use that cookie in the actual subscribe request. Naturally,thisis not the only way to cover these use cases.> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]