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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 00:43:45 -0400

An additional thought below...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 7:33 PM
> To: [email-masked]'
> Subject: [Simple] Another idea for presence authorization
> 
> 
> Folks,
> 
> I was in the process of writing up the consensus to date on presence
> authorization, and I had another idea on uploading 
> authorization for the
> subscriptions. The approach is a hybrid between the intitial "post a
> document to an http URL" idea, and the AUTH or SERVICE 
> methods in SIP. 
> 
> Here's the idea. B is some presentity. B subscribes to his own watcher
> information. When A subscribes to B's presence, B gets 
> notified of a pending
> subscription. This comes in a NOTIFY carrying a watcher 
> information data
> format. This data format has, as part of its definition, URLs 
> that can be
> used to accept or reject the subscription. So, for example, B 
> would get a
> NOTIFY like:
> 
> NOTIFY sip:[email-masked] SIP/2.0
> From: sip:[email-masked]
> To: sip:[email-masked]
> Content-Type: application/watcherinfo+xml
> Event: presence.winfo
> 
> <watcherinfo>
>   <presentity uri="sip:[email-masked]">
>     <watcher uri="sip:[email-masked]" status="pending"
>                 event="subscribe">
>       <approve>http://bar.com/approve.cgi?user=A&watcher=B</approve>
>       <reject>http://bar.com/reject.cgi?user=A&watcher=B</reject>
>     </watcher>
>   </presentity>
> </watcherinfo>
> 
> 
> Now, if B wants to approve the subscription, the URL within 
> the approve tags
> is taken and used, and if it wants to reject, the one within 
> the reject tags
> is used. Of course, the http POST needs to be authenticated. 
> That can be
> done with digest over https, and the username and password 
> provided would be
> checked against the same back end database that holds the SIP 
> username and
> passwords. No document formats or anything else are generated. 
> 
> Now, the benefits of this approach are:
> 
> 1. no need to define an authorization policy data format
> 2. no need to standardize a mapping from sip URLs to http 
> URLs, which was
> one of the main (and valid) objections to the initial HTTP approach.
> 3. the server chooses the URLs for approval and rejection, 
> their structure
> has no semantics anywhere outside of the server. 
> 4. views approval and rejection as form post operations, 
> which is what they
> really are (indeed, I expect offline authorization systems to 
> be entirely
> web based, with forms as the primary tool for setting data. 
> Indeed, the same
> back end cgi scripts can be used, which is very nice)
> 
> The drawbacks:
> 
> 1. still reuqires http. Now, you could, in principle, put a 
> sip url in there
> instead of an http URL, but I think thats pushing it a bit. I 
> really think
> that this kind of thing is a form post operation. This kind 
> of mecahnism is,
> BTW, exactly how collected data is passed in VXML systems.

Thinking about this more, I think there is merit in having a SIP URL in
there, but the meaning of that is different than what people have been
thinking (but more in line with what sip is actually for). A SIP URL here
would mean that "use this to initiate a session to some IVR or something
else which will use voice prompts to authenticate you and then change the
authorization policy. So, for example, you might have:

<watcherinfo>
   <presentity uri="sip:[email-masked]">
     <watcher uri="sip:[email-masked]" status="pending"
                 event="subscribe">
       <approve>http://bar.com/approve.cgi?user=A&watcher=B</approve>
       <approve>sip:[email-masked]</approve>
       <reject>http://bar.com/reject.cgi?user=A&watcher=B</reject>
     </watcher>
   </presentity>
 </watcherinfo>

So, a client now has a choice. If http enabled, it can post the form data to
approve or reject. If its voice only, it can call the SIP URL provided. That
would go to a VXML server, which might interact with the user like this:

VXML server: "please say your username"
user: joe
VXML server: "please say or enter your pin"
user: 7654
VXML server: "to authorize the subscription from A, please say yes"
user: yes
VXML server: "thank you. User A now approved. Bye."

The VXML server would then form post the data to a web server thats managing
the authorization list.

So, really, the idea here is that there are many potential user interfaces
one might take advantage of for managing the authorization list:

1. web pages
2. custom GUI application
3. voice interaction

we want to separate the way the UI is done from the interface to the
application. For 2 of the three above (web, voice interaction), the standard
interface is already defined as http form posts. Seems natural to extend
that further to the second case, by doing what I am proposing above. 

-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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 01:23:12 -0400

> From: Robert Brown [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 12:57 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Simple] Another idea for presence authorization
> 
> 
> I think the other objection to HTTP GET was that the fact that a route
> exists that can deliver a NOTIFY SIP request to B doesn't imply that
> HTTP connectivity is possible between wherever B is and the 
> host that is
> addressed in the HTTP request.  After all, there is no guarantee that
> the entity that issued the notification has omnipotence regarding the
> firewalls or HTTP proxies between B and the HTTP servers expressed in
> the notification.

Well, unlike SIP which has known firewall and nat issues, http works pretty
darn well. I don't see this as a real problem.

> 
> Now, certainly, this would work in many cases.  But there are 
> likely to
> be situations where this assumption is not valid.

Such as?

-Jonathan R.
---

