Subject: RE: [Simple] authorization for presence

From: "Robert Brown" <[email-masked]>
Date: Tue, 5 Jun 2001 23:18:22 -0700

To my mind, the strengths of the new proposal are that it:
1 - deals effectively with the potential latency involved in deferred
authorization
2 - deals with multiple potential authorization points
3 - attempts to provide current data state that can be used to
synchronize state across nodes that might display or enforce
authorization

But I do share a similar concern to that expressed in the first
paragraph of Theodore's mail.

---

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

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.

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.

---

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

---

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

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>

Note the general content-type "text/xml+authlist"

As a possible optimization to cater for lengthy authorization lists, we
could propagate deltas instead.  If I have 200 watchers, and grant
access to the 201st watcher, I'd rather not propagate all 201 watchers.
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>

---

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>

---

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.

Thanks for reading this far :-)

- Rob

Robert Brown
Lead Program Manager
Microsoft Real Time Communications Server
mailto:[email-masked]

> -----Original Message-----
> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 9:02 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Simple] authorization for presence
> 
> 
> 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,
> >
> > 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
> >
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
> 
> 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 12 Jun 2001 11:11:06 -0500

Some recent posts have made it clear that the subpackage proposal
may be widely misunderstood. I'll attempt to clarify a couple of points.

> NOTIFY sip:[email-masked] SIP/2.0

...

"Event: watcherinfo" will **NEVER** be a valid thing to say. We are
proposing this to be a *subpackage*, which means it must be contained
in another package. For the purposes of the discussions we've been
having here, my guess is that you mean to say "Event: presence.watcherinfo"

One of the consequences of this fact is that, for example, including
"event" as part of the XML document makes no sense.

><authlist>
>   <subscriber URI="sip:[email-masked]" event="presence" auth="allow" />
>   <subscriber URI="sip:[email-masked]" attribute="geolocation" auth="allow"
/>
>   <subscriber URI="sip:[email-masked]" event="presence" auth="block" />
></authlist>

Since this document will be carried in a NOTIFY which has an
"Event:" header of "presence.watcherinfo," the event which is
referenced *must* be "presence." Including it in the document
is redundant if it matches, and invalid if it does not.

/a