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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Jul 2001 08:17:01 -0400

Vasilis

There are a couple of issues:
1. Can you subscribe to your own something that Notifies you
when a watcher subscribes?
	I say, sure, why not, fine idea.
	I think the concept that you CAN get notification
		when someone actually starts looking at your
		presence info is a good one.  As you say, it's
		optional to subscribe.
	Note that this has nothing to do, in my mind, with
		authorization

2. Can you subscribe to something that gets you Notification
   that you have some authorization effort to make?
	I say, not interesting.  The process of authorization
	is within an implementation of a UAS (the presence server,
	as an endpoint in a SIP system, is a UAS) and is not
	subject to standardization.  The only way this isn't
	true is if the presentity is represented as a UAC, and
	the PS is a UAS, and then you need a standardized way that
	the presentity's UAC conveys authorization and presence
	setting information to the PS's UAS.  I think that is
	a bad design idea.

3. Is a pair of URLs the way to represent an accept/deny 
   authorization decision?
	I'd say, no, not by a whole lot.  To make an authorization
	decision, the presentity needs to be presented with
	credentials (who are you that is asking to be authorized).
	Presence information may come in several forms, and you may
	need to specify what form.  A decision on presence may
	not be binary (it may be, for example, which form is 
	allowed).	So to authorize, you have to present a variable 
	amount of information from the watcher, and you have to
	accept a variable amount of information from the presentity.
	While I happen to think that a web based GUI to do this
	is a very fine idea, I think that you can't standardize it,
	at least now.

Brian	

