[user5994461]

It's already available if you use any of the major email provider.

If you want to provide it from your own domain, it's perfectly doable, but it takes a lot of work to setup. This won't be usable from other sites though because they won't trust yoursite.com

Discovery is non existent because it makes zero sense in practice.

[detaro]

Ok, so you confirm that while the standards theoretically exist, OpenID Connect doesn't provide those features from OpenID in practice (where they did make sense for some reason?)

You don't need trust to the domain if you just want "an identity" to recognize a user, which is the use case for many services: basically as soon as you allow e-mail + password sign-up, that's the only thing you get. OpenID did the same.

Delegation is helpful exactly because it is somewhat difficult to implement OAuth nicely. OpenID did the same.

Which I guess answers the original question of "why not OpenID Connect" with "because nobody in that ecosystem cares about those features, even if someone at some point wrote down how they can work".

[user5994461]

I don't understand your complaint. I suspect you have a fundamental misunderstanding of identity management in practice, irrelevant of whether it's implemented with OpenID, OpenID Connect or SAML.

If you want people to register with anything, then just let them register with an arbitrary username and password. You don't even need an email or a domain.

[detaro]

I want what OpenID provided me: I give a site a URL to a page I control, and it goes there to figure out what service of my choosing to use to sign me in. I want this to be open, so I don't have to check with each site what whitelist of providers they accept.

I thus do not need to remember/manage a username/password pair per site, and am not tied to a specific service that might die, which was a big problem with the OpenID infrastructure dying bit by bit: those wo didn't use URLs they controlled to delegate lost their ability log in when the provider they used went away.

[dwaite]

But in practice, OpenID 1/2 were a nightmare.

Most of the implementations were incomplete/broken, everyone wanted to provide OpenID while nobody wanted to consume it, and the few parties that did consume it got left holding the bag when the OPs ripped out support and left users without a way to prove their identity to recover their accounts.

You want at least a weak unilateral arrangement, such as Google or Microsoft or Facebook saying they have no plans to rip the feature out from under you any time soon.

Also, OpenID adoption was never going to happen with users being identified by URLs. No party was going to step up and explain to users why they should go through the effort of learning all this tech to use it vs. using the passwords they were already familiar with.

[icebraining]

This won't be usable from other sites though because they won't trust yoursite.com

Why do they have to trust it at all?

[user5994461]

Because otherwise anyone could make an authentication provider that's authenticating as [e-mail] and assume your identity.

Remember that the goal is to delegate authentication, user profile and/or user creation. It's implicitly trusting everything coming from the third party. For instance when supporting google login, it's expected that google only validate user accounts that really exist and are hosted by google.

[icebraining]

Well, no, it would only accept IDs of the format *@yoursite.com for the provider yoursite.com (or the provider yoursite.com has delegated to).

[user5994461]

Authentication cannot be bound to any email or format.

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

If you want to rely on emails, just use emails.

[icebraining]

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

That's what delegation is for.