Managing identity on the Web used to be much more complex and fragmented than it is today, as each platform was managing its own siloed identity. There was no way to pull information from third-party services and create rich, comprehensive profiles.
Similarly, before WebRTC communicating on the Web was also much more complex than it is today — service providers had to build their own proprietary plugins and services, manage authentications and identities, develop networks interoperable with the PSTN/VoIP in which e.164 took a vital part in defining identities, and more.
Today, with the emergence of WebRTC and other Web technologies developers can easily build their communication platforms and manage user identities the way they want. Initiatives likeOAuth or OpenID, for example, have allowed for the use of third parties such as social media platforms or email servers to manage identities on behalf of the service platform. “Identity” on the Internet has become completely decentralized, and has allowed for contextual identity over the Web. Believe it or not, this can actually be a good thing.
Here’s the formula on which the industry has achieved contextual communications:
The implementation of WebRTC APIs in modern browsers has allowed for platforms to add in communications capabilities with no frills. Now, because communications can be completely Web-based, communications capabilities can be present on more platforms — not just those dedicated to communications. Any platform can add communications features and mash them with all sorts of APIs to create rich, real-time communication platforms that are not focused solely on conferencing, but also on performing other actions (playing video games, conducting job interviews, etc.).
On the user’s side, there is no longer a need to download a plugin for the browser — this now opens these multi-purpose platforms to a much greater user base. Compatibility can be assumed across the board.
(+) OAuth and Authentication APIs
OAuth and other APIs that enable authentication have allowed any website to request access to a user’s information from any social platform, without jeopardizing the credentials. This allows the platform to choose or let the user choose which service they will be authenticating and how much information will be shared. This system has become very popular with social networks such as Facebook, LinkedIn, or even Google’s or Yahoo’s email services. Now, any platform can gather a greater amount of information from third-parties without having to create and manage their own profiling systems.
This allows for richer profiles to be created on the Web, and provides the foundation of contextual identities.
(+) OpenID and Identity Federation
While opening up communications services to various social profile providers allows for a richer Web, how do we ensure secure communications when using this method? Who has the ability to claim you are who you say you are? With such platforms, your identity is assumed to be truthful. But it’s not always right: For example, I shared my Netflix account with my college roommates (shhhh), and I don’t use my real name on Facebook. These single sign-on platforms that use OAuth have allowed me to switch from one identity service to another, fragmenting my identity on such services.
Here’s where federating identity comes into play. By decentralizing identities from services’ silos and federating into one common platform, we would allow platforms to ‘talk’ to each other and recognize the central identity of a user whether they log on with Facebook or Google.
Though the idea of consolidating identity on the Web through a federated system seems appealing, OpenID does not seem to be the solution the Web community is waiting for. It is DNS-based (Domain Name System) and centralized into a DNS registrar. This means that there can be security concerns tied to DNS itself and the DNS registrar.
(=) Contextual Identities
These are exciting times for communications over the Web. As real-time communications have been ported to the Web with WebRTC and as services are opening up their profile information through API services like OAuth, we’re able to build rich, contextual applications using many kinds of information from social profiles, emails, and even from your Fitbit’s activity history! All of this information can now simply be pulled up in a video call or a real-time data platform.
That said, I’m probably not going to play online poker with my LinkedIn profile. Nor am I likely to take a video job interview with my Facebook account. Similarly, my doctor has no interest in my Twitter message history when performing a telepresence exam. The list goes on.
However, I do want to upload my experience and education from LinkedIn and be identified as my LinkedIn name for a video job interview. I do want to be identified with my phone number when I’m expecting a support agent to call back. And when making a WebRTC-based call with a virtual teller, I do want to have my specific banking profile available, which can, in turn, pull information from a Google+ profile.
This is where the good part of identity decentralization lies, as it enables contextual identity — offering selected quantities of information to be shared, depending on the website, application or context. For example, thanks to OAuth, you can easily import Facebook contacts you want access to in a third-party application, such as WhatsApp; or decide which information from your social profiles you want to share with the service to add context and richness to the application (e.g. create a CV from a LinkedIn profile).
But, what does all this mean for developers?
Thanks to WebRTC technology, your users will not have to download a plugin to start using your services, and as a developer, you can integrate with any other API to make your platform richer (with contextual information).
These technologies have opened the door to so many options when it comes to choosing a profile/identity provider for your platform… So how do you know which one suits you best? There are a few issues that developers will need to consider when making this decision, including:
- Which technology holds the right set of information needed?
Certain providers offer different kinds of data sets (e.g. Facebook profile info vs. LinkedIn profile info), but also different levels of permissions (e.g. both LinkedIn and Facebook limits different types of information you can retrieve from the authenticated user’s friends or connections).
- What is the purpose of the communication?
This is fairly straight-forward: Are you building a job interview video platform (if so, I recommend using LinkedIn), or are you are building a platform for running buddies? (if so, you should probably look into Facebook, Fitbit, Nike+, etc.).
Through the implementations of authentication APIs like OAuth and WebRTC APIs, we’ve allowed for Web communications platforms to become richer in context and easier to develop. However, there are still a few crucial points missing to developer better contextual communications to the Web.
So, what’s missing?
- CNAM as an API with OAuth/Authentication capabilities
For the last few decades, the phone number has had a vital role in the telecommunications ecosystem — mainly for its use in defining identities. Back then and still today, the phone number is a “universal identifier,” regrouping billing, communications and personal data, as well as a link to government ID databases.However, it has barely been ported over the Web in the way voice has. It has the potential to hold so much information about an individual and even still, it is not being used for authentication over the Web. At Voxbone, we’ve actively worked on keeping the phone number relevant to the Web by building our WebRTC-SIP SDK to enable cloud PBX companies to open their existing telephony infrastructure to WebRTC traffic. This way, the phone numbers’ advantage of being a unique identifier can be linked to contextual data gathered on a Web service. Many other initiatives have been developed to bring the phone number to the Web, such as services providing CNAM database as an API. As a reader, what is your opinion on the initiatives that have been taken to bring CNAM and the phone number to the API world?
- Truly Decentralizing Identity Management
OpenID is still a very much centralized way of federating identities. The Web community is requesting a better way to federate identities and truly decentralize the identity management system. This is because traditional login systems have identities owned by corporations instead of being owned by the individuals to whom those identities belong to. Some examples of such initiatives include using the (Bitcoin) BlockchainID, or the Stellar Consensus Protocol, for an alternative to OpenID.While perfectly in sync with the Web mentality, these initiatives along with WebRTC wouldn’t please authorities as it would render traceability much harder than it is today. Think: WebRTC + BlockchainID + DeepWeb for optimal private communications.
- Interoperability, the missing link
Now, with OpenID / OAuth / BlockchainID, I can choose how I want to authenticate to a service, but I cannot dictate how I want to communicate on a service, as each platform has its own signaling protocols. In this manner, the interoperability landscape seems fragmented and inconsistent. For example, I may be currently active on WhatsApp, but I’m ‘offline’ on Skype. Sally, my friend, doesn’t have WhatsApp but uses Skype. She assumes she can’t call me because I am offline — though I would be available to receive her call on WhatsApp.This is because IMS providers (Facebook, Google, etc.) are fine with opening up their services to OpenID or OAuth, but they want to keep their own platform siloed and not implement such services themselves. Also, the two platforms don’t speak the same signaling ‘language.’
So far, only the phone number is doing a great job at being ‘universal.’ It is assumed that everybody has one, but as our means of communicating evolves, who knows if the phone number will last. Some initiatives like Matrix.org have taken a stab at fixing the interoperability issues while not having to federate identities.
Have I missed something? What do you think about all this? Please let me know in the comments.
Latest posts by Sacha Nacar (see all)
- Building the Phone of the Future with Voxbone & Cisco Spark - April 17, 2016
- Automating your DID Provisioning with Slack & VoxAPI – Part 2 - January 27, 2016
- Automating your DID Provisioning with Slack & VoxAPI – Part 1 - January 9, 2016