[Standards-JIG] Re: Roster Subscription Synchronisation
richard at dobson-i.net
Thu Sep 16 20:28:06 UTC 2004
> So a user would authorize an entity (e.g., a gateway) as "trusted" in
> some fashion and the user's server would automatically act on roster
> additions, deletions, and modifications suggested by the entity? It
> seems that the user would still need to know which entity is initiating
> each action so that it can determine whether to continue trusting that
> entity. For example, imagine that you tell your server that you trust
> the following three entities to suggest roster changes:
> 1. aim.example.org (a gateway to AIM)
Would only be able to see items in its own domain, i.e. JIDs with the
following format user at aim.example.org, this is the easiest case to handle
and make secure.
> 2. groups.example.com (a shared groups server for your company)
> 3. stpeter at jabber.org (for the "JSF Members" list)
Yes these two options do need careful thought in order to make sure things
are as secure as possible.
> Now you start getting new roster items, old items disappear, names and
> groups are changed, etc. How do you know who suggested those changes?
> Perhaps there is a way to limit which roster groups an entity may change
> (e.g., stpeter at jabber.org, who is inherently untrustworthy anyway, can
> suggest changes only in your roster's "JSF Members" group).
Yes restricting to a group is one of the options.
> But it seems
> that you may want to know that groups.example.com suggested to add
> FoxyLady at aim.example.org (what's to stop it from doing so?), because you
> may not trust that entity to add appropriate roster items in the future.
That is a valid point, all depends on the level of control you are giving
the third party, it would be preferable to restrict the entity to only be
able to make changes to contacts in a particular group in this case, and as
far as shared groups goes having all of the items inside one group in the
roster will make things far more user friendly for the end user anyway, as
the user can immediately tell which items are part of which shared group.
> So perhaps we need to include an "originator" JID (perhaps via JEP-0131)
> in the roster push you receive from the server (we can't set the 'from'
> address of the roster push to aim.example.org since that violates some
> of the protections in XMPP IM).
As far as transports are concerned you would have it so that the transport
could only see/alter/add items that are in its own domain, as far as
controlling what other things might do to your roster that would be the
responsibility of whatever ACL scheme we devise for controlling access to
the roster, other options would be things like an entity managing a
particular group in your roster (and having the same rules applied as
transports, i.e. only being able to see roster items for which it can
> Other questions arise: what if two entities have recommended that you
> add the same item to your roster, and one calls pgmillard at jabber.org
> "pgm" while another calls that JID "Peter Millard" (where "calls" means
> the value of the 'name' attribute). Which one rules if we don't check
> with the user?
Thats a valid point but you are going to get this problem whether the server
manages the additions or the client does, maybe as part of the ACL you
define which things an entity can alter like the name as as some have
pointed out they dont like the names of their contacts changing like they do
can in MSN, but others might not mind, you might also want one entity to
have the capability to change the name and one that cant, but can add and
remove the item from the group it manages.
> You see, we open an interesting can of worms when we start to mess
> around with rosters.
Yup but most of it can be quite useful stuff as far as usability goes, i.e.
the auto updating of the transport contacts.
> Speaking of which, I will soon submit a proposal for revising JEP-0093.
> Stay tuned...
Cool will do :)
More information about the Standards