Subject: [Simple] Another idea for presence authorization

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Jun 2001 19:33:27 -0400

Folks,

I was in the process of writing up the consensus to date on presence
authorization, and I had another idea on uploading authorization for the
subscriptions. The approach is a hybrid between the intitial "post a
document to an http URL" idea, and the AUTH or SERVICE methods in SIP. 

Here's the idea. B is some presentity. B subscribes to his own watcher
information. When A subscribes to B's presence, B gets notified of a pending
subscription. This comes in a NOTIFY carrying a watcher information data
format. This data format has, as part of its definition, URLs that can be
used to accept or reject the subscription. So, for example, B would get a
NOTIFY like:

NOTIFY sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Content-Type: application/watcherinfo+xml
Event: presence.winfo

<watcherinfo>
  <presentity uri="sip:[email-masked]">
    <watcher uri="sip:[email-masked]" status="pending"
                event="subscribe">
      <approve>http://bar.com/approve.cgi?user=A&watcher=B</approve>
      <reject>http://bar.com/reject.cgi?user=A&watcher=B</reject>
    </watcher>
  </presentity>
</watcherinfo>

Now, if B wants to approve the subscription, the URL within the approve tags
is taken and used, and if it wants to reject, the one within the reject tags
is used. Of course, the http POST needs to be authenticated. That can be
done with digest over https, and the username and password provided would be
checked against the same back end database that holds the SIP username and
passwords. No document formats or anything else are generated. 

Now, the benefits of this approach are:

1. no need to define an authorization policy data format
2. no need to standardize a mapping from sip URLs to http URLs, which was
one of the main (and valid) objections to the initial HTTP approach.
3. the server chooses the URLs for approval and rejection, their structure
has no semantics anywhere outside of the server. 
4. views approval and rejection as form post operations, which is what they
really are (indeed, I expect offline authorization systems to be entirely
web based, with forms as the primary tool for setting data. Indeed, the same
back end cgi scripts can be used, which is very nice)

The drawbacks:

1. still reuqires http. Now, you could, in principle, put a sip url in there
instead of an http URL, but I think thats pushing it a bit. I really think
that this kind of thing is a form post operation. This kind of mecahnism is,
BTW, exactly how collected data is passed in VXML systems.
2. doesn't allow more complex policies to be set *this* way; you can still
set authorization policy through CPLs, web interfaces, and so on. This
mechanism would just automate the baseline case of approve/reject. Indeed,
we could even have another tag, <setpolicy>, which has a URL you can visit
for an interactive web session to set arbitrarily complex policies.

Comments?

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: Mon, 02 Jul 2001 10:18:46 -0500

> for an interactive web session to set arbitrarily complex policies.

I can see value in this approach for simple yes/no decisions. However, I 
do not think benefits 1 and 2 really apply, as we would _still_ need the 
method for pushing policy outside of the context of a subscription 
request. For example, if I using the above approach choose to disapprove 
your subscription to me(assuming you mean for that decision to be 
sticky) how could I change my mind tomorrow and allow you access? I 
assume that I would not be notified for every _denied_ subscription.
That requirement alone suggests that _every_ (or at least most) presence 
system must have a way for pushing policy at any time, not _just_ in 
response to a pending subscription. If this is true, then we also need 
to standardize the method and formats of pushing policy at any time.