> -----Original Message-----
> From: Vasilis Polychronidis 
> [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 6:38 PM
> To: Jonathan Rosenberg; 'Rosen, Brian'
> Cc: 'Boyer, D G (Dave)'; [email-masked]'; Ben Campbell;
> [email-masked]
> Subject: Re: [Simple] Another idea for presence authorization
> 
> 
> Hi Brian,
> Looking through this issue I tend to agree with Jonathan's proposal.
> It is really important that the method described by Jonathan 
> (Subscribing to
> your watcher info)
> is optional.
> As Jonathan said B has to explicitly request it (subscribe to 
> his watcher info).
> 
> In addition we should not mandate the Presence Server to
> accept "watcher type": subscriptions.
> So the proposed feature is an optional one.
> Is this acceptable to you Brian?
> 
> I also agree with the use of URLs for accepting/rejecting a 
> subscription.
> 
> BR,
> 
> Vasilis Polychronidis
> 
> Jonathan Rosenberg wrote:
> 
> > Brian,
> >
> > Now I understand what you are saying. I want there to be a 
> way for B to find
> > out when someone subscribes to him, so he can, if desired, provide
> > authorization. You don't want to ever tell B when someone 
> subscribes;
> > rather, you tell A that they should visit some web page, 
> and maybe that
> > allows them to send email to B asking for authorization.
> >
> > So, let me make a few comments in response:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > The problem that has been observed with your alternate 
> approach, of telling
> > A about a URL, is that this allows A to learn whether they have been
> > approved or rejected. Paul argues that this knowledge can 
> be learned anyway,
> > by sending an INVITE and seeing whether the call is 
> accepted or rejected.
> > Not necessarily; I can set up a service to achieve the same 
> effect for
> > voice. If someone calls me, and I don't want to talk to 
> them, instead of
> > them getting a "600 I hate you" response, the server can 
> simply let the
> > phone ring indefinitely, so that the caller can't tell 
> whether I'm not
> > there, or whether they've been rejected.
> >
> > -Jonathan R.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Tuesday, July 10, 2001 6:18 PM
> > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)';
> > > [email-masked]'; Ben Campbell
> > > Cc: [email-masked]
> > > Subject: RE: [Simple] Another idea for presence authorization
> > >
> > >
> > > Yes, I understand what you are proposing; I think it
> > > is not appropriate to confuse the concept of
> > > authorization (will I allow you to subscribe) from
> > > the actual subscription.  You want to do that - you
> > > want the very first action to be a subscribe.
> > > If the server for B can immediately confirm a new
> > > authorization, because there is some policy in place
> > > that lets it do so, you propose to let that subscription
> > > succeed.  You want to talk about what happens when
> > > it fails.
> > >
> > > I want to completely remove authorization from the protocol;
> > > Subscriptions are then only how you connect to the
> > > presentity's server.  It succeeds if you are authorized,
> > > fails if you aren't (also fails for other reasons).
> > > I see no win at all to have the protocol deal with
> > > authorization.
> > >
> > > So, with that in mind, let's look at what you propose:
> > >
> > > > This is not right. The party that approves or denies the
> > > > subscription is NOT
> > > > the party that has subscribed.
> > > We all agree, B is the approver.  B's server has the 
> authorization.
> > > A subscribes.  It succeeds only if B has given approval.
> > >
> > > >
> > > > Here is the scenario. A subsciber, A, subscribes to B. For
> > > > any subscription
> > > > to B to be approved, B has to have given authorization for
> > > > it. However,
> > > > there is currently no authorization policy specified by B
> > > > about whether A
> > > > can subscribe. So, when A's subscription is received by the
> > > server, a
> > > > response is generated, but the subscription is not activated.
> > > I claim if B has no authorization for A, then A's subscription
> > > request is denied, and that is the end of the story.
> > > So I agree you get a response, and that is fail, with
> > > a referral (URL).
> > >
> > > If A wants to get approval, he might consult the URL to find
> > > a web page that might allow him to be authorized.
> > >
> > > >Now, the
> > > > problem is that the server needs to know whether B approves this
> > > > subscription. It might just wait, hoping that someday, B sets
> > > > a policy for
> > > > user A. However, that doesn't work well. What you want is
> > > > some way to prod
> > > > B, and say to him, "hey, A tried to subscribe, please set a
> > > > policy for A".
> > > > Then, A can go to some web page, or whatver the backend
> > > > policy mechanism is,
> > > > and set up policy.
> > > Wrong end.  You don't want B to take action just because
> > > A tried to subscribe.  Great opportunity to drive B nuts.
> > > What you want to do is tell A how to get authorized.
> > > A is the one who wants to get authorized, and we can tell
> > > him how to do it.  There is no win in telling B how to
> > > run his own authorization mechanism.  Mostly, there is
> > > no win in prodding B based on a subscription attempt for A
> > > when A isn't even authorized.
> > >
> > > Importantly, the subscription request failed.
> > > If B's server eventually gets some authorization info,
> > > it has nothing to do with it but wait until A tries
> > > to subscribe again.
> > >
> > > >
> > > > So, to provide this "prodding" capability, we've agreed to
> > > > use a new event
> > > > package, called watcherinfo. The idea is that B can subscribe
> > > > to his own set
> > > > of watchers, so that when it changes (for example, when A
> > > > subscribes), B
> > > > gets notified. B can then go to the web page and upload 
> approval.
> > > This seems wacky to me.  Why should the protocol prod B?
> > > Why should the protocol do anything to support authorization -
> > > that is a non-real-time issue.  Sending B an email may be a more
> > > appropriate thing to do, but that should be because A asks for
> > > authorization.  The question is, how does A do that?  The point
> > > is that since it's B's decision, B may need arbitrary information
> > > from A before he will authorize.  Therefore, A needs to use B's
> > > authorization mechanism.  You can't make A's user interface
> > > know how to give B what he needs to authorize.  A web page that
> > > B creates is at least one way to do that.
> > >
> > > >The
> > > > additional thing we are debating, is whether there should
> > > be an actual
> > > > protocol mechanism for conveying that approval/rejection to
> > > > the server. I
> > > > have proposed that the NOTIFY that gets sent to B when A
> > > > subscribes have two
> > > > URLs specified by the server, one which approves the
> > > > subscription from A,
> > > > and one which rejects. Others have proposed that we specify a
> > > > protocol for B
> > > > to upload approval in a presence document. Others want 
> to specify
> > > > SIP/SOAP/WSDL for this.
> > > Repeating myself, there is no point in having protocol support
> > > for human-in-the-loop messaging.  While this might be something
> > > that is worth specifying so that B's agent can talk to B's
> > > server, I suspect that at least for now, we can safely leave this
> > > out of the spec because it has nothing to do with A and B.
> > > You are talking about how B the human interacts with B's server;
> > > not something I think is worth standardizing.
> > >
> > > >
> > > > All of this is different from what A sees when A's
> > > > subscription to B is
> > > > rejected, approved, or marked as "pending" because there is
> > > > no policy. We
> > > > have already agreed some time back that in all cases, the
> > > subscription
> > > > request is immediately responded to with a 202 and a NOTIFY
> > > > with the status.
> > > > If the subscription was accepted, the status is correct. If
> > > > the subscription
> > > > failed, or was marked as pending, the NOTIFY contains
> > > > syntactically correct
> > > > but invalid data. This way, the subscriber can't know what
> > > > happened to their
> > > > subscription.
> > > I think we are in agreement here.  A doesn't get to know if
> > > he is authorized or not, subscription just fails.
> > >
> > > In particular, when B finally does authorize A, A has to
> > > "just know" to try subscribing again; we don't help him.
> > >
> > > It's always possible that the authorization mechanism tells
> > > A, say by email.
> > >
> > > Brian
> > > >
> > >
> >
> > ---
> > 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: Vasilis Polychronidis <[email-masked]>
Date: Fri, 13 Jul 2001 10:26:17 -0700

Ok I think everybody is in agreement with one (being able to subscribe to
watcher info as optional feature)
.
In principle I agree with you on 3 --> authorization can be very complicated

however Jonathan is proposing a simple use case and a simple optional way of
doing this.

I also understand your hesitation in 2 of using SIP operations as a
notification mechanism of authorization actions.
So you are asking do we want to mix SIP and authorization notifications?
In order for me to answer I have to ask another question since I have not
read all the SIP related RFC/IDs:
Is this (authorization related notifications) being proposed (via an ID) or
done in some SIP related RFC?
If the answer is yes well in that case the SIP community has answered your
question.
If the answer is No then we may need to take this question to the SIP
mailing list
and ask is this a good design?

BR,

Vasilis Polychronidis