[Catalog-sig] OpenID login to PyPI

[Chris Withers]

Firstly, thanks to Ben for bringing these discussions to the correct 
list. I'd wondered why PyPI's OpenID support was so difficult to use, 
now I understand ;-)

Martin v. Löwis wrote:
>>> If I had to verify the user's real name afterwards anyway, and if I
>>> need a verified real name (for some reason), I have no way other than
>>> relying that the real name is really reliably provided.
>> Yes. Which is no worse than what you have in the absence of OpenID.
> 
> If I had a need for a verified legal name, I would need to require
> people to show some kind of legal ID. If I then find a provider to
> provide that to me instead, I could drop that verification.

How would you verify that the provider is doing its job properly?
What would you do for people who could not afford to use that provider 
or weren't allowed to because they lived in the wrong country?

> I'm also skeptical that OpenID users would accept such email
> verification, as presumably other sites using OpenID don't do that.
> Then I would have to bow to the pressure again "nobody else does
> it, so you have to change your procedure".

Every site I've ever used OpenID to log in to has verified my email 
address, just like they would if I typed it on a form.

>>> It may be that most providers don't verify this information, and let
>>> the user put in arbitrary junk. Such providers I will not trust.
>> How will you know?
> 
> By studying their documentation, exchanging email with them, etc.
> Initially by recommendation (that's how I got the current list).
> It's the standard way trust is established in our society.

But from what I've read in this thread, you could still have this 
trusted list *and* let people use provider-agnostic openids by 
supporting delegation. Does python-openid already support this?

>> My point is that you should treat such information as
>> though the user generated it at some arbitrary point in the near or
>> distant past, and don't expect that it has gone through any particular
>> verification.
> 
> If that was true, OpenID would be useless to a relying party.
> Fortunately, it's not true.

Then you are a lot more trusting than your responses suggest ;-)

> We are going in circles here. I don't *have* to treat the information
> as unreliable once I chose to trust a provider that it *is* reliable.

My gut feeling is that you'll be hard pressed to find any providers that 
meet these requirements. Even someone like Google, who can certainly 
promise to have a valid email account associated with their openids by 
tacking a gmail account onto each one, can't promise that a human has 
ever looked at that account. That's why you have an email verification 
process. If you're paranoid, you even go further than the "click this 
link" since that's easy enough to write a bot to do...

>>> I also *want* to eliminate the email verification at registration
>>> time. Ideally, I would also learn about changes to the email address
>>> from the provider.
>> You can't have that and allow users their choice of provider, since you
>> can't trust an arbitrary provider to verify email addresses to your own
>> standard.
> 
> Hence I cannot support arbitrary providers.

But, from what I understand from this thread, that doesn't imply you 
can't trust arbitrary openids...

cheers,

Chris