> > Sent: Thursday, June 28, 2001 4:33 PM
> > authorization, and I had another idea on uploading authorization for
> the
> > information. When A subscribes to B's presence, B gets notified of a
> > pending
> > subscription. This comes in a NOTIFY carrying a watcher information
> data
> > format. This data format has, as part of its definition, 
> URLs that can
> be
> > used to accept or reject the subscription. So, for example, B would
> get a
> > NOTIFY like:
> > 
> > Now, if B wants to approve the subscription, the URL within the
> approve
> > tags
> > is taken and used, and if it wants to reject, the one within the
> reject
> > tags
> > is used. Of course, the http POST needs to be 
> authenticated. That can
> be
> > done with digest over https, and the username and password provided
> would
> > be
> > checked against the same back end database that holds the 
> SIP username
> and
> URLs, which
> was
> > 3. the server chooses the URLs for approval and rejection, their
> structure
> which is what
> > they
> > really are (indeed, I expect offline authorization systems to be
> entirely
> > web based, with forms as the primary tool for setting data. Indeed,
> the
> > same
> sip url in
> > there
> > instead of an http URL, but I think thats pushing it a bit. I really
> think
> > that this kind of thing is a form post operation. This kind of
> mecahnism
> > is,
> > 2. doesn't allow more complex policies to be set *this* way; you can
> still
> > set authorization policy through CPLs, web interfaces, and 
> so on. This
> > mechanism would just automate the baseline case of approve/reject.
> Indeed,
> > we could even have another tag, <setpolicy>, which has a URL you can
> visit
> > for an interactive web session to set arbitrarily complex policies.
> > 
> > 
> > Comments?
> > 
> > -Jonathan R.
> > ---
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Robert Brown" <[email-masked]>
Date: Thu, 28 Jun 2001 21:56:44 -0700

HTTP connectivity is possible between wherever B is and the host that is

Now, certainly, this would work in many cases.  But there are likely to
be situations where this assumption is not valid.

For this reason it is tempting to also allow a SIP URL.  However, it
isn't clear how this can be accomplished without also pre-defining other
semantics for how the URL is to be used.  Even with HTTP we have to
define that this is a GET, but this is a pretty easy definition.

the
> document to an http URL" idea, and the AUTH or SERVICE methods in SIP.
> 
data
> format. This data format has, as part of its definition, URLs that can
be
get a
approve
reject
> tags
> is used. Of course, the http POST needs to be authenticated. That can
be
would
> be
> checked against the same back end database that holds the SIP username
and
> 2. no need to standardize a mapping from sip URLs to http URLs, which
was
structure
> 4. views approval and rejection as form post operations, which is what
> they
entirely
the
> 1. still reuqires http. Now, you could, in principle, put a sip url in
> there
think
mecahnism
still
> set authorization policy through CPLs, web interfaces, and so on. This
Indeed,
visit

---

From: "Robert Brown" <[email-masked]>
Date: Thu, 28 Jun 2001 22:47:24 -0700

HTTP works because it is uni-directional, has no routing, and is more
mature - the solutions are well understood and widely available.  SIP
works too if you configure your network right, use the right NATs, etc.
The issue is not whether or not one works.  The issue is that just
because one works doesn't mean the other does.

Such as your typical enterprise network...

There's a company called foobar.  It has a directory service containing
userid and password for all its users.  It has a DMZ consisting of a
network between two firewalls - one on the boundary of the corporate
network, one on the boundary of the Internet.  Any host within the DMZ
is regarded to be compromizable, hence the directory service can be
accessed from within foobar's corporate network, but not from within the
DMZ.  The inner firewall only permits inbound requests between specific
server pairs on specific ports - e.g. an SMTP router in the DMZ can send
to an SMTP server in the inner network.  Foobar deploys a SIP
infrastructure on its network for instant messaging and presence.  It
deploys a SIP proxy in the DMZ to route between external SIP nodes and
the internal network.  It deploys an HTTP server for authorization in
the internal network - where it needs to be so it can access the
directory service.  Everything works fine until one of Foobar's users
tries connecting from the Internet.  How does this user request an HTTP
GET to the internal HTTP server?

> Sent: Thursday, June 28, 2001 10:23 PM
> To: Robert Brown; Jonathan Rosenberg; [email-masked]
information
would
> > > done with digest over https, and the username and password
provided
Indeed,
> > > instead of an http URL, but I think thats pushing it a bit. I
really

---

From: Neil Deason <[email-masked]>
Date: Fri, 29 Jun 2001 07:16:37 -0400

We should have a SIP based mechanism. A problem for the
proposal here is that the SIP auth service requires support
for voice sessions. SIMPLE devices may not support voice and
also IM+P providers may not have VoiceXML servers in their
backend systems. Support for SIP messaging + XML seems a more
reasonable entry level for the authorization service within
SIMPLE.

As what we are looking for is a web service for
authorization I previously raised the possibility for
using WSDL ( http://www.w3.org/TR/wsdl ). I didn't
hear anything to say why this wouldn't work. In fact it
fits nicely with the idea of defining a web service
that could be accessed through both HTTP and SIP. A SIMPLE
WG XML doc defines the basic elements of the auth service.
Service providers then import this definition into the
publication a WSDL desription of their SIMPLE auth service
implementation. The service could support all of HTTP-CGI,
SOAP/HTTP and SOAP/SIP intefaces. (WSDL can already describe
how services are made available through HTTP-CGI and SOAP/
HTTP. Service bindings for SOAP/SIP would need to be added).
We could standardize what mechanism(s) a min impl must support.

I gave an example of a definition of the service elements
for the service and how a service provider would make the
service available through SOAP/HTTP before.
http://mailman.dynamicsoft.com/pipermail/simple/2001-June/000257.html
The WSDL spec has an example of a HTTP-CGI service at
the end. The Definition SIP/SOAP bindings would be close to
the existing HTTP/SOAP ones.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: 29 June 2001 05:44

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 11:13:22 -0400

> Sent: Friday, June 29, 2001 1:47 AM

VPN. The scenario you are describing is why VPN was invented. Many other
applications will have the same problem you describe.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 11:49:20 -0400

> Sent: Friday, June 29, 2001 11:37 AM
> > VPN. The scenario you are describing is why VPN was invented.
> 
> No it isn't.
> 
> VPN won't work.  For example the foobar user is a consultant or
> supply-chain partner sitting in a customer's network behind their
> firewall.  It is all too common for outbound PPTP to be blocked.

If the user is not served by the foobar domain, why would they be sending
their authorization information to the foobar server?

Also, lets assume its all SIP. I'm hoping you're still in favor of
authenticating these SIP messages. That requires access to the DB inside the
corporate network. So, the proxy in the DMZ forward the request to the
server inside the network. Can you explain why that doesn't work for http?
There is an http proxy in the DMZ, and it forwards HTTP requests to the HTTP
server inside the corporate domain. Granted HTTP cannot do complex routing,
but we're not talking about that.

-Jonathan R.
---

> > Sent: Friday, June 29, 2001 8:13 AM

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 29 Jun 2001 08:36:37 -0700

No it isn't.

The solution needs to work in SIP.

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 29 Jun 2001 17:01:49 -0700

I agree.

There are two proposals here:
(1) - SOAP over SIP
(2) - Using WSDL to describe services implemented in (1)

Implementors would adhere to (1) and have the option of doing (2)

SOAP over SIP will enable any scenario that could alternatively be done
with HTTP, but without additional infrastructure or complexity.

WSDL can be published by a product/service for the purposes of
describing the services it implements.  Watcher authorization would be
one such service.

> From: Neil Deason [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 4:17 AM

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 3 Jul 2001 01:24:50 -0400

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 11:19 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] Another idea for presence authorization
> 
> 
> > instead of an http URL, but I think thats pushing it a bit. 
> I really think
> > 2. doesn't allow more complex policies to be set *this* 
> way; you can still
> > mechanism would just automate the baseline case of 
> approve/reject. Indeed,
> > we could even have another tag, <setpolicy>, which has a 
> URL you can visit
> I can see value in this approach for simple yes/no decisions. 
> However, I 
> do not think benefits 1 and 2 really apply, as we would 
> _still_ need the 
> method for pushing policy outside of the context of a subscription 
> request. For example, if I using the above approach choose to 
> disapprove 
> your subscription to me(assuming you mean for that decision to be 
> sticky) how could I change my mind tomorrow and allow you access? 

Sure. The million dollar question is - how will you do that? Will it be from
a browser type of thing? Or do we need to define a custom protocol for the
whole thing? I would argue that because this policy can be arbitrarily
complex, the ideal solution is not to specify a protocol or document for it,
but simply use web forms or voice prompts. This leaves a lot of flexibility
in how the policy can be specified, without requiring standardization. You
need a protocol only when automata are going to be setting the policy, and I
just don't see automata setting complex authorization policies. People will.

I 
> assume that I would not be notified for every _denied_ subscription.
> That requirement alone suggests that _every_ (or at least 
> most) presence 
> system must have a way for pushing policy at any time, not _just_ in 
> response to a pending subscription. If this is true, then we 
> also need 
> to standardize the method and formats of pushing policy at any time.
> 

Right. Thats all part of the watcherinfo package. I've come up with a basic
state machine for generic subscriptions, so that notifications are sent on
the transitions of this machine. One of the transitions is due to rejected
subscriptions, so that you'd get a notification of that.

-Jonathan R.
---

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 3 Jul 2001 12:00:15 -0400

Maybe one of the issues that is causing confusion is that
there are actually two "subscription" kinds of things.

One is the one where you get the human involved - will you
as presentity allow so-and-so as watcher presence information
(along with what kind/how often/....).  That has a possible
long delay, and lots of policy, and, as Jonathan has pointed
out, possibly no protocol.  When you decide, a database records
your choice, but there is no SIP.

Then you get right down to the actual user agent trying to
get the Notifies to come.  That too is a "subscription",
but it happens AFTER the former thing, has no UI, no delay,
no policy, and very much is a protocol thing.

Let's keep them straight.  Maybe we need some terminology:

Suppose we call the first "authorization" and the other 
"subscription".  Both have to be authenticated.  Thus you
would have to be authorized before you could subscribe.

Brian

Brian

> Sent: Tuesday, July 03, 2001 1:25 AM
> To: Ben Campbell; Jonathan Rosenberg

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 4 Jul 2001 12:21:01 -0400

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2001 12:00 PM
> To: 'Jonathan Rosenberg'; Ben Campbell

The complexity is that one (subscription) will frequently need to trigger
the other (authroization). That is, when someone suscribes to me for the
first time, there is no authorization policy. In order to make a yes/no
decision on the subscription, the particular application scenario might
require that I be notified of the subscription in order to generate an
authorization decision. So, the authorization policy here is
"pseudo-real-time", in the sense that its triggered based on a subscription.

However, because, ultimately, its still the process of providing
authorization, and also, still may not happen immediately after the
subscription arrives, I like the model of having a single mechanism for
providing authorization. That mechanism is server specific, I argue, and
ideally done through web interfaces. By providing the URL to give
authroization, the process can be facilitated and can even be done without a
browser, for simple cases at least. More complex policy is going to be too
complex to do in a protocol.

-Jonathan R.

---

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Jul 2001 13:13:16 -0400

Of course.  What is the point?
Every failure of the subscribe would return the URL
to a page that would authorize.  It wouldn't matter if
there was or wasn't authorization.  Denied authorization
wouldn't be distinguishable from failed or not attempted
authorization.

It seems to me that trying to put a human in a protocol 
loop is a bad design decision.  The subscription results should
be immediate.  The decision to seek authorization, and its
success or failure, is not really something that needs to be,
or should be standardized.   What you want is the immediate
subscription to the presence to work between arbitrary
presentities and watcher/fetchers.  The failure of
subscription, we agree, should not reveal why.
	
Brian
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 11:47 AM
> To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell
> Cc: [email-masked]
> > Why can't the request to subscribe fail if there is no
> > authorization?  Provide the URL in the response.
> 
> Largely because it's crucial that an unauthorized subscription,
> a denied subscription, and a subscription to the presence of
> an offline user be completely and utterly indistinguishable
> from the point of view of the subscriber.
> 
> /a
>

---

From: "Boyer, D G (Dave)" <[email-masked]>
Date: Tue, 10 Jul 2001 10:32:30 -0400

> Sent: Monday, July 09, 2001 1:13 PM
> To: [email-masked]'; 'Jonathan Rosenberg'; Ben Campbell

Isn't this a policy decision that should be let up to the application?
In some implementations it is allowable and useful to
let a user know why their subscription failed.

Dave Boyer

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2001 10:38:05 -0400

It's clearly a choice, but there are indeed nasty security problems that
arise because information leaks that is intended to be helpful in diagnosing
a problem, but instead is used by J. Wiley Hacker to debug his hack.
Usually best to silently fail.
 
Brian

-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; [email-masked]'; 'Jonathan Rosenberg'; Ben
Campbell

> From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Dave Boyer 

> > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > from the point of view of the subscriber. 
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>  
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>

---

From: "Boyer, D G (Dave)" <[email-masked]>
Date: Tue, 10 Jul 2001 10:47:56 -0400

Hi Brian,
 
I am trying to get up to speed with this.  I see where you are coming from
with this, but
I still have a question or three.
From your answer below it appears that  a subscription to the presence of an
offline
user and a subscription to a user who deny you access would lead to the same
response.
There will presumably be implementations that deal with the offline
subscription problem; won't they
need to have a different response from the case when a user tries to make an
unauthorized subscription?
 
Thanks
Dave

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:38 AM
To: 'Boyer, D G (Dave)'; Rosen, Brian; [email-masked]'; 'Jonathan
Rosenberg'; Ben Campbell

Brian

-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; [email-masked]'; 'Jonathan Rosenberg'; Ben
Campbell

Dave Boyer

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2001 11:01:33 -0400

Well, some of us may question what the proper response to an "offline"
user subscription request might be.  I would say that the subscription is
accepted, if authorized, and you get a presence status that could be
"off line", or something else ("not available" perhaps).  That would be
very handy if the presentity subsequently became available.  YMMV,
but existing systems do that.
 
If you did want offline to return something that was an "error" when
someone subscribes, AND the watcher/fetcher is authorized, then
I'd say that wasn't much of a security issue. 
 
Still separates "authorization" from "subscription", which is the main point
of the thread.
 
Brian

-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:48 AM
To: 'Rosen, Brian'; Boyer, D G (Dave); [email-masked]'; 'Jonathan
Rosenberg'; Ben Campbell

Hi Brian,

Thanks
Dave

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:38 AM
To: 'Boyer, D G (Dave)'; Rosen, Brian; [email-masked]'; 'Jonathan
Rosenberg'; Ben Campbell

Brian

-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; [email-masked]'; 'Jonathan Rosenberg'; Ben
Campbell

Dave Boyer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Jul 2001 17:37:55 -0400

Brian, 

A lot of different things are being confused here. From your original
response:

> Get authorized, try subscribing again.
> 
> Brian

This is not right. The party that approves or denies the subscription is NOT
the party that has subscribed.

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

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

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. 

Hope that clarifies things.

-Jonathan R.

---
  
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 11:02 AM
To: 'Boyer, D G (Dave)'; [email-masked]'; 'Jonathan Rosenberg';
Ben Campbell

Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:48 AM
To: 'Rosen, Brian'; Boyer, D G (Dave); [email-masked]'; 'Jonathan
Rosenberg'; Ben Campbell

Hi Brian,

Thanks
Dave
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:38 AM
To: 'Boyer, D G (Dave)'; Rosen, Brian; [email-masked]'; 'Jonathan
Rosenberg'; Ben Campbell

Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; [email-masked]'; 'Jonathan Rosenberg'; Ben
Campbell

---

From: Subir Saha <[email-masked]>
Date: Tue, 10 Jul 2001 16:36:50 -0700

Brain:
By sending the URL with a response to failed subscribers, are we not
indicating that he is being denied to subscribe as opposed to silent
rejection? Or we include the URL every time.

Subir

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 3: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.

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

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

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

> but invalid data. This way, the subscriber can't know what 
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

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Jul 2001 08:41:45 -0400

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.

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

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.

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

Of course if there were, my argument still holds - it's
within one implementation, not subject to standardization.

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

> 
> 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. 
Well of course if the behavior you want is that authorization is
automatic, and what you get is a constant presence indication of
some form of "not available", fine, your presence system allows
anyone to subscribe any time.  That means the subscription never
fails, and you don't see my URL.  A policy choice, which I would
certainly support.  Seems to be lots of opportunity for DoS
attacks, but if you get flooded with SUBSCRIBEs that fail, that
is a form of DoS attack too.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Jul 2001 08:46:30 -0400

Policy choice.  You can:
1. Fail and return the URL
2. Fail silently
3. Succeed and return constant status

Brian

> From: Subir Saha [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 7:37 PM
> To: 'Rosen, Brian'; 'Jonathan Rosenberg'; 'Boyer, D G (Dave)';

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Jul 2001 10:37:20 -0400

Jonathan,

Why is this so hard?  It seems there are three separate processes here:

A:  Authorization - between system and authorizer
B:  Subscription - requestor and system
C:  Notification - presentity and subscriber

C won't happen without B won't complete without A.
Only C should be reveal presence.

If X subscribes, they get a response saying "your request has been 
accepted, you'll know it worked when you start getting notifications."

Variation:  If X subscribes and was already authorized, response says "you 
were previously accepted."  Says nothing about when that occurred.  Note 
this should not be done for rejections, as consecutive pings by X could 
detect when X went from accepted to rejected, indicating presence at least 
momentarily.

When the authorizer logs in, they accept (authorize) or reject requests.

Notifications occur based on authorized subscriptions.

Have I missed something?

Mike

At 09:58 PM 7/10/2001 -0400, 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:
>
>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
>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
>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
>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.
>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
> > Sent: Tuesday, July 10, 2001 6:18 PM

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Jul 2001 13:53:49 -0400

At 01:36 PM 7/11/2001 -0400, Jonathan Rosenberg wrote:

> > From: Michael Hammer [mailto:[email-masked]]
> > Sent: Wednesday, July 11, 2001 10:37 AM
> > To: Jonathan Rosenberg
> > Cc: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)';
> > [email-masked]'; Ben Campbell;
>Well, the notification is really between the system and the subscriber, but
>thats a nit.
>
> >
>That is what is specified now, yes.
>
> >
>Yes. You say:
>"when the authorizer logs in, they accept (authorize) or reject requests".
>
>How does the authorizer know whether there are subscriptions waiting to be
>authorized? Sure, the system can send the authorizer email, or an IM, but
>that means there is no way to manage that information on the client side
>using an automata which queries the user, or applies local policy to
>generate an authorization. I'm interested in this primarily because that is
>what systems do today. When I start Yahoo, it tells me who has tried to
>subscribe, and allows me to accept/reject each of those. Are we willing to
>say that a tool cannot be written that queries the user for this, that the
>only way is to send email or IM or something else which is only
>interpretable by a human? Not that using IM or email is bad; just that we
>may want to enable an automata to handle the information.

I should have described the transaction there.  I believe that is related 
to the watcherinfo stuff you were working on.  I was viewing that as part 
of A above.  Once you log into the system, the authentication process sends 
you a message indicating who requested subscription and your response 
contains the authorize/deny per request.  The key is that A, B, and C are 
independent transactions only related together by the system application.

Mike

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Jul 2001 14:25:14 -0400

Well, I'm real confused.  
1. The "automata" you are talking about -- I don't understand
what role it has in the context of this discussion.  We have
"servers" that have presence information and "clients" that
want to get it.  The server is an entity operating on behalf of a
presentity.  The client is an entity operating on behalf of a watcher.  In
SIP terms, we have a UAC and a UAS.  The UAS
is the agent of the presentity, and the UAC is the agent of
the watcher.  Now, where is this automata?  In the UAS?
The UAS is what the protocol defines, you seem to want to deal
with something that is not the UAS but is connecting to it.

At the moment, the model I'm imagining in your head is one
where the presentity and the watcher are both UACs and there
is a centralized UAS - the sort of AIM/Yahoo/MSN messenger
idea.  If that is the model you are pushing, I want to push
back.  The UAC is the agent of the presentity, the UAS is the
agent of the watcher, and the UAC doesn't need any protocol
to the presentity -- it "is" the presentity.  If you want
the presentity to be a UAC, then we need more than what we
are talking about on this thread - we need to standardize
how the UAC at the presentity tells the UAS how to change its
presence, and then we get into all sorts of issues about 
how this model supports rich presence information (since it
requires that two UACs AND the UAS all have the same
capabilities).  How the UAC interacts with the presentity
is not the place we standardize.  It could be split into
a "client" and a "server", but the interactions between those
pieces are complex, and I don't see how we could standardize
them right now.

2. I never used Yahoo Messenger.  I just loaded it.
Yes, you get a message when someone puts you in his
friend list.  However, what it is asking you seems to be
whether you want to put him in YOUR buddy list.  In particular,
if you reject, you are still in his friend list, and he sees
your presence.  You cannot hide your presence from someone.
You can hide your presence from everyone, and you can ignore
messages from selected people.  

Brian

> Sent: Wednesday, July 11, 2001 1:50 PM
> To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)';
> > Sent: Wednesday, July 11, 2001 8:42 AM
> 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.
> 
> > 
> I think I've addressed this above. Email or IM content is not 
> processed by
> automata. 
> 
> > 
> 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.
> 
> > 
> > > 
> 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.
> 
> 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.
> 
> ---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 17:30:28 -0400

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

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

> While there could be other ways, having one standardized way 

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.

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

> not all.  However, it doesn't matter because it's entirely in

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.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 17:35:40 -0400

Yes. You say:

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 10:03:01 -0400

> Sent: Wednesday, July 11, 2001 2:25 PM
> SIP terms, we have a UAC and a UAS.  

Its more complex than that, Brian. 

I'll repeat the picture I just sent in a previous email:

         |                  |                      |
         |                  |SUB B's pres.winfo (1)|
         |                  |<---------------------| B's client turns on
         |                  |200 OK             (2)|
         |                  |--------------------->|
         |                  |NOTIFY             (3)|
         |                  |--------------------->|
         |                  |200 OK             (4)|
         |                  |<---------------------|
         |                  |                      |
         |SUB B's pres  (5) |                      |
         |----------------->|                      |
         |202 Accepted   (6)|                      |
         |<-----------------|NOTIFY "A Pending" (9)|
         |NOTIFY B's pres(7)|--------------------->|B learns that A
         |<-----------------|200 OK            (10)|      subscribed
         |200 OK         (8)|<---------------------|
         |----------------->|                      |
         |                  |                      |
         |                  |                      |
         |                  |Set policy        (11)|
         |                  |<---------------------|
         |                  |                      |
         |                  |                      |
         |                  |                      |
         |                  |                      |

      Subscriber          Presence              Presentity
         A                Server                   B

> The UAS

There is a presence server, which is a UAC for some transactions, and UAS
for others. There is a subscriber A, which is a UAC for some transactions
(the SUBSCRIBE) and UAS for others (the NOTIFY). There is a presentity
application for B, which is a UAC for some transactions (SUBSCRIBE to its
watcherinfo), and a UAS for others. Remember, UAC/UAS is a per transaction
role. The presence server is the "agent" for B, in the sense that it accepts
subscribes and generates notifies on B's behalf. How it finds out about the
presence state is another orthogonal piece, not specified in the SUB/NOT
mechanism. Typically, its through registrations or through direct upload of
a presence document.

> to the presentity -- it "is" the presentity.  

I cannot map these statements to sensible definitions of UAC and UAS,
presentity or watcher. Please see above.

> If you want

I still cannot understand any of the above based on the definitions of UAC
and  UAS in the bis spec, and presentity, watcher, etc. from rfc2778.

> your presence. 

No, thats not true. When I subscribe to someone, they appear in my buddy
list, and the status is marked as "pending authorization" until the time
that they provide authorization. Once that happens, I see their real
presence. On the other side, when someone subscribes to me, I get a screen
pop, which asks for "approve", "approve and add", or "reject".
Approve/reject have the meanings we've been discussing - they approve or
reject the subscription. "approve and add" approves the subscription, and
also sends a subscription from me back to them, adding them to my buddy
list. 

I've been using this tool for several years. I think I can make these
statements with soem confidence that they are correct.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 10:14:43 -0400

> Sent: Friday, July 13, 2001 8:17 AM
> To: 'Vasilis Polychronidis'
> Cc: Jonathan Rosenberg; 'Boyer, D G (Dave)'; 
> [email-masked]';
> Ben Campbell; [email-masked]
> 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

This is the piece I am most interested in doing, and previously, the piece
that I thought you were objecting to. This covers 90% of what I think we
need.

> 
> 2. Can you subscribe to something that gets you Notification
>    that you have some authorization effort to make?

I'm not proposing quite that; I'm proposing that when you get notified that
a watcher subscribes, from (1) above, that notification tells you what
happened to the subscription - whether it was accepted, rejected, or marked
as "pending", because the presence server could not make a decision, as
there was no policy specified.

If the user sees that someone subscribed to them and was marked pending
because there was no policy, they can go to the web page at their leisure,
and provide some policy, or use an IVR system, or whatever. However, none of
those allow for the application on the user's PC (assuming its runnig) to
provide authorization automatically, or the the application on the user's PC
to perform a screen pop that queries the user, and based on what button is
pressed, provide authorization. I agree that in many cases this is NOT
sufficient, since the subscriber will need to know more than who the
subscriber is, and will need to give more details about the policy for
handling the subscription. I agree that in such cases, it is ideally handled
through user interactions like web pages or voice response. 

However, I think there is value in allowing the basic operation to be
automated, and then requiring human interaction for the complex cases.

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

We need standards whenever we want communications between two entities that
are separated over the network.

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

Again, I cannot understand this based on my understanding of the terms UAC
and UAS.

> 
> 3. Is a pair of URLs the way to represent an accept/deny 
>    authorization decision?
> 	I'd say, no, not by a whole lot.  

In many cases, you are correct. I am not arguing that it be the ONLY way.
I'm arguing that it be A way.

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

Agreed. But, I argue that there is a common enough case for existing
applications that will allow us to provide a simple interface for the simple
things, and let the more complex cases remain unstandardized through web/IVR
interactions (or possibly even CPLs...).

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 09:48:23 -0400

> Sent: Wednesday, July 11, 2001 1:54 PM
> To: Jonathan Rosenberg
> Cc: Jonathan Rosenberg; 'Rosen, Brian'; Jonathan Rosenberg; 
> 'Boyer, D G
> (Dave)'; [email-masked]'; Ben Campbell;

I haven't been saying anything different!!!

What I am proposing is that things look like this:

         |                  |                      |
         |                  |Set policy ?      (11)|

The SUBSCRIBE from the subscriber A is messages 5-8. The two transactions
(SUB/202 and NOT/200) are totally independent from everything else. It does
NOT wait on human intervention or anything else, PERIOD. It is regular,
normal, SUB/NOT for presence, with each of the two transactions completing
instantly.

Before this subscription, when B's client was activated, it send a subscribe
to the presence server, to watch to see who subscribers to B. Thats sequence
(1)-(4), two SIP transactions. Now, when A subscribes, INDEPENDENTLY of the
processing that subscription, the presence server sends a NOTIFY to B,
telling them of the change (messages 9-10). 

Now, after that there are no pending transactions, or anything like that. At
some point, indefinitely into the future, B can send policy about A to the
presence server, message(s) 11. I've been arguing that we should NOT specify
SIP for this, but rather, view this as a web application that sets
potentially complex policy. However, I have also been arguing that it would
be nice to allow this to provide the most common and basic function,
approval/rejection, without a web browser. This would be needed, for
example, if I want the application software at B to provide a screen pop
when A subscribes, with two buttons "accept" and "reject". Clicking either
approves or rejects the subscription. Thats still an HTTP request, I am
arguing, but it doesn't require B to have a user filling in a form. The
client application at B can figure out what HTTP form POST request to send
to approve or reject, based on information in the NOTIFY, message (9).

-Jonathan R.
---

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Jul 2001 15:04:30 -0400

Hmmm, I didn't look at Jonathan's diagram close enough.
I would think that A would not get a Notify until
after B authorized.  So, message (7) can't happen
until after (11).  Is that what you mean?

Brian

> From: Daniel Starin [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 2:58 PM
> To: 'Rosen, Brian'
> Cc: 'Jonathan Rosenberg'; [email-masked]
> That's the thing... I think Jonathan says that an initial 
> notify will be
> sent in step 7 of his diagram.... "NOTIFY B's pres"..... before
> authorization... as far as I can tell.  I agree with his 
> diagram in that
> policies should be set at any time... but I think that initial notify
> needs some authorization....
> 
> Dan
> 
> Sent: Friday, July 13, 2001 2:44 PM
> To: 'Daniel Starin'
> Cc: 'Jonathan Rosenberg'; [email-masked]
> I think we are agreeing that you can subscribe without
> authorization.  I think we agree that you don't get any
> Notifies unless you are authorized.
> 
> I do note in Jonathan's text that he used 202 for the
> actual presence subscription acceptance, but 200 for
> watcherinfo.  I don't quite understand that - it seemed
> to be either an information leak, or some kind of a typo.
> 
> We could hold a discussion on DoS.  The issue is which is 
> better - lots of subscriptions that succeed, or lots of
> subscriptions that silently fail?  If you explicitly fail
> (not authorized), information leaks - not good.
> 
> Brian
> 
> > From: Daniel Starin [mailto:[email-masked]]
> > Sent: Friday, July 13, 2001 2:37 PM
> > To: 'Rosen, Brian'
> > Cc: 'Jonathan Rosenberg'; [email-masked]
> > If I understand correctly,  you and Jonathan have come to a 
> consensus
> > that an initial Notify (specifying presence information) 
> > should be given
> > without authorization?  This seems to me to be similar to the 
> > AIM model
> > in which user A may add user B to a buddy list without 
> authorization.
> > User B may later set a specific policy on user A (like 
> blocking them).
> > 
> > If this is the case,  I disagree with both of you and I believe that
> > rfc2779 (the presence requirements) does as well.  It 
> specifies.. "The
> > principle controlling a PRESENTITY MUST be able to control which
> > WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By
> > allowing any random watcher to access even one Notify without
> > authorization, this requirement is not met...
> > 
> > Dan
> > 
> > [mailto:[email-masked]] On Behalf Of 
> > Rosen, Brian
> > Sent: Friday, July 13, 2001 1:46 PM
> > To: 'Daniel Starin'
> > Cc: 'Jonathan Rosenberg'; [email-masked]
> > Daniel
> > I suppose it's a matter of semantics, but I would claim 
> > that you change authorization to change what information is 
> revealed.
> > Whether you do it before subscription, or after it, 
> > you are changing your authorization.
> > 
> > I also think you made my point.  Authorization is complex,
> > and standardizing it, at this time, is unwise.
> > 
> > Of what use is it to the PS if I give it a yes/no,
> > and don't give it a what?  So you can accept the
> > subscription but not send a Notify?  Not interesting
> > methinks.  Besides, as you observe, even yes/no is really 
> > transient (yes, at the moment, but I could change my mind).  
> > All the more reason to get it out of the protocol.
> > Even Jonathan proposes to accept the subscription without
> > authorization.
> > 
> > We are talking about a complex interaction between the watcher
> > and the PS as well as the presentity and the PS.  Until
> > there is a much greater degree of consensus on how that
> > interaction takes place, I don't see the value in
> > specifying any of it.  Jonathan wants to standardize a simple
> > yes/no authorization so that it can be done in the GUI of
> > B's UA, and not take a browser.  I think that such an idea
> > is far too limiting to be useful, and encourages lowest
> > common denominator thinking.  It doesn't even give you
> > the basic notion of presenting the name of the watcher - 
> > all you get is the existing SIP headers, which would in
> > many cases be a cryptic email identifier.  I'd much rather
> > go the other direction and start talking about sending
> > an XML credential in the authorization request, and an
> > XML policy in the authorization reply.
> > 
> > BTW, I wanted to make sure that everyone agrees that
> > authorization is not authentication;  if the PS requires
> > authentication for the subscription (and it ought to),
> > then authentication must take place before the subscribe
> > will be acted upon.  All authorization is dealing with is
> > what B will let you see, and it ranges from nothing to
> > a lot.  Authentication is proving to the satisfaction
> > of the PS that you are who you claim to be.
> > 
> > Brian
> > 
> > > From: Daniel Starin [mailto:[email-masked]]
> > > Sent: Friday, July 13, 2001 1:05 PM
> > > To: 'Daniel Starin'; 'Rosen, Brian'
> > > Cc: 'Jonathan Rosenberg'; [email-masked]
> > > Revised.... I hit send by accident...
> > > 
> > > The difference is, when I authorize someone, the way that 
> I interact
> > > with them may change throughout the time that the 
> > subscription exists.
> > > One minute I may want them to see detailed presence (IN / OUT /
> > > AWAY / BUSY) while the next minute I may want them to see OUT 
> > > regardless
> > > of what my actual presence is.  The fact is, for the most 
> > part, these
> > > decisions are based on what is happening currently, not 
> what happens
> > > when the request for the subscription takes place.  At the time of
> > > request, all that is usually known is Yes, you may subscribe, 
> > > or no, you
> > > may not.  If you happen to know that you also want to give 
> > > the person a
> > > specific type of presence (IN / OUT) at that time than so 
> be it, you
> > > can (after you have said Yes to their subscription).  But 
> > many times,
> > > you will not know specifically how you want your presence to be
> > > distributed to those that subscribe to you at the moment they 
> > > request a
> > > subscription.
> > > 
> > > Thus a Yes/No authorization should be specified.  
> Possibly a "what"
> > > should be specified as well but these two things should 
> be distinct.
> > > 
> > > As for credentials.  I agree that some form of credentials must be
> > > specified for Yes / No authorization...
> > > 
> > > Dan
> > > Sent: Friday, July 13, 2001 12:05 PM
> > > To: 'Daniel Starin'
> > > Cc: 'Jonathan Rosenberg'; [email-masked]
> > > I don't agree.  Authorization is specific - who and what.
> > > You can't split it up like that, or at least there is very
> > > little value in doing so.  If I gave you a standardized way
> > > to say yes/no, but don't give you a standardized way to
> > > specify what, the implementation is just as proprietary.
> > > 
> > > Also don't forget the credentials part.  In order to even say
> > > yes/no, you need the credentials.
> > > 
> > > Brian
> > > 
> > > > From: Daniel Starin [mailto:[email-masked]]
> > > > Sent: Friday, July 13, 2001 11:59 AM
> > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'
> > > > It seems that there are two different issues you are 
> discussing.  
> > > > 
> > > > One is whether or not A (the watcher) may access any of 
> > B's presence
> > > > information (a binary decision) and the other is IF B indeed 
> > > > allows A to
> > > > access presence information, what type of information will 
> > > that be, -
> > > > In/Out, In / Busy/Out, etc.
> > > > 
> > > > Regardless of what complex presence information a user may 
> > > have, there
> > > > will always be an initial binary decision (yes, you can 
> > > > access presence
> > > > or no, you cannot).  Because this decision must always be 
> > > > made for each
> > > > and every subscription request which is made, it may be 
> > > reasonable to
> > > > standardize how this will be done.
> > > > 
> > > > -Dan
> > > > 
> > > > [mailto:[email-masked]] On Behalf Of 
> > > > Rosen, Brian
> > > > Sent: Friday, July 13, 2001 10:44 AM
> > > > To: 'Jonathan Rosenberg'
> > > > Let's start over.
> > > > A and B are both UAs.  I think we all agree on that.
> > > > You want a PS.  I'll agree they are useful.  If you
> > > > want a PS, then its a UAS to A.  I want to talk
> > > > about how PS and B interact.
> > > > 
> > > > I don't know if you would allow me to go there, but,
> > > > just for a moment, indulge me and let's talk about
> > > > A and B without PS.  A wants to know B's presence.
> > > > Okay, so A subscribes to B, and B supplies
> > > > presence as NOTIFYies.  This all works fine, although
> > > > it ignores how B authorizes A.  In particular,
> > > > in order for B to authorize A, he needs credentials
> > > > for A (who are you).  While the standard SIP headers
> > > > might be enough, in many cases, you need more 
> > > > information about A.  How do you get that?
> > > > 
> > > > With my example, everything (except credentials) is
> > > > fine.  In particular, B can send presence to A
> > > > because it's really B (B's real UA) that is the
> > > > source of the presence info, and we would all agree
> > > > that B the human interacts with B's UA in some
> > > > implementation dependent manner for B's UA to
> > > > find out the actual presence state.
> > > > 
> > > > Are we okay here?
> > > > 
> > > > Now let's put in the PS.  In your model, just for now,
> > > > skip authorization, and let's just talk about how
> > > > B tells PS that B's presence state changed.
> > > > I can see two possibilities.  The one I like is that
> > > > PS subscribes to B's presence.  The other is that
> > > > there is a new header that is used for that purpose.
> > > > My way is real simple, takes no extension, and does
> > > > exactly what you want.  When B changes his presence,
> > > > he does so on his UA (exactly as above), and Notifies
> > > > PS.  PS, in turn, Notifies A.  Simple, clean, effective.
> > > > 
> > > > So what is PS?  I claim it's a straightforward
> > > > B2BUA.  Instead of subscribing directly to B, PS
> > > > subscribes to B and A (as well as any other authorized
> > > > watchers) subscribe to PS.
> > > > 
> > > > Now, you introduce watcherinfo.  I'm okay with that.
> > > > B subscribes to watcherinfo on PS, and PS Notifies B
> > > > of subscriptions.  
> > > > 
> > > > Now, back to authorization
> > > > 
> > > > In several posts, I've stated that I'm interested in a
> > > > rich notion of presence.  That covers a LOT of territory,
> > > > but let me give you a small example.  Suppose I have
> > > > 3 states in my presence model In-Busy-Out.  For
> > > > some watchers, I will give them one of these three
> > > > states.  However, there are some people for whom I
> > > > don't want them to know that I'm in, but busy.  They
> > > > only get two states - In/Out.  This is all pretty easy
> > > > stuff. 
> > > > 
> > > > However, my authorization is not binary.  I have to
> > > > tell PS which of the two models A gets.  Two URLs
> > > > are not enough.
> > > > 
> > > > So, authorization, I claim, is complex.  You need
> > > > arbitrary credentials from A, and you need arbitrary outputs
> > > > from B. Thus, I claim, there is no sensible way to define the
> > > > authorization process between B and PS, or for that
> > > > matter, between A and PS in a standardized way.
> > > > 
> > > > One way to help would be to at least tell A where 
> > > > to go to at least FIND OUT how to get authorization.  
> > > > Simply subscribing (attempting to subscribe) is not enough.
> > > > If you want to turn that around and say, fine, let's
> > > > also tell B how to authorize, I can't argue.
> > > > 
> > > > Brian
> > > > 
> > > > 
> > > > > Sent: Friday, July 13, 2001 10:03 AM
> > > > > > presentity.  The client is an entity operating on 
> behalf of a 
> > > > > > watcher.  In

---

From: Michael Hammer <[email-masked]>
Date: Fri, 13 Jul 2001 16:28:38 -0400

In an earlier email Dan (I think) implied that an additional transaction to 
complement the "Set" method would be needed, namely a "Fetch" where the PS 
knows that before it sends out notifications of presence it should get a 
policy update.  Would this presume that the human has already modified the 
policy prior to allowing the Sub indicating presence?

Actually, this could be avoided if the initial contact by B to the PS 
includes that policy update.  Is that what was contemplated?

Mike

---

From: Michael Hammer <[email-masked]>
Date: Fri, 13 Jul 2001 16:06:27 -0400

Jonathan,

I don't think I am in disagreement, but diagram below is modified slightly 
to represent what I am understanding from this thread.

Mike

At 09:48 AM 7/13/2001 -0400, Jonathan Rosenberg wrote:

>          |                  |--------------------->| B notified of other
>          |                  |200 OK             (4)| parties presence
>pending  |<-----------------|NOTIFY "A Pending" (9)|
>state    |                  |--------------------->|B learns that A is
>          |                  |200 OK            (10)| requesting subscription
           |                  |                      |Terminal-human 
interaction
           |                  |                      |to auth and set 
permissions
>          |                  |SET? policy       (11)|
>          |                  |<---------------------|Application-specific 
> controls
           |                  |200 OK                |uploaded
>          |NOTIFY B's pres(7)|                      |
>success  |<-----------------|                      |A gets notified if B's 
>control
>or fail  |200 OK (8)        |                      |conditions are met, 
>else some
>state    |----------------->|                      |notify of status from 
>pending
>                                                     to subsciption 
> success or fail

In the previous version, it was not clear whether presence was being 
sent.  Hope this clarifies that.  Subscription pending can be assumed.  No?

---

From: "Daniel Starin" <[email-masked]>
Date: Fri, 13 Jul 2001 17:20:20 -0400

There is no difference... that makes sense...

IMO, required functionality with respect to this thread must allow for 

1. the PS to request that B sets a policy if none exists for a given
watcher who has subscribed
2. the User being watched to be able to set a policy in advance (he may
wish to allow anyone from a particular domain to automatically subscribe
with a particular policy)
3. the User being watched to be able to change the policy at any given
time after a policy has been set
4. the User to be able to subscribe or not to any of these notifications

And with respect to the Yes / No discussion I had with Brian... 

No policy being set on the PS by User B means to User A either that his
subscription is pending or that it has been rejected, this allows User B
to reject the subscription without giving away any of his presence.

Dan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, July 13, 2001 4:21 PM
To: 'Daniel Starin'
Subject: RE: [Simple] Another idea for presence authorization

What is the difference between a yes with no policy
and nothing?

You send 200 OK to the subscribe before you have yes/no
You don't send Notify until you get policy.

If you got a no, how would you treat it differently than
a yes with no policy?

There is nothing you can do with the yes/no without
policy except admire it.

Brian

> Sent: Friday, July 13, 2001 4:12 PM
> To: 'Rosen, Brian'
> Yes that's what I mean... 
> 
> Some authorization must occur before a Notify may be sent...
> 
> From what I understand....
> 
> - Authorization must occur before notification
> - Policies for the distribution of presence to a particular 
> Watcher from
> the PS may be set or modified at any time... before or after a
> subscription request and these policies could be arbitrarily 
> complex...
> (in the before case... you may say to your PS that all of
> sip:[email-masked] has authorization to subscribe to you with a
> specified policy)
> 
> - The only aspect of the authorization for subscription process which
> can be strictly specified for any and all subscription 
> requests is that
> the subscription will be accepted or denied.  If accepted, 
> the accepting
> UA has the responsibility to set a policy (the UA may already have a
> policy in place... see above).  If rejected, no notifications of
> presence may be sent and it must not be possible for the requesting UA
> to infer any presence information.
> 
> From these understanding... I come to the conclusion that we 
> can either
> specify a yes / no format and leave policies to be specified 
> at another
> time or specify a complete policy format.
> 
> IMO, I feel that there is something different between policy 
> (which can
> be set or updated at any time and defines the type of 
> information which
> will be sent to a subscribing user) and the initial yes / no response
> (which specifies if any information at all will be sent to a user)....
> 
> Comments?
> 
> Dan
> 
> 
> 
> 
> Sent: Friday, July 13, 2001 3:05 PM
> To: 'Daniel Starin'; 'Jonathan Rosenberg'
> > > > > > for others. There is a subscriber A, which is a UAC 
> for some 
> > > > > > transactions
> > > > > > role. The presence server is the "agent" for B, in 
> the sense 
> > > > > > that it accepts
> > > > > > subscribes and generates notifies on B's behalf. 
> How it finds 
> > > > > > out about the
> > > > > > presence state is another orthogonal piece, not 
> specified in 
> > > > > > the SUB/NOT
> > > > > > No, thats not true. When I subscribe to someone, 
> they appear 
> > > > > > in my buddy
> > > > > > presence. On the other side, when someone 
> subscribes to me, I 
> > > > > > get a screen
> > > > > > Approve/reject have the meanings we've been 
> discussing - they 
> > > > > > approve or

---

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

Keep in mind that some folks want to be able to
keep A in the dark about an authorization disposition.
Johnathan's sequence has the subscription accepted
with a 202, and subsequent receipt of a Notify
without a 200.  While I questioned that, if you
send a 200 for the Subscribe always, or send
202 for the Subscribe always, it's okay.  What
you can't do if you want to keep A in the dark
is to send a 202 before you get authorization,
and a 200 for a subsequent Subscribe after
authorization.

Those who want to let A know the state could use
202 and 200 appropriately to do that.
I personally would prefer to let A know when
there was no policy decision by rejecting the
subscription.  When a policy decision was in
place, I would always allow a Subscribe with a
200.  I would show Presence state as constant Out,
and it wouldn't change for those I did not
authorize.

Brian

> Sent: Friday, July 13, 2001 5:20 PM
> To: 'Rosen, Brian'
> > > > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). 
> There is a 
> > > > > > presentity
> > > > > > > watcherinfo), and a UAS for others. Remember, 
> UAC/UAS is a 
> > > > > > > per transaction
> > > > > > > mechanism. Typically, its through registrations 
> or through 
> > > > > > > direct upload of
> > > > > > > a presence document.
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > also sends a subscription from me back to them, 
> adding them 
> > > > > > > to my buddy
> > > > > > > list. 
> > > > > > > 
> > > > > > > I've been using this tool for several years. I 
> think I can 
> > > > > > make these

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jul 2001 23:40:33 -0400

