[Standards-JIG] Re: Roster Subscription Synchronisation

Richard Dobson 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 
control).

> 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 :)

Richard





More information about the Standards mailing list