On evolving IndieAuth.
Thoughts on how we can improve the user experience of IndieAuth. (5 minute read.)
In its current incarnation, IndieAuth requires the following, as outlined by Barnaby Walters:
- One or more of: an email address, a phone number capable of receiving SMS messages, or an account at one of the providers listed here [Twitter, Facebook, etc.]
- a domain name which resolves to an HTML page containing the following markup:
<a rel="me" href="">Me</a>where the value of
hrefis either the URL of your profile on the aforementioned provider, a
- for the account (if chosen) to link back to your domain — usually there’s a ‘website’ field when editing your profile
Needless to say, this is not a straightforward process.
Signing in is hard to do
The biggest problem with the process is that it breaks the user’s flow. The user wants to sign in and we are telling them to go away and edit a web page on their own server. Even if the user has their own server, they may not want to add the provided markup to it to expose their social networks, email address, or phone number. It is, of course, possible that this step can be automated by tools that create a page specifically for IndieAuth in the future. But we need to ask ourselves whether this step is even necessary.
In addition to using rel="me" links between a web page on your own site and a social network, you can also use your email address or a phone number to authenticate via IndieAuth. Now this seems like a much better idea to me. However, if we can authenticate with an email address or a phone number, why do we need all the web page malarkey to begin with? Ah, I think we’re starting to get somewhere in simplifying this process…
Now consider what we mean by authentication and identity. Regardless of how many hoops we make you jump through, are we ever actually identifying you as the person you are? Do we have a way of knowing, via IndieAuth, that you are really the walking bag of mostly water that you claim to be? No. If we authenticate via rel="me" links between your web site and your Twitter account, for example, all we are proving is that (a) you have write access to that web site, (b) you have the username and password for a Twitter account. That’s it. The problem we’re trying to solve here isn’t to identify you but to make sure that the credentials you provided when you first signed in are the same in subsequent sign in attempts so we can give you access to your account.
If that’s the case, we can simply authenticate you using your email address or your phone number, we do not need your domain and that whole extra step.
Now, I realise this goes against the whole Indie Web bit of IndieWebCamp but that’s one of the reasons why we also need a more generic banner like Indie Data under which we can formulate solutions that don’t necessarily depend on the web and web technologies.
Indie Auth 2: no web site required?
So how would you authenticate if you removed the web site requirement? Easy.
To sign in to a site with your email address:
- Enter your email address on the site.
- Check your email and follow the link in the email.
- Boom, you’re in.
How about with your phone number?
- Enter your phone number on the site.
- Check your text messages and follow the link in the message.
- Boom, you’re in.
We can even be clever about it: Say you entered your phone number on your notebook computer and you get the text message on your phone. When you follow the link in the text message on your phone, we can automatically sign you in on your notebook computer (via a shared token that gets sent in the message).
This, too, may break your flow slightly but it is nevertheless a huge improvement on the first‐time sign‐in experience at the very least.
Solving the right problem
So I propose that we solve the correct problem which, as stated on the IndieAuth home page, is allowing you to sign in not as ‘you on Twitter’ or ‘you on Facebook’ but as just ‘you’. Solving this problem does not require us to ask you to own your own domain name and edit an HTML document to add microformats to it. That’s the solution to a different problem (‘how do we get people to set up their own web sites and use them as the canonical location for data they want to share’). Solving this problem merely requires us to authenticate that you have the same credentials you had when you first signed in (or to detect whether this is your first sign in) and give you access to either your existing account or a new one. That’s it. That’s all Indie Auth should do.
Once we understand the actual problem we can limit our solution to the simplest one for solving just that problem.
Now, later, if we also want to tackle the problem of populating a person’s profile, we can then ask for a domain name.
This is where, if the user has a domain name, we can create a simple system — using convention over configuration — to get their profile information. Let’s call it Indie Profile for now.
For example, how about a standard where you upload a profile photo called me.jpg or me.png to your website and other sites know to look for that for your photo. No HTML necessary.
What if you also created a simple me.txt file (ala humans.txt) on your site:
Name: Aral Balkan Twitter: @aral Facebook: aralbalkan Bio: Experience design + open source = freedom for mere mortals.
Now, if you want to automatically populate your account, you can give the site that supports Indie Profile your URL (eg.http://aralbalkan.com) and the site would know to look for http://aralbalkan.com/me.jpg (or .png) and the me.txt file.
Simple. And no HTML necessary. But still web.