On Evolving IndieAuth Followup
Aral's post raises some good issues (which have been captured), but also misses existing known aspects of identity on the web, and indieweb efforts in general. This followup serves to clarify those points in the hopes that we as a community can better communicate these points in the future.
Improving Summary ExplanationIn response to a three-bullet lengthy explanation of what IndieAuth requires, Aral says:
this is not a straightforward process
This is a good point. Any explanation of how to use IndieAuth needs to start with a 1-2 sentence summary. No more.
Compare with: https://dev.twitter.com/docs/auth/sign-twitter (how Twitter sign-in works and how to set it up).
Also compare with http://blog.facebook.com/blog.php?post=41735647130 - How Facebook Connect works and how to set it up / use it.
Signing in is hardAral continues:
Signing in is hard to do
Also true. And has been challenging identity folks for decades.
Avoid Breaking User FlowAral points out:
The biggest problem with the process is that it breaks the user’s flow.
This is true but for a different reason than Aral offers.
Security UX tests have shown that the bounce somewhere and bounce-back web UI flow is much more vulnerable to phishing attacks (originally studied as perhaps the biggest UX problem with OpenID).
I don't have the citation to the study offhand, but a colleague of Rohit Khare did it (he may have the citation). - Tantek
Web native identity requires using your websiteSpecifically:
The user wants to sign in and we are telling them to go away and edit a web page on their own server.
The same would be true if the user:
We know we're actively building the indie web and thus, having a web site that represents you is a core part of web-native identity. Of course it's going to take some setup - web native identity is still very new.
IndieAuth builds on existing behavior
Even if the user has their own server, they may not want to add the provided markup to it to expose their social networks...
The assertion about "may not want to … expose their social networks" is generally false. The default behavior of people with their own websites is to openly link to their social network profiles. This is the existing emergent behavior that RelMeAuth, and the Web sign-in experience, was designed and built-upon.
Not exposing email address phone number
Even if the user has their own server, they may not want to add the provided markup to it to expose their ... email address, or phone number.
Not wanting to expose email address is true in more cases than not, (there are exceptions).
Also, not wanting to expose phone number - also true in more cases than not (also has a few exceptions).
SMS services have very poor (none or almost no) blocking abilities, therefore people in general do not want to expose their mobile phone number publicly to be potentially abused by spammers or other harassment.
However if it was possible to only expose an SMS link to requests from the IndieAuth server, then it may be possible to setup SMS based IndieAuth without exposing the information publicly.
If there were some way know to when a personal web site's server home page request was coming from indieauth.com, then that server could give return more info.
UI instead of code for rel-me
... this step can be automated by tools that create a page specifically for IndieAuth
Yes. That's a logical step. Some sort of home page configuration UI that lets you pick your "other profiles". Actually we've already seen such UIs. Pownce had one. G+ has one. Storytlr is an indieweb project with such a UI.
We should probably document those UIs with screenshots on here on the wiki.
Web is still better than email or phone
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?
Because you are not your email address and you are not your phone number. Already explained. Perhaps we need to expound on both of these further in the wiki:
Physical Identity Non-goal
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.
Straw man. No one is claiming to solve the "strong identity of the physical human" problem.
Short of biometrics (hand/thumb print, retina, etc.) no one will bother - and physical identification has other downsides (can't delegate etc.)
Website selection and control
all we are proving is that (a) you have write access to that web site
That's all we ask. That you control the website/domain you are self-identifying with (by choosing to type it into a sign-in box). That's it and that's plenty good enough.
Why not email or phone number again
we can simply authenticate you using your email address or your phone number
We can't trust those. You don't own those.
Your email you sharecrop on a silo (or if its your own domain, then just type your own domain, simpler).
Your phone number you get from an even smaller number of government monopoly providers. Also not yours.
We can't trust those for persistent identity (the kind you come back to a site with days/weeks/months/years later, like a username).
We can trust them for ephemeral authentication of your web identity (just in the moment, one time, unless they're still on your site). They're good enough for that, because you, the user, can swap them out at any time (burn them), and no website that uses your web identity depends on your email or phone number.
Use Persona for email sign-in
To sign in to a site with your email address
That's a solved problem. It's called Persona. http://www.mozilla.org/en-US/persona/
Ironic email identity breaks user flow
Check your email and follow the link in the email
But "check your email" means you must break your flow!Previously the post said:
The biggest problem with the process is that it breaks the user’s flow
This appears to be a contradiction.
And if there's anything that breaks your flow, it's checking your email and getting distracted by all the crap there.
Boom, you’re in.
More like: Boom, you're now distracted by email hell as you look for an email from a previously unknown sender amongst all the email in your inbox etc.
And you're distracted and no longer signing into a website.
This is precisely why Persona avoids the "Check your email and follow the link in the email" in the normal flow. Only if your email has to use the Persona default provider implementation, and only then on first set-up, do you have to check your email.
"Check your email and follow the link in the email" is to be avoided at all costs.
SMS identity costs and vulnerability
How about with your phone number?
Your phone provider is a government monopoly and is already sending everything to the government, long before websites or email providers did, thus using a phone number as identity is a step backwards from using Twitter or Facebook.
Enter your phone number on the site.
Does this require entering a 10-11 digit number you rarely enter anywhere else? It sounds about as bad as being asked to enter your IP address.
Check your text messages...
What if you're in a foreign country? Yeah fine that's probably a 1% edge case ;)
...and follow the link in the message
What if your phone doesn't have data coverage where you are? Again, foreign country use-case (1%?) or what if you're trying to sign-in on your laptop, not on your phone?
Boom, you’re in.
Or rather, boom, you've just been overcharged for an international txt message, or intl data roaming charges, or both. Yuck.
Signing as just you
In reference to email and phone as identity, Aral wrote:
allowing you to sign in not as ‘you on Twitter’ or ‘you on Facebook’ but as just ‘you’
Allowing you to sign in not as 'you on Gmail' nor 'you on Yahoomail' nor 'you on Insert-Another-Email-Provider-Here'.
Nor 'you on Verizon/AT&T/T-Mobile/O3/Orange/etc.'
You are not a (phone) number.
You on your own domain name is more indie, more free (as in freedom) than all of those.
HTML literacy is here
...does not require us to ask you to … edit an HTML document
Baristas learned to edit HTML during the dotcom boom of "web 1.0"
to add microformats to it.
Not microformats* plural, but microformat. rel=me. 6 characters. 7 if you count the additional space.
This again however alludes to the aforementioned home page configuration UI goal.
Your site should give you a simple usable dashboard that let's you easily one-click add additional profiles for *you* (whether social network / web profiles, email, sms, or perhaps in the future (back to the past style), fax, or maybe even postcard receiving physical address ;)
Avoid yet more DRY violating files
Aral suggests a new file with line-formatted information:
What if you also created a simple me.txt file (ala humans.txt) on your site...
Anyone who can write a plain text me.txt file and upload it can in practice also edit their index.html and upload it and their index.html already likely has this information, their name, hyperlink to their Twitter, hyperlink to their Facebook, perhaps even summary bio.
Asking them to type it again into a me.txt violates two things:
This is much easier than what me.txt is asking for, which is many more steps:
me.txt seems like a lot more work - why advocate for the user to do a lot more work?
Well-known Photo URLs
upload a profile photo called me.jpg or me.png to your website and other sites know to look for that for your photo
"me.jpg" in particular is a hypothetical suggestion and has little merit, yet it is easy to see why this may have some appeal.
The general idea of having a "well-known location" for a photo has some merit, and is similar to the existing behaviour of publishing domain.com/favicon.ico.
Tantek Çelik has been posting his self-images / avatars by convention at:
If that pattern emerges among indie web sites in general, then perhaps we can suggest that as a guideline/fallback in the absence of an h-card with u-photo or u-logo.
New formats are rarely simple
Aral goes on to claim his new format is:
Simple initially, but new and unknown, requiring:
Creating these files and uploading them to a server is no less complicated than publishing HTML, especially as there are vast amounts of resources dedicated to showing people how to use HTML, it’s been stress-tested for years, has proven to scale, is well understood by many, etc.
HTML is the new literacy
Aral seems to have a problem with HTML:
And no HTML necessary.
And yet (perhaps unknowingly) proposes something worse:
HTML is the new punctuation, the new literacy, and has been for over a decade.
If someone complains about learning HTML, send them to https://webmaker.org/about
Everyone should learn HTML, just as everyone should learn how to read and write. And people are learning simple HTML.
Specifically for HTML, start here: https://wiki.mozilla.org/Learning/WebLiteracyStandard/Building/HTML
Well known is not web
Aral claims his well known me.* file locations and formats are:
But still web.
But they're not "web" at all.
”is a system of interlinked hypertext documents accessed via the Internet. With a web browser, one can […] navigate between them via hyperlinks”.
Not interlinked, not hypertext, not navigable in a web browser, not the web.