This is part of the Federation Conversation, where commenter Jashan worried, reasonably enough: “Users tend to forget which of the gazillion available services they have registered at your site with. And then they're too lazy to try all the possibilities. And then they're gone.” Ouch!
On the other hand, they might show up at your IDP-free site and forget what username they’d logged in with. Or they remember that but forget the password. And then they worry they’re trying the wrong username.
Which is to say, as with many other Identity issues, it’s hard. But we can agree: The less cognitive load it takes to get into your site, the more people will.
It’s like the racing cars · When identigeeks talk, the term “NASCAR page” is often bandied about. Here’s a memory refresher.
What we’re talking about is a page where you show up and it’s got sign-in badges for Facebook and Google and Twitter and Amazon and Persona. Too many badges and stickers, just like the stock cars. (Watch out for pile-ups in the corners of your branding!) And yeah, it’s perfectly reasonable to worry about people forgetting which they used.
There’s another problem with this approach. I have no idea what the right number of IDPs is, but I’m pretty sure it’s more than two. And who wants to clutter up their login page with a bunch of IDP gadgets? NASCAR pages are not only ugly, they don’t scale.
There are two approaches I know of to help people with this.
AccountChooser · I’ve written about this; it’s been ready-to-go since late last year. The idea is that your browser keeps a local list of the email addresses (and IDPs, if used) that you’ve used recently to log into one thing or another. It’s easy to integrate with and has a good privacy story and if you do it right, a high proportion of people will get one-click sign-in and two-click initial-sign-up (the extra click is when the IDP asks for approval).
This should be very attractive for site operators, and it will be. But not quite yet; there’s a tragedy-of-the-commons situation, because AccountChooser relies on all the sites that use it to build up its memory, so the payback is poor for the first adopter, so there haven’t been many.
The OpenID Foundation is cooking up what I think is a good solution; provide an API for IDPs to pre-load the AccountChooser, so that when some site decides to give it a try, chances are that people’s favorite accounts will be there, ready to go.
I think AccountChooser has legs, and is robust in the face of any number of IDPs (because all you see are the ones you’ve used); stand by.
IDP Finder · We have to ask people to remember something. So, what’s the simplest thing anyone could ask ? I’m thinking email address. Everyone has a small number of them, you can type those on pure muscle memory, and a mental mapping between your addresses and the places you log into is, quite possibly, not too much to ask. (In case it’s not obvious, I haven’t made up my mind.)
So does that mean no more federated login? Back to the days of emails and passwords? No need for IDPs?
Um, no. But at this point, I have to acknowledge the offstage shouting from the Mozillians who say, essentially, that signing in with your email means Persona; check out the closing stanza in Austin King’s writeup.
Maybe. But maybe not. I think that people are going to sign in with the help of lots of different IDPs, and I think they’re often going to do it with their email addresses. So, if you’re going to be email-based, and you’re going to do federated sign-in, you have to be able to figure out which IDP to use for which email.
So I built some software to do that, to show that it’s easy. Why not give it a try?
The idea is you type in your email, the site automatically figures out which IDP to log you in with, then does it; no muss, no fuss, no NASCAR.
Nothing terribly fancy is happening here; it just tries a bunch of heuristics to see if there’s an obvious IDP for the email; I could go on at length but the results readout is pretty self-explanatory and the heuristics are a work in progress; lots of stuff left to try.
findIDP does JSON output too, just change the URL from
find?m=. I’ll publish the source one of
While it’s now a Go program on App Engine, it could (and maybe
server side because I’m going to run a version with a database, for people
who want to assert their IDP, not have some program guess it. Just an
Take-away · Minimizing cognitive/memory load is potentially one of the biggest payoffs for getting out of the password business and into Federated Identity. It’s easy to stumble into a NASCAR page, but there are least two ways I know of to avoid that, and I bet there are more being cooked up right now.