I despise the Nascar-effect of social login widgets, and apparently users to do

If so, why do you propose OpenID/OAuth ?

I really like some of the other suggestions, like suggest previously used accounts, tracking login failed accounts and use follow up forms after registration.

A minimum password length of 12 is counter productive and does not improve UX

One of the things that improved UX on my site, is client site checking existance of the email address during login/registration, using java and checkdnsrr. It avoids misstype email addresses and off course false registration validation emails.

Another one is suggesting usernames, based on email addresses. Less chance they don't remember and also less chance of already existing names.

One of the fears users have with social login (which is unjustified) is that the site will have their password from the login provider. I have heard that many times.

I wish to comment on this hot and interesting topic but the discussion posted on this link concerning the future of password holds me back from giving my suggestion. Here is the link concerning where the state of social login is heading.  http://community.elgg.org/pages/view/1525775/the-end-of-password-or-password-is-dead

Would it be an idea to check for certain cookies on the users browser that either facebook, google, persona,openID,...use, to see if the user is using one of these logins? If the cookie is there, hand them the loginbox for that IDsystem without any questions or other proposals, if it isn't give them the default option of your website. Just an idea...

My site is not ready yet, and I've been thinking of what to do with it for a couple of months now.
For myself, I'm kinda thinking of using only one system, either 'OpenID connect' or the default Elgg auth system. I want to be independent and from my own experience on the net, I never use facebook or google login boxes if I can make my own login as well, I always make a new login for that website. But maybe I'm just too old fashioned about this.

The only option I might want to give 'em is Facebook and the only reason for that is that I can fetch information from their profile to fit into my sites profiles

OAuth is a road to hell. BTW, Eran Hammer, lead OAuth2 project author, works under oz project now

This is referring to the developer experience, not the User Experience. "Sticking with passwords" is not a realistic option for me because of the User Experience issue.

Mozilla Persona is a good solution.

I liked Persona a lot and hoped for the best but it doesn't look like its doing very well. It has the following downsides for me:

• Adds another brand to the mix (beyond the expected site-I'm-logging-in-to and identity-provider)
• Doesn't give you much control over the UI (stuck with Persona's UI)
• Restricts flexibility in terms of what information you can get from IdPs (Asking for anything beyond email was considered a privacy breach, but a lot of times getting basic profile info is a genuine value-add for the user and the site-to-be-logged-into).
• Doesn't support Google Apps domains, and won't any time soon because it's been defunded.

A good way to understand my proposal is that we just take Persona's login flow and bake it into Elgg:

1. User provides email address
2. If its backed by a supported IdP, send the user through the auth flow of that IdP, requesting only email-address validation.
3. If IdP doesn't support any kind of special auth flow, and the user has already set up a password with the site, let them enter the password they sent.
4. If they forget their password or haven't set one up yet (new user), send them an email-with-secret-code that they can click to log in and change/set the password.

If [you hate the Nascar effect], why do you propose OpenID/OAuth ?

Because the user can tell you which IdP they want to use without you listing all supported providers up front. They do this implicitly when they enter their email address. If I type a gmail.com address then we can assume you'd like to "log in with Google" for example. If the user rejects this flow, we can just fall back to the send-email-with-verification-link flow.

client side checking existence of the email address during login/registration

I do like this if it can actually be done reliably. If there is an OpenId/OAuth flow it seems like this becomes irrelevant because the IdP is trusted to assert a valid email. From our discussion on github though it sounded like it is easy to get false negatives with this server-side check you propose. How do you deal with that case?

[There is a fear that] the site will have their password from the login provider.

Ah, interesting! Hadn't considered that. Wonder how widespread that sentiment is.

clarifying the overall intention/desire around the whole 'trusted identity' concept would make this exploration simpler.

for example, besides making the login process simpler - what is the value that is sought with regards to the process and logging in with a 'trusted' identity?

