Subject: RE: [SIMPLE] Presence Authorization

From: "Oded" <[email-masked]>
Date: Tue, 12 Jun 2001 16:38:54 +0200

The debate over how to upload and retrieve watcherinfo documents assumes
that these lists should be stored on the presence server while it seems much
more logical to store these lists on the services (IM/ UM etc.).

In the context of presence to an IM service (this example applies to a more
general service as well) 3 basic lists may exist:
1. Permit list - users that can receive presence on a certain presentity
(allowed)
2. Deny list - users that should not receive presence (blocked)
3. Waiting authorization list - users that were not approved yet to receive
presence (pending)

Usually, only one of the first two lists would be active/implemented.

The presence server (PS) should be defined as an application that supplies
presence services to real applications (presence providers/consumers). The
logic of how to handle these lists is usually different among services and
thus cannot reside on the PS itself.

The presence server need not know anything about the subscription
authorization process (that can be different from one service to another).
When user A approves to reveal his presence to user B, the service(!) adds B
to A's permit list and notifies the PS.

Note also, that some services may not implement a deny list, and some even
not require subscription authorization. In other words, since the PS cannot
know in advance which applications will be using it and their internal
logic, it should leave the logic to the services.

Jonathan, in your comments you imply that in a certain implementation, the
service can manage authorization and the PS may use an 'accept all' policy.
The problem is that this implementation will not be compatible with other
implementations that implement authorization on the PS and not in the
service.

It's important that SIMPLE defines where these lists are managed and who to
contact to manage them.

To conclude, SIMPLE should define how to upload/retrieve watcherinfo
documents, but this command should be performed against the service and not
the presence server. I agree that presence servers may be allowed to manage
these lists but the protocol should encourage doing it on the service level,
as a main stream approach.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, June 11, 2001 6:19 AM
To: 'Oded Cna'an'; SIMPLE Mail List (E-mail)
Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail)
Subject: RE: [SIMPLE] Presence Authorization

> -----Original Message-----
> From: Oded Cna'an [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2001 10:18 AM
> To: SIMPLE Mail List (E-mail)
> Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail)
> Subject: [SIMPLE] Presence Authorization
>
>
> Hi,
>
> A general presence server (PS), in my view, handles 3 basic tasks:
>
> 1. Collection and aggregation of presence information - a PS
> updates the
> presence information by both connecting to different
> 'sensors' (location
> servers, reachability servers, velocity servers etc.) and
> receiving updates
> from presentities as to their status (availability, location etc.).
>
> Presence information is aggregated so that the server holds the latest
> presence state of a presentity based on all the UAs currently
> registered.
>
> 2. Manage subscription (not authorization) of entities that
> wish to receive
> presence notifications on specific presentities. These
> entities must already
> be approved to receive notifications.
>
> 3. Issuing notifications to watchers whenever the presence information
> changes. Normally, a presence server would also support
> querying of presence
> information as defined in RFC 2778.

I think they do handle authorization, but I strongly feel that how the
authorization is done can, and should, be extremely flexible. The proposed
watcherinfo provides one, and only one, means for authorization that is
needed to solve an important common case (which is why we factor it out into
a separate and orthogonal document set).

>
>
> Presence servers work hand in hand with applications that
> require presence
> info (e.g., IM, UM, call routing, content delivery etc.) in a
> way that these
> applications supply the logic part and the PS takes care of presence
> collection and distribution. The main point is that these services are
> separated from the PS.

I agree 100%. In fact, you should have a look at the application component
architecture for SIP:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
.txt

which is all about the separation of applications from application-unaware
components, including media servers, conferencing servers, and presence
servers.

>
> If we take a SIMPLE based IM service as an example, this
> service requires an
> implicit/explicit login/logout actions, manages message routing (and
> possibly storing) and is the interface for presence information.
>
> The translation of these operations into a SIMPLE work flow
> can be done as
> follows (although this is not the only way):
>
>
>       UA                  IM             PS
>       |     REGISTER       |              |
>       |------------------->|   REGISTER   |
>       |                    |------------->|
>       |                    |   200 OK     |
>       |       200 OK       |<-------------|
>       |<-------------------|              |
>       |                    |              |
>       |    SUBSCRIBE       |              |
>       |------------------->|  SUBSCRIBE   |
>       |                    |------------->|
>       |                    |     200 OK   |
>       |      200 OK        |<-------------|
>       |<-------------------|              |
>       |                    |   NOTIFY     |
>       |      NOTIFY        |<-------------|
>       |<-------------------|              |
>       |                    |              |
>       |     MESSAGE        |              |           OTHER UA
>       |------------------->|           MESSAGE           |
>       |                    |---------------------------->|
>       |                    |              |              |
>       |                    |            200 OK           |
>       |      200 OK        |<----------------------------|
>       |<-------------------|              |              |
>
>
> As shown above, the actions are performed against the service
> (in this case
> IM) that passes them (if appropriate) to the PS.
>
> Subscription authorization, in the general case, is related
> to a service and
> not the PS.

Absolutely. However, the PS still needs to do authorization, but of a
different sort. In this model, the PS needs to authorize that the
subscription is coming from a trusted application (in this case, the IM
service). That is generally accomplished in SIP using transport layer
security techniques. The IM service would have a secure connection to the
PS, using SSL/TLS. The authorization policy of the PS would be to accept all
subscriptions that come over this connection. The IM service would handle
the service level authorization, as you describe.

As an example, let's say that I am connected to 2
> different
> services (IM and UM) that use the same PS as their back
> office (a typical
> scenario for mobile operators and enterprises). Approving
> subscription to
> user a@b on the UM service does not mean that I approve
> subscription to that
> user on the IM service.

While I agree in principle, practically speaking, this is not going to
provide real security. If I want to get at your presence for IM, but you
refuse, I can simply ask for your presence for UM, get accepted, and then
use that information for other purposes.

>
> The above analysis dictates a solution in which the service
> is responsible
> for the subscription authorization and the presence server is
> informed by
> the service, which users can receive presence info on a
> certain presentity
> (subject to PS provisioning).
>
> This approach, that separates between the services and the PS
> was adopted by
> the PAM forum and is at the basis of the PAM API.

I hope I have been clear in that I don't think what you are proposing is at
odds in any way with the SIMPLE model. In your case, you would simply not
use the watcherinfo based authorization. Instead, your authorization is
based on transitive trust between and application and the presence server.
Standard ways in SIP exist to establish such a relationship. Of course, how
the application makes its decision on authorization is also an
implementation decision, and there is nothing that would prevent you from
running PAM for this purpose.

-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: [email-masked]
Date: Tue, 12 Jun 2001 11:54:43 -0500

> From: Oded [mailto:[email-masked]]
> 

I think you're presuming a particular architecture for your
network. And that's great, but doesn't really have a bearing
on the work we're doing here. On the protocol level, we don't
really distinguish between a presence server and whatever it
is you think of as your nodes on the "service level."

I can't make myself see this as a problem, though. In general,
you can trivially solve the problem by using any arbitrary
protocol (Corba, SIP, RPC, something proprietary -- it doesn't
matter) between your PS and your nodes on the service layer.
This has an elegance to it inasmuch as it does not require
the clients to have knowledge about the way you have chosen
to design your network.

Or it could be that I'm missing something. Perhaps a clearer
illustration of what you mean by "service level" as well as
a definition of some terms (UM?) would help.

/a