Usernames and passwords are broken. Even with two-factor authentication, one still needs to remember their userid and password, and let's face it: password managers all suck.
Existing federated identity solutions such as OpenID require that the attesting entity own the namespace where the identity is attesting to lives. In order to use, say, your email address, your email provider would also need to support the federated identity solution. Even worse, with "solutions" like OpenID Connect, the relying entity needs to have an existing relationship with the attesting entity and thus your email provider.
It seems obvious why large providers like Google and Facebook prefer pseudo-federated-but-really-centralized solutions like OpenID Connect. But it doesn't seem likely that we'll wean consumers off their Gmail or Hotmail account. It seems like an uphill battle to get people to adopt yet another identifier, and public key hashes as identifiers are a nonstarter. So what are we to do?
Many sites are starting to use some form of passwordless authentication. While this class includes certificate authentication, user certificates are practically nonexistent on the open Internet because today's key management solutions are so crappy. So passwordless generally means email or SMS. There's even a decent [open source implementation for Node.js-based sites].
Passwordless authentication solves the username and password problem without precluding the use of 2-factor authentication, but it is actually harder than using a password manager that's well-integrated with your browser, which means its main benefit is that it makes initial sign-up transparent to the user and doesn't leave turds in their password manager, which is great for sites you only occasionally visit like comment pages on independent blogs.
But why couldn't federated identity providers attest to identities in namespaces they do not own but can verify? This is what PGP key-signing robots and Auth0 do, but PGP keys require key management and Auth0 is proprietary and centralized.
So why not combine the two ideas? You can trust any number of key-signing robots. There's no reason a site couldn't trust an arbitrary number of authentication providers. Just embed an iframe for each one and have the returned Javascript call window.postMessage to let the relying site know if the user already has a cookie. The site could then do a redirect or let the user choose which identity provider to use depending on which provider cookies they have, if any.
I'm probably going to need to mock this up or implement a prototype to demonstrate what I'm thinking, but if you get it and want to steal my idea, please go for it :)