I was pointed to this thread by some people on our local user group,
and since I've done some OpenID implementation work in the past (on
the RP and OP side), they asked me to chime in.
The criteria for inclusion into the whitelist posted is:
must be in wide use, using procedures that the community trusts
must support OpenID 2.0
must support provider-driven identifier selection
must provide a validated email address, either through AX or SREG
must support direct communication over https
I wanted to note in particular that
must provide a validated email address, either through AX or SREG
is not very useful for this sort of system. Keep in mind that Google
and MyOpenID, two of the providers on the whitelist, can return email
addresses, they are optional. It's just as likely that a Google user
will opt not to return an email address. And I believe (although I'm
not sure right now) that with MyOpenID you can return any email
address you want.
In short, you still have to verify the email address through
traditional means.
As another point, I do use MyOpenID as my provider, but I do so
through delegation from my personal site; that way I don't have to do
the work of maintaining a provider but I can use one that I trust.
With this whitelist I cannot use my chosen identifier.
Finally, the other respondents are correct in that trusting an OpenID
provider (as an RP) is the same as trusting an email address provider
if you have a reset password link (as PyPI does).
Please reconsider allowing a user-chosen identifier, even if you do
keep the identifier-select buttons.
Adam
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
