Subject: RE: [Simple] Another idea for presence authorization

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jul 2001 09:21:53 -0400

We have a presence server and a presence client.
We can standardize the interface between the presence
server and the presence client, but we can't standardize
the interface between the presence server and the presentity
(a human).

Actually, of course we could - we could add a new entity,
which is a presentity agent, distinct from the presence
server and then standardize the interface between the
presentity agent and the presence server.  I propose that
we DON'T do that.  If you want the effect of a centralized
server with the agent of the presentity distinct from the
server, then use a B2BUA where the "presence server" is
the only client of the "real" presentity, and the
rest of the clients connect to the presence server.

Before anyone yelps about privacy, I'll point out that
there is NO WAY to prevent anyone from doing this - if
you give me authorization to your presence, I can then
run a presence server for anyone I like that offers
your presence, and there is nothing you can do about it,
except unauthorize me.  If you run your own version of it,
you control the policy of the presence server, and it's
the same level of control you ever get to have.

We went through all of this in SPATIAL.  It's much simpler
to keep the basic SIP paradigm of UAC/UAS at the edge,
and then get some help with scaling from proxies in the
middle then it is to have a different protocol between the
presentity agent and the presence server then between
the presence server and the watcher agent.

If you do it my way, then you are talking about the GUI
mechanism between the UAS and the human - not something
we standardize.  More importantly, authorization is
very complex, because it is tied to what the actual
presence model is.  While you all might be thinking about
the simple minded logged on/not logged on model, I have
a much richer model, as many folks working on presence do.
To authorize, I need to know a fair amount about who you
are, and then I will authorize you for some, but possibly
not all, of the presence information my server can supply.
While I agree that you can do this with a URL in some
cases, in my case, that would be insufficient.

But mostly, I don't want to open that can of worms at all,
at least not now. 

Brian

