antecipate: We must not transport Jingle!

XMPP has from the beginning build a reputation of inter-operability through its ability to communicate with disparate instant messaging systems. Just look at the number of public IM transports in service today.

There is no reason why this inter-operability could not be extended to the VoIP or multimedia communication as well. The XMPP community is working at making Jingle a robust signaling framework, with the same extensibility in mind as the rest of the protocol. That said, VoIP services comes in ever increasing flavors and numbers, each with its own way of providing its service. Bridging between Jingle and VoIP providers using the same transport design as for public IM transports will not scale. Not from a protocol view point, but from an identity and addressing perspective!

In a traditional XMPP transport, the end user usually goes through a registration phase, providing some sort of credentials, and above all, a valid address handle for the target communication system. Existing transports either store this information locally on the hosting machine, or use some non standard mechanisms (see <xdb/> packets in jabberd) to delegate the storage to the associated XMPP server.

Doing so creates a large number of “identity islands”. One such islands for every installed transport, holding in some not always secure store the association of an address handle and credentials. I do not believe this to be a good practice from a security stand point. Neither is it an efficient design because of the multiplication of sensitive information in different locations.

If you do not expose yourself much by “trusting” your public IM credentials to an XMPP transport (except if you use your public IM account as a trader of course), it becomes a different game when you start using paying services, such as PSTN voice gateways. You would not be happy to have some happy GTalker charging your credit card by calling its Grandma at the other side of the earth…

We must not apply the current monolithic self contained transport design to Jingle. The context has evolved to a larger communication space. We have a good opportunity to learn from experience here. There are numerous discussions going on in the Internet digital identity world on the subject of minimizing identity exposure. Everybody complains about the ever increasing need to provide identity related information for all sorts of service available on the Internet. These security trends include, but are not limited to, making sure the end user is in control of its identity, as well as using assertions to derive authorization. Trends also clearly indicate the limitations incurred by using address handles as identity identifiers. This is not exactly how the original Jabber transport were built. I believe it becomes important to incorporate these new trends, ready ourselves and rethink our existing implementations, and prepare better ways of handling identity and querying about addressing.