> Sent: Friday, July 13, 2001 5:53 PM
> To: 'Daniel Starin'

Correct. We've discussed this issue extensively on this list, and the impp
list previously. The agreement was that it should be possible for a
mechanism to exist by which the subscriber cannot tell whether their
subscription was approved or rejected, or neither. So, the agreed upon flow
was:

SUB------->
<-------202

<------NOTIFY
200------>

In the case of an authorized subscription, the NOTIFY contains valid
presence data. In the case of a denied or pending subscription, it contains
syntactically valid, but incorrect or uninteresting information (i.e.,
always offline). In the case of an authorized subscription, additional
NOTIFYs will come as state changes. In the case of an unauthorized or
pending subscription, no further NOTIFYs will arrive (except the triggered
ones on a SUBSCRIBE refresh).

This guarantees that the subscriber cannot know the authorization decision.
So, the NOTIFY is always sent, which is why it appeared in my flow.

Now, others wanted to support applications where its OK to know that your
subscription was definitely accepted or definitely rejected. In that case, a
200 or a 400 response to SUBSCRIBE can be used. Certainly different packages
should be able to make differing decisions on this. So, I see no reason why
the presence.watcherinfo package cannot allow explicit accept/reject
responses to SUBSCRIBE, but presence always uses 202. I even think its OK
that within a package, subscriptions for a particular user on a particular
server can do this differently than other users on other servers. What you
cannot do is have it so that a SUBSCRIBE for A gets a 200 in some cases, 202
in other cases. 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jul 2001 23:57:47 -0400

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 12:45 PM
> To: Rosen, Brian; Bobby Sardana; Subir Saha
> Cc: Jonathan Rosenberg; [email-masked]
> > 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).
> 
> The more complex scenarios occur when the UA wants to 
> delegate publishing rights to a server in the middle of the 
> network. This is a substantial deviation from the basic SIP 
> architecture. The equivalent for INVITE would be to send the 
> calls to a gateway, and to use some form of out of band 
> mechanism such AUTH or NOTIFY in order to decide whether or 
> not that specific call should be picked.

