Subject: RE: [Simple] authorization for presence

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 May 2001 08:26:12 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 6:44 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] authorization for presence
> 
> 
> 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.)

Just so I am clear, are you saying that we need an entire solution that is
completely SIP based, or just an entire solution? I agree with the latter,
and that was indeed the point of the proposal. I am not yet completely
convinced that it is all SIP, and less certain that uploading of
authorization documents is best done by a new AUTH method or something
similar.

> 
> 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.).

I think that having a standard naming convention here is probably a good
thing. It also seems clear that this concept does go beyond just presence.
One way to consider it is that every event package has a pre-defined set of
subpackages:

foo.wachters
foo.statistics
foo.policy

or something like that.

> 
> 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.

I think the mechanism should allow this, but we don't need to require each
presence server to support these sub-sub packages. So, for example:

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: presence.subscribers.subscribers

might generate:

SIP/2.0 489 Package not Supported

This example does make me wonder, though; if the package name is
"subclassed" to indicate watchers, do we need to indicate this in the R-URI
as well? That is, would the SUBSCRIBE instead look like:

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: presence.subscribers

I suspect this is probably more correct and in line with the SUBSCRIBE
architecture.

-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

> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 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
> 
> 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". 
> 
> > 
> > 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
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 May 2001 11:39:19 -0700

> authorization documents is best done by a new AUTH method or something

I would prefer that there is a SIP solution, as otherwise we create
naming problems, among other things. (Also, as a secondary problem,
UDP-only embedded systems are then no longer feasible.)

> I suspect this is probably more correct and in line with the SUBSCRIBE

Definitely the second one. This follows the object/properties model.

---

From: "Adam Roach" <[email-masked]>
Date: Tue, 22 May 2001 08:07:41 -0500

Jonathan Rosenberg writes:

> foo.watchers

I like this idea. Should I be including this sort of thing in the
SUB/NOT draft (since it ostensibly applies to all events), or
should we leave this to a different draft or set of drafts?

It would seem most appropriate to allow this sort of thing to
be extensible (e.g. float the idea of generic subpackages in
the base draft), and then let other drafts define them. In other
words, a new draft would define the "watchers" subpackage
which can be applied to any arbitrary package (even other
subpackages). That's rather cool...

/a