What we really need is federated authentication, but that doesn't exist yet.
This sounds like a great use case for IndieAuth. w3.org/TR/indieauth
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
To log in to your Gitea instance, I would enter my own Gitea profile URL. Your instance would then do discovery on my URL to find where to send me to authorize the login on my own OAuth server (my Gitea server), which would then send me back to your Gitea where it would be able to verify the authorization code against my Gitea instance.
I'd be happy to walk through this in more detail if you're interested!
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.