> -----Original Message-----
> From: Bobby Sardana [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 1:53 AM
> To: Subir Saha
> Cc: 'Jonathan Rosenberg'; 'Rosen, Brian';
> [email-masked]'
> Subject: Re: [Simple] Another idea for presence authorization
> 
> 
> Greetings:
> 
> Allowing ad-hoc authorization decisions, for subscription, 
> based on proprietary
> implementations is worse than formalizing them, IMHO. So 
> there needs to be
> guidelines/mechanisms in place for authorization.
> 
> Presenting URLs for subscription authorization is one such 
> mechanism that is
> being proposed by Jonathan. If it leads to formalization in 
> implementations,
> then it should be protocolized. Otherwise, we'll have what's 
> out there now --
> the popular IMs and folks trying to inter-operate them.
> 
> Bobby Sardana.
> [email-masked]
> 
> Subir Saha wrote:
> 
> > I think what Brain is objecting about putting a human in 
> the authorization
> > loop. However, I think it is not necessarily so. Let us 
> assume the call
> > flown below:
> >
> > A subscribes to B's presence server(PS). The first thing PS 
> does a send a
> > 202 back to A and then a authorization request to B giving 
> some info about
> > A. If B may have an "automata" to authorize A or he may do 
> it interactively.
> > If the PS is waiting on this result then it is problem. 
> However, PS may fire
> > an authorize request and forget and when the authorization 
> is done in B, PS
> > may get back a new message AUTHDONE or something like from B.
> >
> >  A              PS                      B
> >  |----Sub--->|                  |
> >  |<---202----|                  |
> >  |               |-----auth A---->|
> >  |               |<----200--------|
> >  |               |                      |
> >  |               |<--AuthDone A---|
> >  |               |------200------>|
> >  |               |                      |
> >
> > Now as PS is not waiting on B for an interaction, I don't 
> thing this is an
> > objection. However the question remains how do we authorize 
> - i.e., what are
> > the information needed to make the authorization done. Is it wise to
> > protocolize that? Like if my friend wants my presence, I may be just
> > authorize on looking at his e-mail or sip or any id. 
> However with the case
> > of business colleague, I may need hell lot of info. Now is 
> it possible to
> > standardized such an arbitrary requirement? That is what a 
> valid objection,
> > I see, Brian has.
> >
> > Subir
> >
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Wednesday, July 11, 2001 2:30 PM
> > To: 'Rosen, Brian'
> > Cc: [email-masked]'
> > Subject: RE: [Simple] Another idea for presence authorization
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Wednesday, July 11, 2001 8:42 AM
> > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)';
> > > [email-masked]'; Ben Campbell
> > > Cc: [email-masked]
> > > Subject: RE: [Simple] Another idea for presence authorization
> > >
> > >
> > > Jonathan
> > >
> > > We agree that the authorization mechanism is not part of
> > > the spec, so why is notification of request for subscription
> > > part of the spec?  In particular, why is there a STANDARD
> > > way that B finds out that A wants to subscribe?  That
> > > is entirely within the domain of B's implementation, and
> > > usually we don't standardize such things.
> >
> > We standardize things when an automata and one point needs 
> to process some
> > information sent by an entity at another point. If we want a client
> > application to be able to process the fact that a 
> subscription was made to
> > its user (so that it might, for example, do a screen pop asking for
> > approval), then we need a standard. If we think that this 
> information will
> > never be processed by automata, then we don't need a 
> standard. I think we
> > might need it processed by automata.
> >
> > >
> > > > 1. this bit about letting B know is **NOT** part of the
> > > main presence
> > > > specification whatsoever. All that specification says is "the
> > > > server obtains
> > > > authorization in some fashion, not specified". The mechanism
> > > > that allows B
> > > > to find out who subscribes is separate, and opt-in, not
> > > > opt-out. That is, B
> > > > has to explicitly request to find out who subscribed to
> > > him. If B does
> > > > nothing, B finds out nothing. Presence servers don't have to
> > > > provide the
> > > > function either.
> > > Got it, but that is entirely in B's implementation - there is
> > > no point in standardizing how B's server tells B the human
> > > how to authorize (or indeed that he is asked to authorize).
> > > If your implementation wanted to use such a mechanism, and
> > > mine wanted to send me email, they would interoperate.
> > > In fact, no aspect of interoperability is affected by this
> > > spec, and thus I claim it is not appropriate.
> >
> > I think I've addressed this above. Email or IM content is 
> not processed by
> > automata.
> >
> > >
> > > My suggestion, on the other hand, is about interoperability -
> > > if B wants to let A know how to get authorized, he can
> > > supply the URL.  A's implementation - not knowing anything
> > > about B's implementation, could assist A to get authorization.
> > > While there could be other ways, having one standardized way
> > > is a good thing.
> >
> > Whether or not we standardize a way to notify B about the 
> subscription from
> > A, I would argue there is no need to tell A how to get authorized.
> > Ultimately, B has to provide authorization. So, anything 
> that A can do
> > ultimately results in getting some information to B in 
> order to allow B to
> > make a decision. So, why have the presence server for B, 
> for example, tell A
> > to send email to B, when the presence server itself can 
> send the email?
> > Particularly since you may not want A to know that no 
> authorization policy
> > exists for them.
> >
> > >
> > > >
> > > > 2. why even worry about this? Well, all of the major IM and
> > > > presence systems
> > > > do this today. We should at least be able to provide the same
> > > > application
> > > > interface thats available, if users and their providers want it.
> > > Excuse me, all existing IM systems have a way to find out
> > > who is subscribed to your presence?  All existing IM systems
> > > supply two URLs to approve or deny subscriptions?  Funny,
> > > I didn't think any of them did.  Let me fire up AIM.
> > > Hmmm, doesn't seem to have any controls on authorization,
> > > doesn't seem to have a way to find out who is looking at your
> > > presence.  You can control who sends you IM.
> > > Actually, I don't know of ANY existing presence service that has
> > > the authorization idea, although there are "closed group"
> > > systems which limit who can do anything.
> >
> > On Yahoo messenger, when someone subscribes to me, if I'm 
> logged in at the
> > time, I get a screen pop which says "User Joe just asked to 
> be added to your
> > buddy list. Click here to approve, click here to reject, 
> click here to
> > approve and add". If I'm offline, this screen pop arrives 
> when I next log
> > in. This tells me that the system provides some way for an 
> automata to learn
> > the set of outstanding subscriptions for its user, in order 
> to provide that
> > screen pop.
> >
> > > > 3. I agree with you that defining authorization policy 
> is a back-end
> > > > mechanism, and typically not real time. Thats why I have been
> > > > arguing that
> > > > the notification to B about the subscriber contain http URLs
> > > > that can be
> > > > used to accept/reject, and those URLs are part of the
> > > > back-end non-real-time
> > > > application. They facilitate a screen pop to a slim phone
> > > > that says "approve
> > > > or reject?" and thus allows setting of simple policies right
> > > > away without a
> > > > browser.
> > > That may be appropriate for some implementations, but clearly
> > > not all.  However, it doesn't matter because it's entirely in
> > > one implementation.
> >
> > Don't we want interoperability between client applications 
> and servers? I
> > thought that was the point - to not need to have a client 
> written by the
> > vendor of the server.
> >
> > -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: Bobby Sardana <[email-masked]>
Date: Thu, 12 Jul 2001 23:02:39 -0700

Greetings Brian:

The interface we talk about is the presentation of a URL -- that can result
in a specific action upon invocation. How is this URL presented to the
presentity is *implementation dependent* but  the presentation of the URL
should be mandated.

Bobby Sardana.
[email-masked]