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
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
