Like most people, I like getting a good deal. I'm also not much of a cook, though I'll occasionally whip up a batch of incentive and make something interesting. What do these two random factlets about me have in common? They led me into examples of a poor identity federation implementation with Groupon and Facebook, and an excellent one with AllRecipes.com and Google.
Why federation is goodness
Identity federation provides the ability to use a trusted identity provider (IdP), such as Facebook or Google, to authenticate a user to a relying party or service provider (SP), such as Groupon or AllRecipes.com, without supplying a password to the service provider. In these scenarios, this enables you to sign up or login to a Groupon or AllRecipes.com using your Facebook or Google userid and password rather than creating a dedicated account for Groupon or AllRecipes.com. Once you’ve successfully logged in, you don’t even need to supply a password; you get single sign on (SSO) to the site. Unfortunately, only about 7% of the 25,000 SaaS websites currently available support federation. And even when they do, the implementation may scare away any privacy-conscious user.
Given a choice of identity providers to leverage when logging in to a service provider, I generally choose the IdP that has the least data about me. In loose order of preference, this translates to Twitter, Microsoft, Google, and finally, Facebook. The first three generally require only my email address and a few other attributes, such as profile information I share publicly. Facebook, however is a whole other matter. I've written before on how Facebook throws a plethora of user identity attributes at a service provider when you use it as identity provider for a federated login. I'm still on the fence as to whether the benefits of using Facebook as an identity provider (not creating an account on some service provider with questionable security practices, more identity management on my part) outweigh its disadvantage (throwing identity data willy-nilly at any SP that asks for it).
Groupon and Facebook: 5800 identity attributes
This leads me to explain my Groupon experience. When attempting to set up a Groupon account, I had the option to create a Groupon userid and password, which also requires an email address, or do a federated login using Facebook. I opted to try out the Facebook login to see how intrusive it is. Was I in for a surprise!
For the convenience of not creating and keeping track of a separate userid and password, Groupon wants access to roughly 20 of my Facebook identity attributes…and the same from everyone in my friends list. I have 288 friends, so that translates to potentially 5780 bits of identity data they collect for a single login! Of course, your mileage may vary depending upon how locked-down your Facebook profile is, but given the Byzantine steps you must take to lock down Facebook data, most people don't bother with anything beyond the most rudimentary settings.
Federation adoption is slow enough already without this behavior. Would you encourage your friends to use a federated login that shares this much identity data?
This wholesale collection is in violation of the Second Law of Kim Cameron's Laws of Identity, which states, "The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution." In other words if you, service provider, don't actually need the identity data to provide your specific service - what you can do today - don't ask for it. Don't ask for a whole bagful of identity information, just in case it might come in handy someday. When the inevitability of a data breach comes knocking at your door, you'll have given that much less information away.
AllRecipes.com and Google: Choose what you wish to share
AllRecipes.com and Google provided me a contrasting experience. I was looking for an easy-to-execute black beans and rice recipe (due to my EE training I treat all cooking as a lab experiment), and I’d seen from my wife that AllRecipes.com had a very tablet-friendly interface and great ingredient-based search engine. Wanting to save the resultant recipe in my Recipe Box, I had to login to the site. Following my rule of choosing an IdP that has less information about me, I chose Google. To my pleasant surprise, I saw that I was able to choose how much information Google provided AllRecipes.com (note the pencil icons):
Some basic identity attributes, such as my email address, were not negotiable, but I could control what data it provided about the people in my Google+ circles:
A good example of the First Law of Identity (User Control and Consent), this is a real step towards making consumer federated login more acceptable, and hopefully more widely adopted. The convenience is undeniable, but it’s the user control that tips the scale towards using it over a separate userid and password.
So pay attention, service providers. Give the customer as much choice as possible over their identity data, and they will use your federated login. Remember: You don’t want to be in the news as the breach of the day, having passwords in your user database exposed. Most of you aren’t in the identity business; it’s just a way to control access to your real business. Leave the identity management to companies that have hundreds of employees focused on it.
I’m pleased with the overall experience using AllRecipes in the kitchen. It’s tablet-friendly, and that makes my lab experiments, uh, cooking, that much easier.
And I still don’t have a Groupon account.