Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Mar 2001 10:40:06 -0500

>
> > 1. X subscribes, and my rules allows the subscription. I am 
> notified that X
> > has subscribed and realize that I do not want X to see my 
> presence state. I
> > publish new rules to prevent X from re-subscribing. But it 
> is too late, X
> > already has my presence information. Also, would the new rules apply
> > immediately, or would X keep his subscription until it 
> expires, and merely
> > be prohibited from re-subscribing?
> >
> > 2. Y attempts to subscribe, but is rejected by my rules. If 
> I knew that Y
> > wanted to subscribe I would allow it. But since I never get 
> a notification
> > that Y wants to subscribe, I have no reason to update my rules.
> 
> The first point was also discussed in the Thread, where 
> authorisation is
> required the immediate NOTIFY returns offline, when and if 
> authorisation is
> granted a new NOTIFY is generated with the correct presence 
> info. This means
> you can't tell if the user is online and rejected your 
> subscription or offline,
> so your privacy is intact. Also in example 2 your friend Y 
> has not been
> rejected. (This is described better in sections 5.5 and 5.6 of
> draft-rosenberg-impp-presence-01.txt)

As I re-read the thread I see that it does answer my question about whether
my new policy list gets applied to existing subscriptions--the answer is
yes.

But unless I am missing something, the information you refer me to does not
address my scenarios. If we use a rule based (i.e. CPL like) mechanism along
with the concept of subscribing to my list of subscribers, then in my first
scenario the authorization has already occured before I get notification
that my list of subscribers has changed. It doesn't matter if I 202 X or 200
X. He will most likely have already received a NOTIFY with my real presence
data long before I can get a new rule set pushed into the server.

In my scenario 2, Y has not been rejected in the sense that he did not get a
400 or 600 class response. Still, I assume if my rules reject him, he never
gets added to my list of subscribers even if we respond with a 202, and I am
never notified that he tried. Are you suggesting that I would receive a
notification for each _unauthorized_ subscription request?

The base problem in both scenarios is the mechanism makes an authorization
decision first, then notifies me (or doesn't). I can tell the server to not
do it again, but it is too late for this particular subscription. Now if my
subscription to the list of subscribers for my presentity got notified of
subscription _attempts_ it would somewhat mitigate scenario 2, but it would
not help much for scenario 1.

---

From: James Undery <[email-masked]>
Date: Thu, 15 Mar 2001 16:05:58 +0000

> data long before I can get a new rule set pushed into the server.

This was discussed in the "immediate notify issue" thread, basically the first
NOTIFY contains the presentity is offline is the subscription is rejected or
requires authentication, when a new policy is uploaded if only authorised
subscribers recieve the real presence info, unauthorised subscribers will see
nothing and can't tell if you really are offline, rejecting them or just not
issued authorisation yet.

> notification for each _unauthorized_ subscription request?

My preference is to have a "ban list", an "allow list" and a default action. The
lists could either be constructed directly or via a CPL script (similar to how
the location list is constructed). In scenario 2 I'd set the default action as
"ask me". The "ban list" would contain the people I wanted rejected (202 and
offline presence) without me being asked, the "allow list" would be to everyone
who was to get the (200 and true presence), every other subscription would
generate a NOTIFY.

> not help much for scenario 1.

The authorisation decision may be to say we are offline until "real
authorisation" arrives from the user. This means it isn't too late as the
subscriber doesn't know if we are offline or not authorising them.

James Undery