If we decide we want to support diaspora* as a generic authentication provider for applications this could be a nice proof-of-concept and a little show-off project. However, given the complexity around that, I am not sure if we actually want that, and given the additional effort to implement an auth-with-diaspora based around dynamic client registration, I am also not sure if this is something applications would actually want. Even if we built something, I fear this will stay a very exotic project forever, and not gain much public traction, if any.
As for Discourse, the rate of GitHub signins here is very high, and that was somehow expected, as most people who participate in development related questions probably do have a GitHub account anyway. For others, signing in via eMail doesnāt seem to be too much of a hassle. I donāt see huge wins here.
That being said, if this is something you want to work on, I will certainly not block you, but there will be a lot of discussion involved.
I just discovered this document which looks fresh. I looked through it and it probably contains some specifications which we might find useful in our case. Iāll read it more thoroughly later and will try to figure out whether it is useful for us or not.
I think asking a user for their diaspora* ID upon sign in is not that bad, itās how OpenID auth works and certainly not worse than asking for an email address and password. Then for future sign inās we could remember that ID in a permanent cookie and prefill the field. IIRC OpenID connect allows to send that along in the auth flow so the target pod can prefill the sign in field in case the user is not signed in currently, so the user wouldnāt need to enter it twice with that approach either.
We need that UX flow anyway in case somebody with accounts on multiple pods wants to have their link handler on one pod but sign in with another.
This thing is implemented by browser too. If you registered more than one link handler there will be a window that asks which one do you want to use to handle the request.
So this OIDC Federation document I mentioned above specifies the thing which is called āImplicit registrationā. This is the thing that might help us to achieve the auto-detected pod login. This document specifies the way to send an authorization request with a relaying party (client) URL instead of the client ID, which then will be used to resolve this client and register it, and then authorize the user to this client. So no prior registration required and therefore one initial authorization request is enough to make the authorization possible (everything else is just done in the background).
Itās totally possible to implement authorization with explicitly asking the userās pod URL. But above I outlined why I feel it is better to be able to sign in via diaspora without this. And that is how some service owner might feel about this feature. In the end of the day it is up to the authentication plugin implementation to ask the pod URL explicitly or not. I think it is important for us to provide some means for auto-detection during the OIDC sign in. I think that it is important that some service providers could integrate the āsign in with diasporaā feature that works the same way as other social networking software. If anyone has problems with this, there is no reason why the authentication plugin canāt ask for the pod host name explicitly. But if some owner of a Discourse deployment wants auto-detected sign in, I think we should allow this to be possible technically. This is why I want to work on this proof of the concept.
To avoid asking an information to the users if it can be obtained otherwise is almost always a good thing, so yes, a way to have a simple āLog in with diaspora*ā button would be nice.
However, I donāt want all websites that I visit to be able to know the diaspora* account attached to my browser without any explicit actions from my side.
So can the first problem be technically solved without leaking my diaspora* id without asking me?
(Btw, Iām super okay with you working on the āSign in with diasporaā feature, even if it is not widely used here on discourse, it is a nice proof of concept for others to implement elsewhere).
The authentication/OIDC client (e.g. a Discourse instance) redirects your browser to a web+diaspora://something
Your browser asks you what to do with the link in a dialog or it redirects you right to your pod if you set ādonāt ask meā in this dialog before.
Your diaspora pod registers the OIDC client as such using the āimplicit registrationā from the OIDC Federation protocol
Your diaspora pod asks you whether you allow to sign in to this client app using your diaspora* account
If you agree youāre redirected back with an authorization token.
So in this case there are at least two points where you can block the remote resource from getting your identity unwanted - when you follow the web+diaspora:// link and when you approve the requested permissions by the client. So no, Iād say itās not possible that your identity will leak without asking you.
In the worst case it is possible that your diaspora pod host name is leaking when registration request is issued to the client before you were asked for the permission, but that could be solved by swapping point 3 and point 4.
