Subject: RE: [Simple] authorization for presence

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 7 Jun 2001 02:00:09 -0400

> -----Original Message-----
> From: Robert Brown [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2001 2:18 AM
> To: Theodore Havinis; Jonathan Rosenberg; 
> [email-masked]
> Subject: RE: [Simple] authorization for presence
> 
> 
> I'm wondering...
> 
> 1 - Is it possible to get solution that is applicable to deferred
> authorization in general, rather than specific to authorizing
> subscribers to presence state (I think this is the same thing Theodore
> is referring to in his message?)

I am not entirely sure I understand what you are asking. Perhaps you are
asking if this approach to authorization of subscriptions could be used not
only for presence, but for other subscribable events, like message waiting
indicators. So, in that case, I could subscribe to the watcherinfo for my
voicemail inbox. Whenever someone tries to subscribe to my voicemail inbox,
I would get notified. THen, I could approve or reject those subscriptions.

If this is what you are asking, I agree it should be general. It is for this
reason that we proposed (and there seemed to be agreement on), that
watcherinfo is basically an abstract sub-package. Each event package could,
if it wanted, make use of a watcherinfo subpackage, and that subpackage
allows you to subscribe to, and get notified, subscriptions to the parent
package. So, for the event mwi, we would have a subpackage mwi.watcherinfo.

> 
> 2 - I'm a little wary of coupling the current authorization state with
> the list of pending authorization requests.  This can lead to 
> very large
> auth request messages when users have large numbers of watchers.

I do not understand what you are saying here. 

One of the issues which is going to plague us in our discussions is common
terminology. THis is especially important when talking about recursive
subscription state, which is what watcherinfo is. I do not know what you
mean by "authorization state" or "list of pending authorization requests". I
suppose the former is the watcherinfo state. I don't know what the latter
is.

> 
> 3 - I'm a little wary of restricting the solution to a specific set of
> rights, such as "active" and "blocked", and structuring the state
> document around those rights, as these may not be meaningful and/or
> sufficient for all types of events.

Fair enough. One of the nice things about using a document format for this,
is that we can define a basic one to get us started, and then define
additional documents or extensions as time goes on. The MIME negotiation
capabilities in SIP can make sure that we always support a baseline
authorization document format (which would be the simple block/accept one),
and can figure out whatever common improved-upon format exists.

I'll also note that the issue of authorization policy is profoundly complex,
and the logic that might go into such a decision may, in many cases, only be
expressable in some kind of turing complete language. Therefore, I do not
think it is useful to support arbitrarily complex authorization document
formats. If your policy is so complex that this is needed, the authorization
should all be specified by programmatic logic put in place ahead of time.
One such way to structure that logic is using the CPL extensions for
presence, an I-D that Xiaotao Wu, Henning Schulzrinne, and myself, recently
submitted to IETF:

http://www.ietf.org/internet-drafts/draft-wu-cpl-presence-00.txt

other things, like SIP servlets, would enable you to create any policy you
can possibly dream up.

> 
> ---
> 
> Perhaps we could modify the proposal as follows:
> 
> ---
> 
> 1 - Separate the subscription to the current state of the 
> authorization
> list from the subscription to authorization requests
> 
> So the example below would become two subscriptions:
> 
> i) subscribe to the authorization list (in this case "watcherinfo") to
> ensure you always get notified of the current state of the list.
> 
> SUBSCRIBE sip:[email-masked] SIP/2.0
> Event: watcherinfo
> 
> ii) subscribe to authorization list's authorization requests (in this
> case we'll call it "watcherinfo.authrequests")
> 
> SUBSCRIBE sip:[email-masked] SIP/2.0
> Event: watcherinfo.authrequests

I still don't know what this is. Can you explain?

> 2 - generalize the payload of the authorization list.  This means
> removing words like "buddylist" and replacing with something more
> general.  It may also mean using attributes to contain 
> conferred rights
> ("allow", "block", etc), rather than having a separate containing
> element for each right.  For example: auth="allow".  Or more 
> generally:
> auth="right1 right2 right3".

By authorization list, I assume you mean the authoriztion document that is
pushed to the server by the users, to approve or reject subscriptions. This
is not the same as the buddylist or watcherinfo.

As I discussed above, I think we need a simple baseline, and support for
more complex ones. 