You mean, like CPL? CGI? Pushing call handling logic into a server is quite
common in SIP networks. Pushing policy into servers make sense when the user
that makes policy decisions is not always available to make them, or their
device is too stupid to ask the user (i.e., using a black phone). It also
makes sense when there are multiple devices representing the user, in which
case the network server is a natural aggregation point. I don't think
anything in the SIP architecture makes this "deviant". 

> 
> Indeed, I am not so naïve as to believe that all 
> implementations will be end-to-end. I am just restating the 
> obvious: the remote control of a publisher from the edge of 
> the network is a complex operation that allows for a variety 
> of solutions. Which solution you use is part of the reason 
> why you pick a specific publisher; it may involve the support 
> of specific authorization mechanisms, special rule for 
> merging presence information from multiple terminals, support 
> for various authentication schemes, etc. I don't believe that 
> we can easily standardize that, and I doubt that we should.

I think we all agree that this interface can be complex, and that we cannot
standardize the full range of it. There also appears to be consensus that
pure watcherinfo is useful,  to tell a subscriber that wants to know, that a
subscription attempt was made. They can then use a server specific approach
to set policy (like a web page).

The only point of contention is this: because any given authorization
protocol cannot ever be sufficient for all needs, does this mean we describe
nothing? Brian and Christian say yes. I say no.

