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.

NASAR, courtesy of Wikimedia commons

Courtesy of Wikimedia Commons, the blogger’s best friend.

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?

Say, with your email:

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.

Hey, if it can’t figure out your IDP and you think it should be able to, drop me a line with a hint. Alternatively, consider putting up a Webfinger or WebFist entry to help.

findIDP does JSON output too, just change the URL from report?m= to find?m=. I’ll publish the source one of these days. While it’s now a Go program on App Engine, it could (and maybe should) be JavaScript in the browser. Only I want a 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 experiment.

And the idea’s not mine; I first saw it done well by Blaine Cook (A.K.A. @blaine) in a beta for his fascinating startup Poetica.

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.


Comment feed for ongoing:Comments feed

From: Geoff Arnold (Sep 15 2013, at 22:40)


Recommended IDP for is <none found>


From: Piotr Kaminski (Sep 16 2013, at 00:40)

Hmm, not convinced about the IDP Finder. Perhaps I'm atypical but I have the same email address registered with Google, Facebook and Microsoft (and who knows where else). The Finder only selects Google, but even if it could probe FB and MS how could it possibly know which of the three I'd like to sign in with on any given site? At best, it could tone down the NASCAR a bit, but not eliminate it.


author · Dad
colophon · rights

September 15, 2013
· Technology (90 fragments)
· · Identity (43 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.

I’m on Mastodon!