Rethinking Federation, ID, Namespace and Directories
Jul 21st, 2020 by Aswath
We are familiar with communication systems like PSTN, email, VoIP and XMPP; especially the importance, ney, necessity of such constructs like Federation, ID and Namespace. But WebRTC is fundamentally different in comparison to these other systems and so we can come up with different approaches that ultimately benefit the end-users, even if the service provider landscape is fundamentally changed. So it is instructive to review these constructs and apply them to a messaging system based on WebRTC.
Federation
Thus far, autonomous systems agreed to federate among themselves to provide global coverage. For example, PSTN providers interconnect among themselves so a user from a provider can call a friend who is served by another provider. This agreement to federate is universal and long standing. We fully expect it to be working and it breaks only for geopolitical reasons. A similar situation exists for email systems, though providers are occasionally blackballed if they are lenient in controlling spammers. The ostracization is total and complete and is used as a punitive scheme. These two cases set us our expectations for other systems and federation became a holy grail for all new systems.
But VoIP faced practical difficulties. Initially there were competing protocols. Even when SIP eclipsed H.323, there were difficulties because new versions were coming out too quickly and systems adopted them at differing rates. So SIP providers settled for federating as PSTN providers. This inhibited many features that could be offered by SIP and users have to settle for what could be done by SS7. By the time XMPP rolled in, providers’ mentality changed even as end-users clung to the romantic notion of universal federation. Winner take all became a business tactic. Though an easy federation is built into XMPP, individual providers refused to federate. Let me stipulate that for all practical purposes, XMPP systems are islands.
To a certain extent, there are valid reasons for not to federate unconditionally. Consider two enterprises A and B that would like to federate because they are collaborating on a project. With the current construct, all the employees of A are federated with all the employees of B. This includes open sharing of some sensitive information like Presence. So B’s server will know the Presence of the CEO of A and there is no control on how B’s server further disseminates this information.
The upshot of this is that even though federation is a laudable objective, there are technical and social issues that have stymied previous systems. The main culprit is that federation requires bilateral agreement and it is total. It is much preferable that federation is done at a more granular level.
ID and Namespace
All the prior systems (PSTN, email, SIP, XMPP) use IDs for dual purposes. ID is used to locate the other end of the session (let us call it addressing) as well as identifying the originator of the session (let us call it authenticator). So a non-user may have an authenticator, but will not have an address.
It is preferable that we decouple these two. For one, a system could allow even a non-user to originate a session to one of its users, thereby blunting the force of “federation hammer”. Additionally the initiating user can select use-appropriate ID; employer provided ID for work related sessions; a personal ID for social occasions and the like.
Namespace stipulates the format and constraints for the ID. For example, PSTN’s namespace is defined in E.164 Recommendation. XMPP, SIP-based VoIP and email have more or less similar format – composed of username and the domain name. A recognized downside of these structures is that the ID is not portable. (Through regulatory fiat, phone numbers are portable within a country,but not universally.)
Even though SIP-based VoIP got wider adoption, there was enormous pressure to federate with PSTN. This forced SIP-based systems to adopt E.164 for addressing. This prompted a movement to map E.164 addresses to one that can be used in the Internet domain. This gave rise to what is known as ENUM Recommendation. In short, the recommendation suggested to exploit the hierarchical structure of E.164 address and map it to hierarchically structured subdomain under a well recognized first level domain – e164.arpa. For a while it was all the rage because one could replicate many of the Intelligent Network services available in the PSTN world in VoIP world. (This is when many were celebrating the Stupid Network.) For our purposes, it is noteworthy because in a limited way it pointed out there are advantages in separating addressing from the authenticator.
Directory service
To this day I get confused whenever I hear this phrase because I imagine the Telephone directory/411 service telephone operators used to offer which gave a person’s address. But it refers to something altogether. Given a SIP URI, Jabber ID or ENUM address how to further concretely locate the entity that can further process the request. This is very much similar to how the browser retrieves A or AAAA record when it tries to access a URL. Both SIP URI and Jabber ID use SRV records. ENUM utilizes NAPTR and SRV records in succession.
It is important to note how Directory service is done because it points out that if a user would like to port their address and/or authenticator, the older domain has to play along. But there is no motivation or regulatory requirement that they do.
Summary
As we attempt to design a system based on WebRTC technology, let us summarize what we have observed thus far:
- For all the obvious advantages of unfettered federation, bilateral federation is fraught with undesirable downsides. It favors big and established systems and they could snuff out new proposed systems however user-centric they may be.
- Though bilateral federation should not be a requirement, it is preferable that a system give access to non-registered users (“guest access”) albeit it is a restricted access. The system is free to define the limits of the restriction.
- It is preferable to separate the address and authenticator.
- The address must be portable from one system to another.
- It is preferable that a system must be willing to accept third party authenticators.
In the following post we will suggest a way to incorporate these points and suggest an addressing and authenticator scheme that is user-centric and at the same time does not place a new/smaller place at a disadvantageous position. We will also point out additional benefits of the proposed scheme.