WebRTC and Contextual Identity on the Web
Managing identity on the Web has evolved, but forming contextual identities is achievable -- and here’s the formula.
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 like OAuth 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?
Read on to page 2 to find out.