Subject: RE: [Simple] Another idea for presence authorization

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2001 18:18:02 -0400

Yes, I understand what you are proposing; I think it 
is not appropriate to confuse the concept of
authorization (will I allow you to subscribe) from
the actual subscription.  You want to do that - you
want the very first action to be a subscribe.
If the server for B can immediately confirm a new
authorization, because there is some policy in place
that lets it do so, you propose to let that subscription
succeed.  You want to talk about what happens when
it fails.

I want to completely remove authorization from the protocol;
Subscriptions are then only how you connect to the
presentity's server.  It succeeds if you are authorized,
fails if you aren't (also fails for other reasons).
I see no win at all to have the protocol deal with
authorization.

So, with that in mind, let's look at what you propose:

> This is not right. The party that approves or denies the 
> subscription is NOT
> the party that has subscribed.
We all agree, B is the approver.  B's server has the authorization.
A subscribes.  It succeeds only if B has given approval.

> 
> Here is the scenario. A subsciber, A, subscribes to B. For 
> any subscription
> to B to be approved, B has to have given authorization for 
> it. However,
> there is currently no authorization policy specified by B 
> about whether A
> can subscribe. So, when A's subscription is received by the server, a
> response is generated, but the subscription is not activated. 
I claim if B has no authorization for A, then A's subscription
request is denied, and that is the end of the story.
So I agree you get a response, and that is fail, with
a referral (URL).

If A wants to get approval, he might consult the URL to find
a web page that might allow him to be authorized.

>Now, the
> problem is that the server needs to know whether B approves this
> subscription. It might just wait, hoping that someday, B sets 
> a policy for
> user A. However, that doesn't work well. What you want is 
> some way to prod
> B, and say to him, "hey, A tried to subscribe, please set a 
> policy for A".
> Then, A can go to some web page, or whatver the backend 
> policy mechanism is,
> and set up policy.
Wrong end.  You don't want B to take action just because
A tried to subscribe.  Great opportunity to drive B nuts.
What you want to do is tell A how to get authorized.
A is the one who wants to get authorized, and we can tell
him how to do it.  There is no win in telling B how to
run his own authorization mechanism.  Mostly, there is
no win in prodding B based on a subscription attempt for A
when A isn't even authorized.

Importantly, the subscription request failed. 
If B's server eventually gets some authorization info, 
it has nothing to do with it but wait until A tries 
to subscribe again. 

> 
> So, to provide this "prodding" capability, we've agreed to 
> use a new event
> package, called watcherinfo. The idea is that B can subscribe 
> to his own set
> of watchers, so that when it changes (for example, when A 
> subscribes), B
> gets notified. B can then go to the web page and upload approval. 
This seems wacky to me.  Why should the protocol prod B?
Why should the protocol do anything to support authorization -
that is a non-real-time issue.  Sending B an email may be a more
appropriate thing to do, but that should be because A asks for
authorization.  The question is, how does A do that?  The point
is that since it's B's decision, B may need arbitrary information
from A before he will authorize.  Therefore, A needs to use B's
authorization mechanism.  You can't make A's user interface
know how to give B what he needs to authorize.  A web page that
B creates is at least one way to do that.

>The
> additional thing we are debating, is whether there should be an actual
> protocol mechanism for conveying that approval/rejection to 
> the server. I
> have proposed that the NOTIFY that gets sent to B when A 
> subscribes have two
> URLs specified by the server, one which approves the 
> subscription from A,
> and one which rejects. Others have proposed that we specify a 
> protocol for B
> to upload approval in a presence document. Others want to specify
> SIP/SOAP/WSDL for this.
Repeating myself, there is no point in having protocol support
for human-in-the-loop messaging.  While this might be something
that is worth specifying so that B's agent can talk to B's
server, I suspect that at least for now, we can safely leave this
out of the spec because it has nothing to do with A and B.
You are talking about how B the human interacts with B's server;
not something I think is worth standardizing.

> 
> All of this is different from what A sees when A's 
> subscription to B is
> rejected, approved, or marked as "pending" because there is 
> no policy. We
> have already agreed some time back that in all cases, the subscription
> request is immediately responded to with a 202 and a NOTIFY 
> with the status.
> If the subscription was accepted, the status is correct. If 
> the subscription
> failed, or was marked as pending, the NOTIFY contains 
> syntactically correct
> but invalid data. This way, the subscriber can't know what 
> happened to their
> subscription. 
I think we are in agreement here.  A doesn't get to know if
he is authorized or not, subscription just fails.

In particular, when B finally does authorize A, A has to
"just know" to try subscribing again; we don't help him.

It's always possible that the authorization mechanism tells
A, say by email.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2001 19:13:24 -0400

Brian,

A key difference between what you propose and what Jonathan proposes is
that in your scenario A is able to tell (because his SUBSCRIBE fails)
that he isn't getting accurate presence information about B. In this
case with Jonathan's proposal A believes that he has been permitted to
subscribe and that B isn't present.

I gather that Jonathan's approach is intended as a form of
confidentiality, and is akin to having your secretary tell people you
aren't in when you want to avoid them. Your proposal doesn't provide a
way to do this sort of fibbing.

While I understand the reason for wanting to do this, it seems to me
that is incomplete, and as long as it is incomplete then it may not be
worth the trouble. The reason it is incomplete is because A can still
try inviting B and get a bunch of extra information out of the resulting
status. To get the full intended effect, it is probably necessary to
configure either the phone or a proxy, to return a particular status to
undesired callers.

	Paul Kyzivat
	Cisco Systems

"Rosen, Brian" wrote:
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple