The Open ID spec requires that relying parties differentiate between HTTP and HTTPS URLs:
11.5.2. HTTP and HTTPS URL Identifiers
Relying Parties MUST differentiate between URL Identifiers that have different schemes.
But StackExchange (et al) strips the URL provided down to the base domain, dropping the scheme, thereby allowing either HTTP or HTTPS to be used. This leaves the user open to MITM attack, with no recourse, per Isn't OpenID over HTTP (not HTTPS) fatally flawed when delegates are used? as noted by this answer.
This is especially true for users using OpenID delegates.
When is StackExchange inc. planning to address this issue?
There's No Mitigation
Now, if it were merely a matter of me always using HTTPS I wouldn't care so much, but my doing so does not avoid the risk (as a matter of fact, my website only responds for the OpenID delegate over HTTPS).
Unfortunately, by their refusal to correct this security flaw, SE leaves me perpetually vulnerable to an MITM hijacking of my account at any time because they will make the request using HTTP if that's what the attacker types into the login field.
And contrary to claims that it's doesn't really matter, "it's only your SE account(s)", it does matter to me - someone could do a significant amount of damage to me in my professional community by taking over my SE account, some of which could never be reversed no matter what moderation capabilities there are (because the damage is done in the minds and perceptions that other people acquire of me as a result of the malicious activity).
www.and only when it's exactly a third level domain. If you have one instance where
domain.comare OpenID providers and go to separate locations I'm all ears - but we have yet to see this. If your argument is someone can steal the DNS, they've already done that with the domain itself.
httpon new accounts.