> 
> This will make the rights list easily extensible for any authorization
> that semantically differs from buddy watchers - i.e. the set of rights
> does not dictate the grammar of the XML document.
> 
> For example, we could change the xml payload of the authorization list
> notification to look like:
> 
> NOTIFY sip:[email-masked] SIP/2.0
> From: sip:bar.com
> To: sip:[email-masked]
> Event: watcherinfo
> Content-type: text/xml+authlist
> 
> <authlist>
>    <subscriber URI="sip:[email-masked]" auth="allow" />
>    <subscriber URI="sip:[email-masked]" auth="block" />
> </authlist>

I am confused here. THe proposal was to get notified of changes to
watcherinfo. That means the notifications contain the current watcherinfo
state, which is the set of people who have active or pending subscriptions
to me. This state, which I proposed be an XML document (and indeed we
submitted a description of in the original June 2000 proposal set), is NOT
the same as an authorization policy document. The thing above in the XML
looks like an authorization document, and that document would be carried in
a REGISTER or SETDATA or whatever we decide upon.

> 
> Note the general content-type "text/xml+authlist"
> 
> As a possible optimization to cater for lengthy authorization 
> lists, we
> could propagate deltas instead. 

Absolutely, this is essential. We discussed that during IETF 50, and it
seemed to be the consensus.

 If I have 200 watchers, and grant
> access to the 201st watcher, I'd rather not propagate all 201 
> watchers.

Exactly.

> Clients could monitor CSEQ (which is defined as "monotonic contiguous
> increasing" - i.e. always increments by 1) in the NOTIFYs to detect
> missing deltas and re-subscribe to get the full list.  For example:
> 
> NOTIFY sip:[email-masked] SIP/2.0
> From: sip:bar.com
> To: sip:[email-masked]
> Event: watcherinfo
> Cseq: 34
> Content-type: text/xml+authlistdelta
> 
> <authlistdelta>
>    <subscriber URI="sip:[email-masked]" auth="allow" />
> </authlistdelta>

Hmm, I think maybe I am beginning to understand what you are saying. You
want to be able to subscribe to my current authorization policy on the
server, since that is also a piece of state (primarily changed through the
uploads of authorization documents). Interesting. Not sure that I really
need to support notifications and subscriptions to it. I think it would be
sufficient just to be able to fetch it (as we do with CPLs).

> 
> ---
> 
> 3 - generalise the payload of the authorization request in a similar
> manner.
> 
> NOTIFY sip:[email-masked] SIP/2.0
> From: sip:bar.com
> To: sip:[email-masked]
> Event: watcherinfo.authrequests
> Content-type: text/xml+authrequest
> 
> <authrequest>
>    <pending URI="sip:[email-masked]" request="allow" />
>    <pending URI="sip:[email-masked]" request="allow" />
> </authrequest>

Do you mean what I was referring to as watcherinfo?

> 
> ---
> 
> The reason I put a 'request="allow"' attribute in there is 
> because they
> might be requesting some type of access other than "allow". This would
> be proprietary to the particular data being watched.  This is 
> also why I
> suggested generalizing the set of authorization states in 
> step 2 above,
> like auth="right1 right2 right3".  For example, the data I 
> want to watch
> might be the number of minutes left on a calling card.  I 
> might request
> access to 400 minutes, but I only get authorized for 20.  I don't know
> if it's that useful.  Supporting multiple simultaneous rights 
> certainly
> isn't necessary for watcher lists, but might be relevant for something
> else.

I think all of these would be separate document formats entirely.

The general watcherinfo concept, and the concept of uploading policy
documents, apply to anything one might want to subscribe to and
authorization. However, the document formats - watcherinfo, and the
authorization document, are specific to human presence, and that is the
subject of concern for this working group.

-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: [email-masked]
Date: Tue, 12 Jun 2001 11:04:13 -0500

I'll make an effort to clear up some confusion here.

> suppose the former is the watcherinfo state. I don't know 

Currently, we define "watcherinfo" to conatain current and pending
subscriptions. (Jonathan, you use this distinction later in this
same post, in the context of: "That means the notifications contain
the current watcherinfo state, which is the set of people who have
active or pending subscriptions to me.")

I beleive what Robert is proposing is that this be considered two
completely different sets of state: active subscriptions to a state,
and pending subscriptions to a state.

I have no opinion on the topic, but wanted to get a feel for group
consensus so that whoever writes the watcherinfo draft has an idea
of how to craft it.

/a