Defining ID, Authenticators and Approaches to Federation for WebRTC-based Systems
Jul 21st, 2020 by Aswath
In the previous post, we analyzed the preferred characteristics of addressing and ID in a user-centric messaging system. Also we saw the downsides of bilateral federation. We will use those principles to design addressing and ID schemes for a WebRTC-based messaging system.
Let us recap the conclusion of the previous post:
- For all the obvious advantages of unfettered federation, bilateral federation fraught with undesirable downsides. It favors big and established systems and snuffs out any new proposed systems however user-centric they are.
- 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.
Addressing
Since the messaging system is based on WebRTC, it is reasonable to use browsers as clients. This suggests that WebRTC-based systems will be better off to use URLs for addressing. As simple as that. But a moment of further analysis would suggest additional benefits of this simple choice. One can make a few quick observations: namespace is the same as that of URL; no need for SRV/NAPTR record assignments. A little reflection would suggest that users can use URLs derived from their own Domain names and then forward them to the URL provided by their service providers. This way they are free to switch the service providers but still maintain the same address. In other words, there is no need for portability agreements among the service-providers.
But there is one big advantage that is not available to any other addressing schemes. A user can have infinitely many addresses and use them to convey the context of the session. For example, a system could allow a user to add parameters to the base address and associate business logic to those parameters. Consider the scenario where A would like B to review a document and provide feedback. In this case, the parameter could indicate the URL of the document and A could include the parametrized address in the email to B. This way both sides can pull up the document when the session was launched.
Next, let us consider the case of incoming marketing. The marketing website can place a click to call link that is indeed a parametrized address where the parameter links to the caller’s browsing history of the site. This way, a marketing representative can access the caller’s browsing history while answering the prospective customer.
These are only illustrative examples. One can easily imagine many others. The beauty is there is no need to standardize any of them and no need to reach a broad agreement before using them.
ID
As we observed in the previous post, the caller could be an unregistered user and so will not have an “address”. At the same time it is preferable if the caller could be authenticated before the session is completed. So we have to come up with an alternate ID scheme. Since we are designing a messaging system based on WebRTC, any HTTP-based authentication scheme like OpenID, OpenID Connect, indieauth or Single Sign On schemes would be preferable. If nothing else, the caller’s email id which is verified by sending a one-time password will also work.
There may be use cases (as identified by the called user) where there is no need to authenticate the caller. In those cases the server could skip the authentication step. Whatever the use case may be, user-centric ID is the order of the day.
Federation
The choice of URL for addressing and allowing the caller to directly connect to the called user’s server and use of user-centric ID and third-party authentication scheme make bilateral federation unnecessary. “Federation” becomes a unilateral decision made by the called user and their server. Furthermore this decision is temporal, and can be made and unmade at any time and without involving any external entity.
Current Implementations
Almost all of the contemporary video conference services use URLs as the address for specific conferences and allow “guest access” who are not registered users. This works for those guests who use a browser. This leaves out those who use conference rooms that conform to other services. To address this issue, many are reaching pairwise agreements so their conference systems will work with each other systems. But as far as I know none of them use it any further. No service offers to present the documents relevant for the conference. Nor do they use user-centric ID to authenticate callers before adding them to the conference.
Messaging apps like Google Duo and Facebook Messenger continue to operate in the old mindset. They still think the market is won by bulking up and holding users captive. Users are addressed by system-specific ID. They do allow “guest access”, but only after the calling user is cajoled and accosted to download their app. The ultimate aim seems to have the bragging rights to the largest installed base.
EnThinnai
The design objective of EnThinnai is single users must be able to host their own messaging system without losing any of the functionality and features available in large systems.To meet this objective, we do not have any choice but to use the ideas suggested in this post. We use URLs for addressing; we add parameters to invoke additional business logic. We use Indieauth as an ID and authentication scheme. If a user does not have such an ID, we generate one using their email ID. Contact/buddy list doubles as a whitelist of people who are allowed to call in obviating the need for bilateral federation. If a contact has an URL to initiate a session, then the user can initiate a session from the Contact list. EnThinnai is a showcase for what can be done with WebRTC that benefits the users. After all we developed the principles of webRTC for this specific purpose a full two years before Google announced their plans.