I obviously spend a lot of time reading, writing, and listening to bright people talk about the complicated problem of Internet identity. The other day, I unexpectedly had a pop quiz on my ability to explain what the Internet identity community is trying to accomplish. And I had a tough audience: my wife.
Now, my wife is pretty computer savvy for a classical musician. (She'd have to be after all this time around me.) But, as with most everyone else, keeping track of a plethora of website user IDs and passwords makes her crazy. When she was contemplating signing up for LinkedIn, I noticed that "Sign In With Facebook" was an available option instead of creating a local LinkedIn account. I jumped on it, of course. Federated identity! Internet single sign-on (SSO)! Just-in-time provisioning!
The Facebook Challenge
Then the depth of my challenge sunk in. I had to succinctly explain (remembering that, to the rest of the world, identity is just a speed bump in the way of the end goal—in this case, using LinkedIn) why she'd want to go ahead and let Facebook share her data with another website. After all, Facebook has become infamous for violating accepted privacy practices by default, then backtracking when there's an outcry. To add pressure, I knew that if I convinced her and it was a poor experience, it'd be a long time before I could convince her to try again.
After quickly throwing out a number of possible motives why she’d want to use her Facebook creds (see "Federated identity! Internet SSO!" above), I settled on two. First, she wouldn't need to maintain a separate LinkedIn account. Second, although Facebook would supply some identity information, her Facebook password wouldn't go anywhere, because LinkedIn trusts Facebook to provide legitmate IDs. Somewhat skeptically, she agreed to continue the experiment. I was a little concerned about Facebook being the only choice of identity provider. Other identity providers (Google, for example) typically supply the relying party (LinkedIn) with the bare minimum of information, but Facebook shovels a lot of identity data at the relying party.
Sure enough, when she signed in with her Facebook account, the authorization dialog box told her that LinkedIn wanted to access her public profile, friends list, email address, work history, education history, and current city. End of experiment! She was having none of this "kitchen sink" approach. She quite reasonably wanted control over what claims Facebook was providing to LinkedIn. Because she wasn't offered any choice in the matter (and wasn't even offered an explanation of why LinkedIn wanted this information), she opted out of the whole thing.
Game Over, Man! Game Over!
So much for the nirvana of federated logon.
Trust has become a precious commodity on the web, and Facebook in particular has beaten up the consumer's trust in its approach to privacy. But Facebook isn’t alone, of course; if the entire federated logon experience (aka “logon with”) isn't completely trustworthy and clearly explained to the user, it will be a very hard sell to get consumers to trust it. What's needed are clear explanations of why certain types of information are required. Why is it safer to use an existing user ID and password than creating a separate one (and that no passwords make it across the wire)? Why does the relying party need these pieces of information from the identity provider?
In this case, the answer to cloud identity confusion isn’t technical. A little explaining goes a long way.
Related: "Peeking Into the Future of Identity"