Subject: [Wocky] Buddy Authorization

From: Jonathan Reed <[email-masked]>
Date: Thu, 11 Aug 2005 11:55:46 -0400

I understand that one of the big selling points of jabber is 
"individual privacy" and that they want it to be like meeting in real 
life, so both people are aware of the interaction, but I find it 
rather frustrating that each time I add someone to my buddy list (or 
I get added to theirs) I have to deal with the authorization, or 
'handshake' as the jabber docs call it.

Is there a setting on the server for this?  Or is the idea that I 
should only use my 'buddy list' for people whom I want to authorize 
(and monitor their status), and if I wish to chat with someone not in 
my buddy list, I should simply open a new chat directly with that 
person and bypass the list entirely?

This seems like it might be difficult to migrate from the AIM mindset 
(or even the xzewd mindset, if you will), where your buddy list is 
more like an address book so you can quickly start an IM with 
someone.  In the Jabber world, it seems like it's more of a trust 
relationship.  I understand the concerns obviously (online stalking 
by knowning how long someone is idle, etc), but in the Zephyr world, 
zlocate and finger provide that information pseudo-anonymously, 
perhaps our Jabber server should be configured the same way?

-Jon
-- 
-------------------
Jonathan Reed

[email-masked]
-------------------

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 11 Aug 2005 13:59:24 -0400

Hi,

Jabber's "buddy" feature is closely tied to presence, hence has some privacy
concerns and requires a level of authorization. However, Jabber also has the
concept of a "roster" which provides some of the functionality that people
may be used to from AIM's buddies and some of the Zephyr features for
discovering people.

Below is some information that I found online. It is primarily aimed at
developers, but has some useful background information for people on this
list.

5. Managing Your Roster
Roster management is one of the most confusing areas of the protocol, or at
least of its current documentation. Here's an overview.

How the roster works.
The roster is the list of Jabber entities with whom the user has a presence
relationship. This includes people to whose status the user is subscribed
("buddies"), people who are subscribed to the user's status ("watchers"),
and people to whom the user wants to subscribe but who haven't yet approved
the request. The roster is thus the model of the GUI "buddy list".

The Jabber server stores the user's roster and notifies all logged-in
clients whenever it changes: when the user adds or removes a buddy, when
another user adds or removes the user as a buddy, and when a potential buddy
approves or rejects a subscription request. This is known as a roster push.
The change notifications are sent as <iq> elements using the
jabber:iq:roster namespace. The client can also manually request a complete
copy of the roster: it's necessary to do this just after logging in to
detect changes that may have been made since the last logout at this
computer.

[JPO 1.6.12]

Subscribing & unsubscribing buddies.
Confusingly enough, adding and removing buddies is not done via roster
manipulation but via <presence> elements. Here the type is subscribe or
unsubscribe and the request is sent to the buddy's address. Confirmation or
rejection is received as a reply <presence> element (with the same ID) with
a type of subscribed or unsubscribed.

Conversely, you'll also deal with other entities wanting to subscribe to
your presence. In this case it's exactly the opposite: you receive the
subscribe or unsubscribe and (after consulting with the user) reply with
subscribed or unsubscribed.

[JPO 1.4.1.3 -- 1.4.1.7]

In all these cases, since your roster is changed, the server will also send
another roster push to tell you about the roster element to change.

Manually updating the roster.
It's possible for you to update the server-side roster by sending <iq
type="set"> elements. You would do this not to add or remove buddies (see
the previous section for how to do that) but to add or change metadata
associated with a buddy, such as their nickname or group[s]. [JPO 1.6.12]

Actually, it is possible to add people to the roster this way, but it won't
subscribe you to their presence. They'll just be there passively, as in an
e-mail address book. You may or may not want to support this in your UI; it
doesn't seem especially useful to me, but it might be handy if there are
people the user wants to send messages to but doesn't need to know their
online status.

The documentation says it's also possible to remove people directly from the
roster by setting the "subscription" attribute to "remove". [JPG p.65] This
is the only way to remove an item added without a subscription (as in the
previous paragraph); but I'm not sure what happens if you remove a
subscribed buddy this way. Presumably it should unsubscribe you from their
presence notifications just as if you had sent a <presence
type="unsubscribe"> element.

