[hypeatei]

The ideas proposed in here aren't bad, but it does seem like you'll need to maintain two user flows as a site owner because:

1) Not all email providers will implement this, and

2) Users may not be signed into their email at the moment they signup

As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support staff. Again, not a bad proposal but perhaps not very useful in practice.

[WorldMaker]

I thought Mozilla Persona aka BrowserID handled this email validation well with a fallback provider that used the same flow (and also implemented the OIDC work for obvious existing social providers like Gmail/Google Accounts). Though obviously not well enough because that fallback provider was seen as a large expense and shutdown without a replacement killing the Mozilla Persona effort.

But that does relate to I keep wanting an email claim for Passkeys. A user's browser/OS could verify an email address once and then associate it with a Passkey. Passkeys might be a good place for that (as Persona/BrowserID suggested). Obviously some browsers could lie about verifying the email address in the claim and there might still need to be more steps to it, but if you are already taking Passkeys it doesn't necessarily add an entirely different flow to accept a verified email claim from a Passkey (and/or decide you don't trust that Passkey's claim and trigger your regular verification code flow).

[TZubiri]

Of course, if the new standard which no one supports doesn't work, the incumbent standard would be used.

[cartofupai]

Just like login federated or with email/pwd.