This spec intentionally doesn't specify how users authenticate themselves to their server, it only deals with how third-party clients can authenticate users where their domain name is their identity.
The analogous version of this in RelMeAuth, with Google as an example, is such: as far as the RelMeAuth client is concerned, it sends the user over to Google, and expects Google to handle authenticating the user. This might involve entering their password, optionally followed by a 2fa mechanism like a Yubikey or TOTP code. That is all invisible to the site they're logging in to.
Similarly, IndieAuth clients do not know how users authenticate to their own server, the client just expects to send them off to the authorization endpoint and get back a response later that can be verified.
It is not a good idea for a spec to require any sort of authentication mechanism between the user and their own authorization server, which is something that the OAuth 2.0 spec has also made clear.
Now, the rest of this conversation is essentially continuing the naming debate of indieauth.com vs IndieAuth the spec vs other options we've considered.
I agree with many of @tantek's points, like
... should be it "just works" even if you only setup rel=me
However, that is describing RelMeAuth, not this spec. And as @Zegnat pointed out, even just adding rel=me isn't necessarily going to guarantee that you can sign in to an arbitrary site that supports RelMeAuth, since you need to add a rel=me link to a service that the site you're signing in to supports, which requires that site to register an OAuth application and deal with that service's API.
I'm in the middle of renaming indieauth.com, the goal is that the wiki will redirect users to indielogin.com to authenticate them using the existing mechanisms: RelMeAuth, email, PGP, and IndieAuth. Nowhere in that flow will users see the term "IndieAuth" unless they include a
rel=authorization_endpoint link on their website to an IndieAuth server of their choosing.
I definitely agree that signing in to the wiki needs to be as simple as possible. That's the reason I added so many OAuth providers as well as alternate methods to indieauth.com (soon indielogin.com) in the first place. We've even had some people who want to sign in to the wiki but don't have a Twitter or GitHub account and don't want one, which is why I added things like email and PGP authentication options, which were not described by RelMeAuth.
This is all to say that it's not the goal of this spec to include RelMeAuth. This spec is intended to be just the URL-based extension to OAuth 2.0. If "IndieAuth" is not the right name for this spec, that's a different issue.
It's been a long time coming, but I've finally published a proper IndieAuth spec!
IndieAuth has been around for years, and is even referenced by the Micropub spec. But until now, there wasn't a canonical version of the spec all in one place. Previously it existed as a series of how-to guides on the IndieWeb wiki. Arguably it's actually more useful that way, since the whole point of specs is to communicate a consistent way of implementing something. But it did make it awkward to refer to it formally.
So I'm happy to say that there is finally a spec for IndieAuth, at https://indieauth.net/spec/
This document captures the current state of what has been implemented, and incorporates much of the feedback we've gathered over the years. Most of the document is split up into authentication and authorization sections, for when you are trying to just identify users for sign-in in vs when a Micropub client is trying to get an access token to post to the user's site. Formally it's an extension to OAuth 2.0, and makes several decisions that were left un-specified in the OAuth 2.0 core spec.
Beginning a slow project of updating the docs about the IndieAuth spec, today I started by updating a few pages on the wiki. Right now, most of the docs about IndieAuth (the spec), and how to use it, live across a variety of pages on the wiki, grouped together at https://indieweb.org/Category:IndieAuth.
My goal with the spec IndieAuth is to make it an extension of the OAuth 2.0 spec. It has always been based off of the OAuth 2.0 spec, but I've never written it up properly as an extension. It's always been just a series of how-to guides. Additionally, I had originally started by specifying all of the responses being form-encoded responses, whereas the OAuth 2.0 spec says all responses must be JSON format. I've been slowly converting my various apps that use IndieAuth to support both, based on the HTTP Accept header, although I haven't publicized this much yet.
Today's project was updating the existing IndieAuth documentation on the wiki to explicitly include the JSON versions as a valid response format.
Eventually I hope to write up IndieAuth as a formal extension to OAuth 2.0, in the same format that something like the Device Flow is an extension.
Sadly, Clef is shutting down in a couple months. If you haven't heard of it, it was a clever way to use your email and a mobile app to sign in to websites. I had integrated Clef logins to indieauth.com as one way to authenticate your email address. Since they are shutting down in June, I am proactively removing it from the website right now.
The other method for authenticating your email address is is to receive a verification code sent to your address, which I will of course continue to support.
While I was in the code, I figured it was about time to retire SMS authentication as well. While conceptually receiving a code via SMS or email are equivalent, in practice this is not true. SMS is actually a pretty insecure protocol, and it's possible (and not that expensive) to intercept SMS messages to all phones in a nearby area if you have the right hardware.
So as of today, SMS authentication is no longer an option for indieauth.com, and you will have to receive verification codes sent to your email instead of using the Clef app. I may bring back SMS support in indieauth.com as a second factor authentication in the future.
Here is my list of providers I use now.
Today I updated the documentation for indieauth.com to include a setup guide for using indieauth.com as your OpenID provider, and added more prominent links to the OpenID and PGP instructions in various places on the site.
The header bar and footer now include direct links to PGP and OpenID setup instructions. The main setup page also now links to the PGP setup page and includes an example of linking to your PGP key along with the other example providers.
I wrote a setup guide for configuring indieauth.com as an OpenID provider.
At this point, OpenID 1 is almost completely gone. There are only a few sites that still consume it, and most of the former major providers have all shut down. Quite a lot of people have migrated to using indieauth.com as their provider since it's one of the few remaining services online. Hopefully this new setup guide will make it even easier to find for people looking to migrate.
I just launched an update to p3k which adds an integrated authorization server. This means that now when I sign in to Micropub apps like Quill, it will redirect me to my own server where I can have more fine-grained control over the access I am granting the application.
My new authorization endpoint displays the scopes the application is requesting, and lets me modify the scope when granting the request. This means if an application I don't yet trust requests the ability to update or delete my posts, I can un-check those boxes but still allow it to create posts.
I also have the ability to have all posts from an application be added to a specific channel, rather than showing up in my main feed. I use the concept of "channels" to create different lists of posts depending on what kind of content the post has. For example, /photos contains all of my photo posts, and /travel contains travel plans, plane flight and train logs, and events that occur outside of Portland.
Now that I have a built-in authorization endpoint, I'm looking forward to adding more features to it, such as setting the default privacy of posts so I can allow an application to create posts that are only visible to me (or a specific audience) unless I make them public.