IndieAuth is a decentralized identity protocol built on top of OAuth 2.0. Identities are HTTP URIs which delegate to an IndieAuth provider. Badger Who Server should be able to act as an
authorization_endpoint for the Authentication Flow with any compatible IndieAuth client. Note that Badger Who Server cannot grant authorization to clients (as it is only an identity provider), and so will not implement the
token_endpoint for the Authorization Flow.
If the user already has a URI that they can control, this may be preferred over the Badger OpenID Connect protocol, as it is a W3C spec. However, Badger OIDC is used if the user prefers to authenticate directly as an identity on the Who Server.
It's in scope for phase 1 to act as both a provider and consumer (#13) of this protocol.
Note that this ticket was originally about implementing the protocol used on indieauth.com/indielogin.com which is somewhat generically referred to as "web sign-in protocol". The current IndieAuth protocol as far as I can tell appears to be an evolution of the indieauth.com protocol. The intention was originally for users to be able to use Who Server as a drop-in replacement for web sign-in services for clients that wished to support it, with the added bonus of being able to use any of Who Server's other supported identity protocols (in other words, like so).
I feel that's still a worthy goal although it's probably orthogonal to using Who Server as an
authorization_endpoint. I'd need to consider the practicality of this, though - what if, for example, someone attempts to log in to (e.g.)
https://sterling.archer.name while also using
auth.hydrocitynet.org as the
authorization_endpoint? The Who Server would probably need to be smart enough to recognize and avoid attempting to use IndieAuth on such identifiers.
The most likely implementation of an IndieAuth provider would be to simply run remote authentication using the
me value as the identifier. Since the
me value is guaranteed to be an HTTP URI, and is most likely not one natively supported by us (otherwise why use IndieAuth?), the most practical effect is that it ends up basically being RelMeAuth with extra steps.
On one hand, we already plan to support RelMeAuth natively! On the other hand, it looks like IndieLogin.com will delegate to an IndieAuth server, so it would be possible to rel-me link to a profile not supported natively by IndieLogin.com and it will delegate to Who Server to successfully authenticate (and vice-versa, allowing Who Server to delegate to IndieLogin.com for Silo links, and removing the requirement for individual Who Server instances to register as an "app" to each Silo).
Deleting a branch is permanent. It CANNOT be undone. Continue?