Subject: [Simple] authorization for presence

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 May 2001 18:18:22 -0400

Folks,

I think its time we begin discussing the second main open issue discussed at
the last IETF. Specifically, the issue of authorization of presence
subscriptions.

The currently defined method makes use of QAUTH. When a presence server gets
a SUBSCRIBE, it sends a QAUTH to the presentity. If the subscription is
acceptable, the presentity responds to the QAUTH with a 200 OK. The proxy
knows to send QAUTH to the presentity because it will send a methods
parameter in a REGISTER, indicating that their contact address supports
QAUTH.

There are several big problems with this:

1. the QAUTH transaction will timeout if the user doesn't answer right away.
QAUTH, like INVITE, requires human interaction, and so its retransmit
semantics don't work.

2. If QAUTH forks, we will end up receiving the "best" response to the
query, which will be a 200 OK if anyone of the forked requests results in a
200 OK. As a result, the policy for merging approvals for subscriptions is
forced to be the same as the forking rules, which is probably not what you
want.

3. The model assumes that if I can send a registration for a presentity,
that means I am authorized to make policy decisions about subscriptions.
That is not necessarily the case. We are really overloading register to
imply something else.

So, the proposal I made to resolve this was the following:

1. We define a new event package, called "watcherinfo". This package defines
a subscribable entity, which is the current subscription state for some
presentity. Its a list of those active and pending subscriptions for some
presentity. When someone subscribes to a presentity, the subscription state
for that presentity changes. A new pending subscription is basically added.
Since this state is subscribable, a UA can subscribe to it, and get
notifications when it changes. In this case, the UA is notified if someone
tries to SUBSCRIBE to the specific presentity. The body of the notifications
contains the current subscription list for that presentity.

2. We define an authorization document format for presence. This is a simple
document format which indicates the set of subscriber identities that are
permitted, or not permitted, to subscribe to a presentity. For example:

allow:
sip:a@b
sip:b@c

deny:
sip:x@y

3. At any point in time (including after receiving a notification that a new
subscriber has attempted to subscribe), a UA can push a new authorization
document to the presence server. The presence server applies this policy to
the current subscription list, dropping or approving subscriptions as
needed. This push could happen via HTTP or through SIP, TBD.

Here is an example.

A subscriber, sip:[email-masked], subscribes to some presentity,
sip:[email-masked]. The presence server receives the subscription, marks it
as pending, and sends a 202. Now, the subscriber list for peter has changed;
[email-masked] has been added as pending. [email-masked] has also subcsribed
to the subscription state for [email-masked]. It did this previously, by
sending a SUBSCRIBE that looks like:

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: watcherinfo

Now, since the buddy list for Peter has changed, Peter (and any others that
have subscribed), get notifications. The NOTIFY might look like:

NOTIFY sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Content-type: text/xml+buddies

<buddylist>
  <pending>
    <subscriber>sip:[email-masked]</subscriber>
  </pending>
  <active>
    <subscriber>sip:[email-masked]</subscriber>
  </active>
</buddylist>

Peter's UA gets this NOTIFY, and responds with 200 OK. It also queries peter
about whether to accept this pending subscription from [email-masked]. Peter
is away from his desk. He comes back 10 minutes later, and clicks OK. At
this point, the UA uploads a new authorization document fragment, using SIP,
say:

SETDATA sip:[email-masked] SIP/2.0
From: sip:[email-masked]
Content-type: text/authlist

accept:
sip:[email-masked]

The presence server gets this, and responds with a 200 OK. Sally is now
approved.

The benefits of this approach are:

1. we separate the policies on (1) who finds out about subscription changes
for a presentity, and (2) who can set policies for subscription changes for
a presentity.

2. there is no transaction timeout problem

3. policies on merging multiple authorization documents are at the
discretion of the presence server.

4. We unify setting of policies asyncrhonously, and syncrhonously with the
arrival of a subscription.

5. since authorization policies are a document, not a protocol, they can be
exchanged, stored, and manipulated which is very good.

6. much of this is reusable by other protocols

The slides I presented at IETF 50, where I described this proposal, can be
found at:
http://www.jdrosen.net/papers/simple_open_mar01.ppt

We need to decide whether to move forward with this approach. Comments and
criticisms are welcome.

Thanks,
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: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 16 May 2001 18:43:54 -0400

One general objective, I believe, has to be that we can present a
complete solution, i.e., there needs to be a way to do the authorization
in SIP. Otherwise, there's no way to build interoperable systems. (This
doesn't disagree with what Jonathan says, just emphasizes that we can't
stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an
explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.)

Also, as much as possible, naming must be predictable. I'm not too
thrilled about having to configure the variations of peter_buddylist@
and whatever else is needed. Making up URLs with designated names is not
general enough. There may also be other events that require the same
mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event
type need such a pairing? Or can we parameterize this to allow other
events to re-use this meta-event mechanism? (For example, it might be
possible to use something like Event: foo ;watchers or some variation on
this, so that every event is treated as a class with a standard
associated meta-event.).

Finally, it would be nice if we can avoid special cases. Subscribing to
the event 'watcherinfo' should not be substantially different than any
other event. In particular, this must recurse, i.e., subscribing to
watcherinfo in itself must trigger a notification.

> permitted, or not permitted, to subscribe to a presentity. For example:

Nit-picking: I think we've learned from SDP that positional parsing is
bad. I would suggest something like:

+ sip:a@b
- sip:x@y

Also, it is not clear whether such a denial is for one subscription
event or "sticky". 

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Theodore Havinis" <[email-masked]>
Date: Tue, 5 Jun 2001 21:02:18 -0700

As I am trying to understand better the proposed solution I am confused as
to whether
the automatic notification to all watchers as soon as a new watcher tries to
subscribe to the event is just *how a buddy list would work* or whether its
a *a generic requirement* when dealing with subscriptions to events.

I assume, for protecting the presentity's privacy, it would
be enough only for the presentity to be notified everytime a new watcher
requests subscription to the presentity, unless the presentity explicitly
allows the presence server to notify every (or some of them) watcher about
which other watcher is in the list.

Kind rgds
Theo

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Wednesday, May 16, 2001 3:18 PM
> To: [email-masked]'
> Subject: [Simple] authorization for presence
>
>
> Folks,
>