Lets look at publication of presence, as its a similar issue. A user can
have many devices. THe means by which his presence is published to the
server for distribution is outside of the basic SUBSCRIBE/NOTIFY presence
protocols. The spec allows a server to use as many, or as few mechanisms as
it likes. However, there are some useful ones. For example, a REGISTER
conveys presence. A presence server can use that to determine some pieces of
a user presence. Its not sufficient for rich presence, not by any stretch.
But, does that mean that we shouldn't mention its usage? That we should
disallow it? I think not. Its a very useful mechanism, and I think it will
see a lot of usage. Despite the fact that this can be viewed as the
interface between two pieces of a decomposed "real" presence server, the
fact is that this is a protocol interface between elements. Unless we ALWAYS
want that to be done with a human driving it, we will need some kind of
protocol to cover a few cases. 

All I am proposing is that we define *a* mechanism (not *the* mechanism),
which supports only the most simple-minded authorization decision - a binary
yes/no that tells the server to send the actual current presence state. I am
sure this will not be useful in all cases, but it solves some real
requirements today. We can define other things in the future if they need to
be standardized. We're not locking ourselves in to this method. We're not
requiring it. We're not making it the only method. Its *a* method that can
optionally be used.

-Jonathan R.

---

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Jul 2001 16:49:33 -0400

