OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AI: Trust issues with subscriptions


Here is some proposed text, to go under "Security Considerations" along with whatever moves in from the whitepaper.  Note that the first case mentioned alludes to WSA issues that are still shaking out.



Given that the subscription mechanism allows a Subscriber to direct message traffic toward a NotificationConsumer without the consumer's direct knowledge, a NotificationProducer is obligated to be sure that actually sending such notifications will do no harm.  Such notification could cause harm in at least two ways: by allowing a consumer to see information it is not authorized to see, and by flooding the consumer with message traffic it is authorized to see but does not want.

In the first case, the may choose to trust the Subscriber, just as though the subscriber were making a direct request for information, or may also or instead require a security token proving that the Consumer is authorized to see the information in question.  In any case, it SHOULD use policy assertions to indicate what level of proof is required.  This is very similar to the case of a request/reply operation in which the reply address is different from the sender of the request.

In the second case, the producer has several options for assuring itself that the notifications are actually wanted, including but not limited to:
  • Trusting the Subscriber only to provide wanted subscriptions.
  • Not trusting the Subscriber, but relying on out-of-band knowledge of which consumers will allow which notifications.
  • Not trusting the Subscriber, but specifically asking the consumer out of band whether it is interested in notifications before sending them.
  • Sending notifications unconditionally for trusted Subscribers, but using methods such as the previous two if the Subscriber is not trusted.
As with the previous case, the NotificationProducer SHOULD indicate what rules are in effect.  In addition, consumers MAY advertise or use out-of-band mechanisms to communicate their requirements to NotificationProducers.  The Notify message format also allows the NotificationProducer to provide a SubscriptionManager endpoint reference that the Consumer may use to terminate an unwanted subscription, though it will often be preferable to prevent the unwanted subscription in the first place.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]