Specify RelMeAuth as fallback.

[Zegnat]

If an IndieAuth Client doesn’t find an authorization_endpoint during discovery, it should fallback to doing RelMeAuth as per user expectation.

This issue was created in response to @tantek writing on the wiki:

IndieAuth authentication services should handle rel=me without needing an explicitly specified endpoint.

I personally do not think the spec should be updated to require clients to implement RelMeAuth, but this does seem to be a discussion that needs to be had.

There was a discussion in #indieweb-dev about this that I will not reproduce here and should be read for full context. Starting at 8:06, ending around 8:43.

From chat

Some points I found to be particularly essential by @tantek:

• adding steps to user setup is usually a way to lose users and have a more failure prone system

• part of "using IndieAuth" should be it "just works" even if you *only* setup rel=me

• the burden should be on provider devs, not millions of users

• if the current spec forces every user to add a second item of configuration then it is broken from a usability perspective and very much not fine

• the non rel-me uses are <1% noise in comparison currently

(I am quoting verbatim, trying not to skew the argument. But please go and read the full chat.)

My counter points:

• First a repeat of the arguments I previously stated in the renaming discussion. I believe all implementations have always used the correct names for things and have not mixed RelMeAuth and IndieAuth.

  • Basically nowhere that advertises IndieAuth that I use (Telegraph, Quill, Omnibear) will let me use RelMeAuth.

  • Only the wiki does, but then again, the wiki *never* claimed to use IndieAuth, it always referred to its login as /Web_sign-in and mentioned IndieAuth as an *alternative*: https://indieweb.org/File:indieweblogin.png

• I am just not sure how you would codify the fallback if no auth-endpoint it linked into the spec, without discouraging implementers.

• I for one would never have written an IndieAuth implementation if it had to offer a RelMeAuth fallback... the only fallback I can imagine supporting is on mailto:-links, and that’s not useful for most people.

Expanding on “discouraging implementers”

This is a point I feel more strongly about than any actual naming confusion. If the IndieAuth specification starts requiring a fallback to RelMeAuth, I expect IndieAuth client implementers to start doing one of two things:

1. not implement that part of the specification at all, or
2. relying solely on indielogin.com.

If 1, it means we will see many partial implementations and referring to the specification as a standard loses a lot of value. If 2, the decentralisation part gets lost to some extend which may harm the “platform agnostic” and “longevity” principles, turning IndieAuth implementations into a monoculture.

I believe this will happen because implementers will not want to host aaronpk/IndieAuth.com or want to register every Client as an application for countless silos. RelMeAuth is undoubtedly easy on users, but an extreme chore for implementers. So much so that I as Client implementer can already state with certainty that I will not be supporting it.

[Zegnat]

Something I realised when going over this with someone else: a fallback to RelMeAuth can still lead to huge differences in user experience. If the reason for the RelMeAuth fallback is so this specification emulates current wiki login behaviour, it will also need to specify which authentication providers MUST be supported.

Examples:

1. If the user is using Twitter as RelMeAuth authentication provider (as supported by aaronpk/IndieAuth.com) to login to the IndieWeb wiki, there is no guarantee they can do this elsewhere. Twitter support isn’t a requirement of either specification.

   This goes the other way around too: an implementation might support Tumblr’s OAuth for authentication, something aaronpk/IndieAuth.com does not support.

2. If the user is using email as RelMeAuth authentication provider (as supported by aaronpk/IndieAuth.com) to login to the IndieWeb wiki, there is no guarantee they can do this elsewhere. The RelMeAuth standard only talks about “links to profiles on OAuth supporting services” as authentication providers and not email, GPG, or SMS.

If this is not addressed I am not sure how a fallback to RelMeAuth can make IndieAuth any more “just works” than it already is.

The current specification would require the user to add link to the RelMeAuth implementation they want to use on their page (e.g. setting authorization_endpoint to https://indieauth.com/auth for aaronpk/IndieAuth.com). This means the user will truly have the same experience no matter where they login.

[EdwardHinkle]

Another thing to consider is the purpose of the IndieAuth flow. There are currently two types of login with IndieAuth: Authentication (https://indieweb.org/indieauth-for-login) and Authorization (https://indieweb.org/obtaining-an-access-token).

In my opinion, RelMeAuth only makes sense for Authentication (Proof that the user is who they say they are) which is much less common outside of the IndieWeb Wiki. Most IndieAuth uses outside of the Wiki are Micropub apps, which require the Authorization workflow. If a user is going to have a Micropub and Token endpoint, it is not much of an extra burden to have them add an authorization_endpoint as well.

The one place I can see RelMeAuth fallback becoming helpful would be in implementing Community Sites (https://indieweb.org/Micropub-brainstorming#Users_using_their_own_identities_to_log-in_to_a_community_blog) where the authorization_endpoint, token_endpoint and micropub endpoints are developed by the community blog. It would then make sense for the individual users that are simply authenticating with the community blog to be able to use RelMeAuth in order to simply and quickly log in to that blog in order to use it with a Micropub client.

Thus, if RelMeAuth is added to the Spec, I would propose that it is added as a fallback for the Authentication flow, but not for the Authorization flow for Micropub clients. This would create the clear delineation between IndieWeb Wiki and Community Blogs that are doing Authentication and Micropub clients that are doing Authorization.

[Ruxton]

Basically nowhere that advertises IndieAuth that I use (Telegraph, Quill, Omnibear) will let me use RelMeAuth.

I feel like it's worth pointing out RelMeAuth is Authentication, while indieauth.com is Authorization and also a RelMeAuth implementation. The 3 you mention require authorization tokens, RelMeAuth does not cover this.

[sknebel]

Small nitpick: Telegraph doesn't do anything requiring authorization to the site you log in with. (It has tokens for its API, but that is not relevant for the login).

As noted on the wiki already last year, I generally agree with what @Zegnat says on this issue. It's clever to fallback to other URL-based auth methods (RelMeAuth, OpenID, possibly login with profiles directly as e.g. @sebsel implements on his site) where desired and the spec should mention this option, but this should not be part of the spec.

Explicitly documenting RelMeAuth as a spec might be interesting, although I think the complexity is primarily in the implementation and less in the spec (unlike IndieAuth).

[aaronpk]

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.

[aaronpk]

Going to close this issue now as indielogin.com has been live for over a year, and now users signing in to the wiki will not see the term "IndieAuth" at all unless they have explicitly added IndieAuth support to their website.