At 11:40 PM 7/16/2001 -0400, Jonathan Rosenberg wrote:

>always offline).

It's still not clear to me what value is gained by a garbage message in 
return for the bandwidth wasted.  It only seems to add confusion to readers 
of call flows.

>In the case of an authorized subscription, additional

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jul 2001 16:51:10 -0400

> Sent: Tuesday, July 17, 2001 4:50 PM
> To: Jonathan Rosenberg
> Cc: 'Rosen, Brian'; 'Daniel Starin'; [email-masked]

For privacy. I don't want subscribers to be able to determine my
authorization policy. Therefore, differing protocol behavior based on
authorization policy can't happen. If a NOTIFY only comes if I'm authorized,
then I can use the presence, or lack thereof, of an immediate NOTIFY to
determine my presence.

-Jonathan R.
---

---

From: Subir Saha <[email-masked]>
Date: Tue, 17 Jul 2001 13:57:34 -0700

[Subir]Also this gives excelent way for DOS attack on my presence server. 
Subir

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Jul 2001 17:14:28 -0400

>then I can use the presence, or lack thereof, of an immediate NOTIFY to

But, I thought that the whole point of the protocol (specifically the 
Notify) is to provide me presence information if I subscribe and am 
authorized.  I saw these two (Subscribe and Notify) transaction as separate 
with consistent behavior.

