Recently I've been thinking a lot about Federated Identify
. In the technology industry it feels like we're always on the constant hunt for the perfect solution when it's been sitting under our noses the whole time.
The Problem Space
At it's heart there are two things that are being solved for. First, how do I authenticate that you are who you are? Second, how do I share basic information in a secure way across multiple systems.
The first problem is a somewhat straightforward problem to solve. While in recent years we've seen advancements in bio-metric authentication, largely authentication is achieved in the form of some sort of username and password combination.
The second problem is not as straightforward to solve. There are a lot of systems that we use everyday ranging from social media to more crucial services like banks and utilities that need a variety of information about us on top of the typical authentication that we are who we say we are. Social networks need to know who your contacts are, what your calendar data entails, who you converse with and when you're available. Banks and utilities need to know more basic information about you such as your mailing address and phone number.
Having a single canonical source for all this data sounds like a great idea doesn't it?
The Problems With The Problem Space
Federated identity and authentication come with the promise of managing your authentication and personal information in one place. In theory that's achievable, but it practice it's a lie. Users still have the burden of managing multiple profiles, duplicating information across sites, and figuring out each sites different privacy policies, what they do with your information and what information they share (or sell) to others.
Again, if there were one true canonical source for this information this wouldn't be a problem, but history has shown that there isn't going to be one canonical source. In fact history has shown that we've made the problem worse. Instead of having one place to manage data we've got a dozen. To make matters worse, most of those places do not stay in sync and we're forced to either deal with inaccurate/out of date data or to spend a lot of time keeping all our data up to date.
Still aren't convinced, how many of these federated identity and authentication sites do you have an account with?
My guess is that you have an account on at least half of those, if not all of them. That data point in and of itself is proof that federated identity doesn't solve for the you're only going to have to manage your data in one place
Redefining The Problem
I'd like to propose that we redefine the problem in such a way that
- We allow users to store their personal data wherever they want
- We make that data accessible and 100% in the control of the users
- We authenticate users in such a way that they only have one username/password combination to remember and changes to their password are instantaneous across all sites they authenticate with.
Solving this problem isn't actually all that difficult. It can largely be done with existing technologies and open standards.
Authenticate users using their existing email service provider
If every email provider exposed an OAuth provider that was built on top of SMTP Authentication
then we'd have this service today. The user would be redirected to their email provider and asked to authenticate. They'd give their email provider their username/password combo and then it would issue an OAuth token to the service.
The users email/password combination are never shared and users don't have to remember multiple usernames/passwords. It comes with the added benefit that when they change their email password it's instantaneously reflected in any service they use.
Again this could be built into every existing service now using existing standards.
Allow users to store data wherever they want
As a user I should be able to store my data in the service of choice. I should be able to store my data in Facebook, Microsoft, Apple, Google, Amazon, or <insert your favorite cloud provider here> service. If I want to use another service then I should be able to point it at where I store my data and it should be able to read or modify it as I choose.
This also could be done today using existing standards and protocols. If each cloud provider did the following we'd liberate our data and ourselves from having to choose how and where we store data.
- Expose CalDav, CardDav, and WebDav APIs to read/write contact, calendar, and file data.
- Provide a mechanism that allowed users to grant access (OAuth anyone?) to their data from another service.
Example of how this would work in the real world
Let's say I decide that I want to use GMail as my email provider. I go sign up and GMail creates an account for me and exposes an OAuth provider for anyone that wants to integrate with my GMail account.
Later, I get an iPhone and want to use iCloud and Apple's calendar. When I sign into my iPhone I tell Apple that I use GMail for email and it also authenticates me using GMail and OAuth and creates an account for me. Part of what I get is a calendar, contact management, and file storage.
I then decide I want to join Facebook. I go to Facebook and instead of creating a new account, I tell Facebook to authenticate me using my GMail email address. When it authenticates me I tell GMail to give it access to my calendar, contacts, and file storage. Facebook creates a new user for me, identified by my email address. Facebook then asks if I have a calendar and contacts and I point it at Apple, who has exposed a CalDav and CardDav server. Since Facebook has been approved for those services Apple is able to validate I am who I say I am and Facebook now has access to my contacts and calendar. In fact Facebook could also use my file storage as the primary place it stores photos and videos I upload.
As a user I get to control my data AND still get access to all the great services I've come to enjoy. We all win.