what constitutes a 'trusted identity'? does google's use of cell phone connection to attempt to establish 'true identity' of a profile, equate to truly knowing that the user of a profile is who they claim to be? not to me it doesn't. many of these techniques, as best, only limit the amount of individuals that can fake a profile and mislead with their identity slightly. as long as you are trusting the dominant corporate paradigms (technology companies) with the responsibility for managing and also with accessibility to the data and technologies that are used to establish identity, you are continuing to empower the ones in those groups to dominate further and further (until this becomes so obvious that no-one goes along with it any more) - which is the most obvious flaw in this approach to me. ultimately, i am not aware of any method that can provide any real assurance that those who login to a profile are who they say they are, so that (to me) totally negates any perceived benefit of using an 'identity broker' type service from a corporate entity and makes these services seem little more than spying and monitoring tools for whomever has access to the 'big data' they are collecting... (which is not 99% of us). if ease of use is the target, then there are other ways to achieve that which do not extend beyond elgg.

resolutions i see to the issues raised in the thread:

• We have a bunch of people (think 12+ people in a sub-community) share the same account info. - elgg is designed for one user per profile, however, if a group wish to share that profile, then that would most effectively be resolved through a new plugin type of 'shared profile' or similar. no need to change the core login process for all for that.
• Simple passwords (easy to remember but also short and easily guessable). -  improving the handling of the process of changing the minimum length of the passwords, such as prompting users to change their password automatically if the admin sets the minimum password length to be higher than the current value - would help. also providing advice for choosing strong passwords and an option for only allowing strong passwords, would help.
• I just use the same password for everything so I don't forget!  - this is a free will choice being made by a free will being! although it is not necessarily such a wise choice - there is little we can do about that. if their profiles are hacked, then they will think differently in future. like the previous point, this can be addressed through nicely presented information in relevant places, advising the best practices for password security.
• Asking me in person to help them log in or reset their password: improving the ui design of the entire login and lost password process would help. this would include more precise languaging, clearly defined info boxes and maybe some symbolic images, for example, to associate the concept of e-mail with an email type icon (or similar). maybe a standard elgg video tutorial for these processes could be made without seeming out of place.
• Giving up entirely -- they just can't figure it out: this is similar to the previous point.. possibly some dietary tips to improve memory/health and advice to go get some sunshine, stop smoking and brushing teeth with fluoride toothpaste would be of assistance to improve mental clarity here. ;) - not all technology problems are technology problems.
  
  
  

looking at the proposal points in the original post here - i agree with all of them, except the identity agent service option.. which, while it can work ok, also provides a level of complexity that is not strictly needed and could in some senses make the site semi-dependent on functionality that is not within the site admin's ability to effect. as was already said, the big websites do not accept each other as id agents... forcing elgg sites to do that is not great.

What are some alternative login flows you've tried to improve success rates? Which has been most successful?

i haven't deviated from the default elgg approach - except to use profile manager and to redesign the signup form and move the login box to a horizontal bar (visual changes only). i will refine this further, though have no plan to change functionality - only informational and visual changes.

Would anyone like to help build this?

there is a lot i would like to do with elgg, currently i do not have space-time available. i would help with this, yet am unable to currently.

@Evan

Since I starting using client side email validation more than a 1.500 users joined and I never had an email validation mail rejected since. Nor did I receive emails of users who were unable to register because the email validation check failed.

It is still possible that some email domains do not allow check existance of email accounts, but none of the larger public email domains have such a policy.

I also googled in false negatives combined with checkdnsrr and the only thing I found was somebody who was trying to check A records instead of MX.

So, in short it seems save

Do not forget there are 2 different flows, one for registration and one for login.

I am using this class now to check existance of email before validation in many forms. It does not only validate if the domain exists (like checkdnsrr), but the actual existance of the user account.

All major email providers support it, it's a bit of a trick where the function check_email($email) simulates sending an email, but actually doesn't after a "RCPT TO:" and positive acknowledgement of user existance abandon the session.

@Jeroen, I didn't get this working yet with your real time java validation check in profile manager registration extension. It always seems to fail there, but not really an issue since the validation is done after hitting submit. But still usefull if you take a look at it.

An easy mod I made that has had a huge effect on recovering lost passwords is to bold "Lost password" using translation editor: <strong>Lost password</strong>.

@Ed, can you be more specific about the "huge effect"?