[no subject]

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 <a class="moz-txt-link-rfc2396E" href="mailto:dmh@tibco.com";>&lt;dmh@tibco.com&gt;</a> wrote on 11/22/2004 04:20:07 PM:

  </pre>
      <blockquote type="cite">
        <pre wrap="">Tom Maguire wrote:



In double opt-in the consumer knows about the subscriber,
    </pre>
      </blockquote>
      <pre wrap=""><!----> 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."

  </pre>
      <blockquote type="cite">
        <pre wrap="">No.
    </pre>
      </blockquote>
      <pre wrap=""><!---->agree
  </pre>
      <blockquote type="cite">
        <pre wrap="">First, DOI is a message exchange between producer and consumer.&nbsp; 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.&nbsp; DOI applies in either case.
I believe it
would just be the producer?
No.&nbsp; 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.&nbsp; 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).
    </pre>
      </blockquote>
      <pre wrap=""><!---->
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?

  </pre>
      <blockquote type="cite">
        <pre wrap="">Tom

Problems cannot be solved at the same level of awareness that created
them.&nbsp; -Albert Einstein
T o m&nbsp;&nbsp; M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY&nbsp; 12601

David Hull <a class="moz-txt-link-rfc2396E" href="mailto:dmh@tibco.com";>&lt;dmh@tibco.com&gt;</a> 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



            <a class="moz-txt-link-rfc2396E" href="mailto:dmh@tibco.com";>&lt;dmh@tibco.com&gt;</a>



To

            11/22/2004 03:07          <a
 class="moz-txt-link-abbreviated" href="mailto:wsn@lists.oasis-open.org";>wsn@lists.oasis-open.org</a>



            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.




&gt;</pre>
      </blockquote>
    </blockquote>
    <br>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_BGJt9JIqfXXnNoLFsn1v+g)--