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.
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.
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.
Not that it's your fault, but I think you're starting to confuse the two roles of indieauth.com.
Role 1) indieauth.com is a service that developers can use to handle all the hard work of doing rel-me-auth with specific providers directly. In this case, the application developer has a trust relationship with indieauth.com and users should not be concerned that they're using indieauth.com, from their POV they are just signing in to the website. This is how the indiewebcamp.com wiki uses indieauth.com
Role 2) indieauth.com is a service that users can delegate their domain to. To use indieauth.com this way, the user links to indieauth.com as their `authorization_endpoint` on their domain. In this case, the user has a trust relationship with indieauth.com, and an application discovers the user's auth endpoint by following the rel link on their website. Micropub apps like Quill work this way, where you will only ever see indieauth.com if you have delegated to it yourself.
Does this help clear things up? In situation 2, you'll only ever see indieauth.com if you explicitly set it as your authorization endpoint. You could use indiecert.net or use your own auth server instead. In situation 1, where a developer has chosen to use indieauth.com instead of implementing authentication themselves, you're limited to the options that indieauth.com has implemented. However the idea is that indieauth.com implements a good number of options and in a secure way, making it a better option for developers than implementing PGP/SMS/GitHub/etc themselves.
With that in mind, could you rephrase your request in that context?
Hm, would you want to delegate to the `pgp` one to prevent any other login mechanisms from being used? One of the nice things about indieauth.com showing multiple options is that depending on the device you're logging in on, you might want to choose a different option. For example I usually use GitHub or GPG login when I'm on my main computer, but use Twitter from my phone.
I can definitely see value in wanting to limit the options provided by indieauth.com to a subset of the rel-me links on your site. (Maybe I want Twitter listed on my site, but never want to use it for login.)
What about using the query string to indicate the supported providers?
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.
@starseerdrgn GPG is also supported. The goal is your domain is your identity. The authn mechanism is secondary. Happy to talk more about the motivations behind IndieAuth, since decentralized authentication is absolutely the goal.