Implementation tip.
Since the server will notify you of all changes in the roster, you can drive
the management of the GUI buddy list entirely from these pushes. For
example, when the user wants to add a buddy, you send out a <presence
type="subscribe"> element but don't update the buddy list yet; you'll
immediately receive a roster push from the server telling you about the
change and should update the buddy list when you receive it. By using roster
pushes to manage the buddy list, you ensure that the buddy list stays up to
date whether it's you or another simultaneously logged-in client making the
changes.

More roster info.
You may want to display more buddy information in your UI than simply the
Jabber ID, presence state and status message. As described above, a full
name/nickname can be associated with a buddy in the roster.

A whole lot more information about a buddy can be obtained by retrieving
their vCard via an <iq> query, if they've stored one on the server [JPO
1.6.26]. vCards are the Internet equivalent of business or Rolodex cards and
can contain any imaginable sort of personal and contact information such as
photos, birthdays, phone numbers...

Still more generally, the Jabber server as of version 1.4 allows users to
store arbitrary XML data tagged with any namespace, accessible to anyone who
queries their account using the same namespace. [JPO 1.6.10] I'm not aware
of any concrete usage of this, but it has great potential.

The preceding information comes from
<http://www.akeni.com/en/support/jabberclientcheatsheet.php>.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 11 Aug 2005 14:42:20 -0400

I think a more general question is whether the goal is for an Athena
Jabber server to provide the same semantics as zephyr currently does,
or whether jabber is supposed to provide support for some other
culture.

I get the impression that there are many zephyr users who would be
unhappy if jabber were to replace zephyr without providing a similar
user experience.

But I'm not clear on what problem the Athena jabber server is supposed
to solve.  (On the other hand, if it's not supposed to be a zephyr
replacement, what does it offer that AIM doesn't?)

How does jabber's current buddy authorization interact with jabber
conferences?  Occasionally I participate in conversations on zephyr
classes where it ends up being useful to move to personals, and on
rare occasions this involves someone who I wouldn't happen to have
already authorized as a buddy, and so the semantics of letting anyone
send are useful.  Every now and then we see a webzephyr user carrying
out an extensive conversation on a zephyr class trying to get someone
to subscribe to webzephyr so that they can send a personal message,
which is somewhat annoying for everyone else who's watching the class.

I think it's also the case that jabber was designed with the idea that
anyone anywhere on the Internet would normally be able to connect,
without any strong mechanism for authenticating the users.  In such a
context, buddy authorization probably makes a _lot_ of sense.  If you
have a system that discourages annoymous messages from being sent
through relatively strong authentication of users, needing to
authorize each user you individually talk to probably becomes much
less of a problem.

---

From: "Paul B. Hill" <[email-masked]>
Date: Fri, 12 Aug 2005 14:41:13 -0400

Hi,

Thank you for your comments and questions. 

I believe we are approaching jabber with an open mind, and for several
different purposes. 

First there are several communities of users at MIT that have never broadly
adopted Zephyr. Many people do use AIM, but as more work is done over IM,
relying on AIM, Yahoo, or MSN becomes problematic. By providing an
institutional IM service we hope that people will appreciate the consistent
namespace and find it of value. We are also somewhat uncomfortable with some
people using these 3rd party commercial services to carry out institutional
business. 

The jabber protocol appears to offer support of most of the Zephyr features
that MIT users feel are important. We realize that today, few, if any, of
the clients support many of these features. This may change overtime, either
through the efforts of people at MIT or elsewhere.

I feel there are reasons to explore alternatives Zephyr. Many people at MIT
need to collaborate with others around the world. Although Zephyr is used at
some other sites, it has never had the wide spread deployment that some
other IM systems enjoy. Furthermore NATs are a reality, and Zephyr does not
work well when using address translation.

As GSS support is added to jabber client and servers it remains to be seen
how developers will deal with the authorization issues. Although we expect
to use GSS within the campus community, which might argue against the
current authorization model, we also want the jabber service to provide an
IM foundation for extra-institutional IM. Not all of those other sites will
necessarily being using authentication methods that we find acceptable. The
UIs will have to evolve over time to address these different needs. 

At this time we are not talking about replacing Zephyr with jabber. We are
trying to create an environment where jabber can compete with Zephyr and
determine what needs to be changed to best meet our customer's needs. 

Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel
N. Weber II
Sent: Thursday, August 11, 2005 2:42 PM
To: Jonathan Reed
Cc: [email-masked]
Subject: Re: [Wocky] Buddy Authorization

_______________________________________________
Wocky mailing list
[email-masked]
http://mailman.mit.edu/mailman/listinfo/wocky