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

From: Subir Saha <[email-masked]>
Date: Wed, 11 Jul 2001 15:58:30 -0700

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

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 11 Jul 2001 22:53:18 -0700

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]