In the Subscribe transaction, the behavior is always acknowledge receipt of 
request, nothing more.  Same behavior whether authorized or not.

The Notify transaction is only provided to authorized subscribers and 
always behaves according to policy rules.  I didn't think there was an 
issue when presence was revealed when revealing presence was authorized.

Mike

---

From: "Sriram Parameswar" <[email-masked]>
Date: Tue, 17 Jul 2001 16:32:56 -0500

Quick observation/question - if you always send off-line (say) and I am
indeed offline (see Jonathans email below), haven't you actually divulged
presence information? I contend that this is also an information leak.

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 4:23 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin';

><< snip>>>
In other words, since the message sequence differentiates between the case
where a subscription was authorized, or was not, an attacker can ascertain
authorization information. To combat this, the message sequence must always
be the same. In the case of an unauthorized subscriber, the NOTIFY contains
a body with something in it. That something is a syntactically valid, but
incorrect piece of presence (i.e., joe is offline, no matter whether he is
or isn't). 
<<snip>>

---

From: Subir Saha <[email-masked]>
Date: Tue, 17 Jul 2001 14:42:03 -0700

My understanding of the call flow is as below:

SUB------->
<-------202

<------NOTIFY
200------>

<------NOTIFY
200------>

<------NOTIFY
200------>

This notify continues till subscription expires. Now you can always change
this flow to a single notification under unaothorised condition. But then
subscribers will be able to distinguise between "authorised" and
"unathorised" subscription!

Subir

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 2:25 PM
To: 'Subir Saha'; 'Michael Hammer'; Jonathan Rosenberg
Cc: 'Rosen, Brian'; 'Daniel Starin'; [email-masked]
Subject: RE: [Simple] Another idea for presence authorization

> Sent: Tuesday, July 17, 2001 4:58 PM

In what way? By making it send a single extra NOTIFY? You already make it
send a response to the SUBSCRIBE when you're not authorized. Should we
disallow responses to SUBSCRIBE as well? I don't think so. Remember, the
NOTIFY is only sent if the subscriber is AUTHENTICATED, so you get
traceability. That helps a lot to discourage attacks.

-Jonathan R.

---

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Jul 2001 17:48:44 -0400

At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote:

> > Sent: Tuesday, July 17, 2001 5:14 PM
> > To: Jonathan Rosenberg
>Of course these are separate transactions.
>
> >
>Correct.
>OK, let me try again. Telemarketer A decides to use presence as a great way
>to sell stuff. When someone logs in, they send them an IM asking to buy the
>latest widget. So, the telemarketer gets a huge list of addresses, and
>starts sending SUBSCRIBEs. Most sane people go and upload authorization
>policy that prohibits the subscription. However, the telemarketer responds
>to that in an interesting way. When the telemarketer refreshes the
>subscription, they detect whether a negative authorization, or no
>authorization has been provided. They then send an email to the user, saying
>"you still haven't approved subscriptions from widgets inc. Please do so now
>to find out the latest and greatest!".

They could just as easily do this when they notice after some time that I 
never seem to generate any subsequent Notify.  Nothing gained.  Once they 
recognize this behavior, it loses all credibility and value.

>How do they do this detection? Well
>they send a SUBSCRIBE. THey get a 200. If a NOTIFY comes immediately, they
>know they are authorized. If none comes, they know that haven't been
>authorized, or have been rejected.
>
>or isn't). Now, the subscriber has no way to determine if their subscription
>was authorized or not, based on message flows.
>
>Now, this issue was discussed a lot on the impp list, and I thought there
>was consensus that it was a good thing. I think authorization information is
>sensitive, and I think its important to protect it.

Still not convinced, but if that was a consensus, I'll be quiet.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jul 2001 17:46:08 -0400

> Sent: Tuesday, July 17, 2001 5:42 PM
> To: 'Jonathan Rosenberg'; Subir Saha; 'Michael Hammer'
> This notify continues till subscription expires. 

No, that is NOT the flow for an unauthorized subscribe.

> Now you can 
> always change
> this flow to a single notification under unaothorised 
> condition. 

That is correct.

> But then

No, they cannot. A perfectly valid scenario is that I am indeed offline for
an extended period of time. An attacker cannot distinguish the unauthorized
case (offline, and no change in that), from the authorized case where I
really am offline, and no change in that.

-Jonathan R.
---

---

From: Subir Saha <[email-masked]>
Date: Tue, 17 Jul 2001 14:50:07 -0700

Probably we are missing one point - the NOTIFY is send by the presence
server and even I am really offline - still this NOTIFY will continue on
every subscription effort. Am I missing something?

Subir
-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 2:46 PM
To: 'Subir Saha'; Jonathan Rosenberg; 'Michael Hammer'
Cc: 'Rosen, Brian'; 'Daniel Starin'; [email-masked]
Subject: RE: [Simple] Another idea for presence authorization

That is correct.

-Jonathan R.
---

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Jul 2001 17:42:30 -0400

At 12:30 PM 7/18/2001 -0400, Jonathan Rosenberg wrote:

> > From: James Undery [mailto:[email-masked]]
> > Sent: Wednesday, July 18, 2001 4:36 AM
> > To: Daniel Starin
> > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian';
> > Daniel Starin wrote:
> > > PLEASE disregard the other message and read this one... I
> > missed a typo
> > > which could ruin my argument...
> > >
> > > So we are all on the same level...
> > >
> > > As I understand it... there are 6 possible states when user
> > A makes a
> > > subscription request to user B...
> > >
> > > User B is?/The response to the subscription was?
> > >
> > > 1. Present/Accepted
> > > 2. Present/Pending
> > > 3. Present/Rejected
> > > 4. Not Present/Accepted
> > > 5. Not Present/Pending
> > > 6. Not Present/Rejected
> > >
> > > If we send "Offline" notifies every time...
> > >
> > > If User A gets an Offline notifies...
> > > he knows the state is one of the following
> > >
> > > 2. Present/Pending
> > > 3. Present/Rejected
> > > 4. Not Present/Accepted
> > > 5. Not Present/Pending
> > > 6. Not Present/Rejected
> > >
> >
> > 6 is not an option a rejected subscription will not generate a NOTIFY
> >
> > >
> > > If User A gets an Online notify..
> > > He knows the state is...
> > >
> > > 1. Present/Accepted
> > >
> > > The "Offline" notify method does indeed hide whether User A knows
> > > whether or not his subscription was Accepted or not.  BUT...
> > > mathematically, it gives User A something else to play
> > with.... If the
> > > probability of all six options are equal... User A knows
> > that when he
> > > gets an "Offline" notify that the percent chance that User
> > B is really
> > > Offline is 60% (3/5).
> >
> > But the probabilities are nowhere near equal (and you are
> > still wrong about
> > 6), assuming there are 1 million people in the world, the
> > fraction of them
> > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a
> > presentity at random to subscribe to, giving a 50/50 chance.
>
>Even better, the presence server can randomly change whether the first
>NOTIFY contains an "offline" or "online" status. This also pushes you back
>to 50/50.

Jonathan,

I would contend that you were at 50/50 when you sent no messages after the 
202 to the subscription.  The fact that you are still at 50/50 with random 
garbage messages means that you have not changed the probability.

No knowledge + no knowledge = no knowledge.  Even simpler math.

Mike

---

From: "Boyer, D G (Dave)" <[email-masked]>
Date: Thu, 19 Jul 2001 11:49:55 -0400

James,

I agree, doesn't make sense to me to send a random message
when a user is not authorized.
Why not just return a message - presence information "Unavailable".  
The presence information may be unavailable for a number of reasons - 
not authorized, network problem, etc.

Dave Boyer
Avaya Labs
Collaborative Applications Research

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 10:32 AM
> To: James Undery; Daniel Starin
> The idea of sending a random online/offline NOTIFY when 
> authorization is
> pending or rejected seems rather strange to me. What happens 
> if they receive
> an "online" and then attempt to contact that user? Wouldn't 
> the subsequent
> failure tell the requestor they were not authorized (or at 
> least give them a
> clue)? Why should we encourage more message traffic half the time?
> 
> In my mind, personal privacy is paramount and the most 
> sensitive piece of
> information that should not be divulged is whether or not the 
> authorization
> is pending or rejected. I think that sending "offline", 
> unless the requestor
> is authorized and the target user is online is, the right 
> thing to do. The
> only thing that the requestor has been told is that they 
> cannot reach the
> target user, they have not been told exactly why.
> 
> All these probability number being thrown around don't really 
> make sense to
> me. If I subscribe to Jonathan's presence for the first time, 
> and I get back
> "offline", I would assume that the authorization is pending 
> or rejected
> since I have never contacted him before. If I have previously 
> had an IM
> session with him, I assume "offline" means "offline".
> 
> The response to the subscription with either a notify (or 
> lack thereof)
> divulges some information. I think the least sensitive piece 
> of information
> is saying the target user is "offline". If that state has a 
> greater than 50%
> probability of being correct, so what? Until I accept your 
> subscription to
> my presence, I am "offline" to you.
> 
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
> 
> ----- Original Message -----
> From: "James Undery" <[email-masked]>
> To: "Daniel Starin" <[email-masked]>
> Cc: "'Jonathan Rosenberg'" <[email-masked]>; 
> "'Michael Hammer'"
> <[email-masked]>; "'Rosen, Brian'" <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, July 19, 2001 4:15 AM
> > > [mailto:[email-masked]] On Behalf 
> Of James Undery
> > > > PLEASE disregard the other message and read this one... 
> I missed a
> > > typo
> > > > As I understand it... there are 6 possible states when 
> user A makes a
> > > Wasn't the whole idea of sending a random notify every 
> time to make it
> > > so User A does not know whether or not his subscription has been
> > > accepted or not?  According to Jonathans diagram 
> previously posted in
> > > the thread a Notify is sent every time... That would 
> include the times
> > > when User B is not present and has set a policy on his PS 
> to reject the
> > > subscription... Wouldn't a notify still be sent?.... If a 
> notify is not
> > > sent doesn't User A know that his subscription is 
> rejected and then we
> > > are back to the telemarketer problem Jonathan 
> described?.... I hold that
> > > 6 is an option....
> >
> > well I contend there is option 7 present / appearing 
> offline, back to
> 50/50
> >
> > >
> > >
> > > >
> > > > probability of all six options are equal... User A 
> knows that when he
> > > > gets an "Offline" notify that the percent chance that 
> User B is really
> > > > Offline is 60% (3/5).
> > >
> > > > But the probabilities are nowhere near equal (and you 
> are still wrong
> > > about
> > > > 6), assuming there are 1 million people in the world, 
> the fraction of
> > > them
> > > Yes, out of the 1 million people, the ones you would authorize is
> > > minimal... the people who would request to subscribe to 
> you is minimal
> > > as well... User A knows nothing about User B until a 
> subscription is
> > > made... thus he has no way of knowing anything about User 
> B's policies
> > > with respect to subscription authorization... the only 
> thing he does
> > > know is that if he gets an offline notify that there are 
> 5 possible
> > > status' and 3 of them specify that User A is offline...
> >
> > My main point is the very little I remember about Probability is for
> complex
> > situations it is easy to make assumptions to get the answer 
> you want, I
> > content the argument is flawed as I could say based on the 
> time of day I
> can
> > make a better than 50/50 guess, for instance as I write 
> this email, I'd
> bet
> > you're at home probably asleep as it is 5am in New York.
> >
> > >
> > >
> > > > Mathematically, that is better than the 50/50
> > > > probability User A has of knowing if User B is present 
> or not that I
> > > > will prove that you get without sending any notifies at all...
> > > >
> > > > Without sending notifies before authorization...
> > > >
> > > > If User A gets No notify...
> > > > if he gets an Offline notify...
> > > >
> > > > he knows the state is..
> > > > 4. Not Present/Accepted
> > > >
> > > > if he gets an Online notify...
> > > >
> > > > he knows the state is
> > > > 1. Present/Accepted
> > > >
> > > > When user A receives No notifies, there is a 50% chance 
> that User B is
> > > > Present and a 50% chance that User B is not present... 
> this truly
> > > > divulges no information about User B's presence to User A....
> > > >
> > > > In this scenario... Jonathans statement is valid...
> > > >
> > > > In non-mathematical terms, if I always tell you its 
> sunny outside,
> > > > irregardless of whether it is or isn't, can you ever 
> know whether it
> > > > really is or isn't? Have I told you anything useful? No!
> > > >
> > > > In the notify every time scenario... this statement does not
> > > > apply...User A has a 60% chance of knowing User B's 
> true presence
> > > > REGARDLESS of whether he is authorized or not...
> > > >
> > > > In my mind... that makes notifying every time a bad idea... both
> > > > information wise and bandwidth wise...
> > >
> > > > A CPIM decision not a SIMPLE one.
> > >
> > > Fine, but I think we have to come to some consensus on 
> the matter... and
> > > Jonathan just brought up another idea... sending random 
> online/offline
> > > status'..... I am willing to back off if everyone 
> disagrees with me but
> > > I think that the "information leak" others have mentioned 
> is because of
> > > the reason described above....
> >
> > Well on the information leak I'd disagree, some times the lack of
> > information is information i.e. the other person doesn't 
> want to or can't
> > due to lack of presence respond. The idea of using subscribes from
> multiple
> > locations breaks the random answer idea. A lie is no good 
> unless it is a
> > consistent lie and I generally prefer just saying offline.
> >
> > James Undery
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Jul 2001 17:18:55 -0400

> Sent: Thursday, July 19, 2001 10:55 AM
> To: Bob Penfield
> Cc: James Undery; Daniel Starin; 'Jonathan Rosenberg'; 'Rosen, Brian';
> Bob,
> My only complaint is that this can be assumed and does not 
> require extra 
> message traffic to tell you that.

This doesn't work. If no NOTIFY is sent if the subscriber isn't authorized,
but a NOTIFY (with valid data) is sent if they are authorized, a subscriber
can tell immediately whether they are authorized or not.

I'll back off from the random selection of the status in the case where the
subscriber was rejected or not authorized. However, I still think that a
notification has to be sent with a syntactically valid, but useless status
that is uncorrelated with actual status.

-Jonathan R.

---