On Mon, Nov 16, 2009 at 12:45 AM, "Martin v. Löwis" <[email protected]> wrote: > No no no. It's called "provider" because it provides me with > authenticated information, and it's called "relying party" because > I rely on the provider to do so reliably. That's the whole point. > 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.
The problem here, I think, is that you're expecting more from OpenID than it really provides. OpenID lets me make an assertion about a URL (namely, that I "am" that URL) and lets you verify the truth (or falsity) of that assertion. It doesn't let me make assertions about my real name, email address or other information, and it doesn't let you verify the truth (or falsity) of such assertions. > As a relying party, I have to trust the provider. Some providers I > trust, others I don't (it seems that myOpendID.com is less trustworthy > than I was originally told, in that respect). Somewhat sad to note: I cannot use my OpenID with PyPI. I delegate to myopenid.com, but my OpenID is and always has been "http://www.b-list.org/";. If PyPI would let me use that and follow the delegation chain, it would be able to verify that I "am" that URL, and then could use, e.g., whois info or email to standard addresses on the domain to strongly verify further claims. But unless/until PyPI supports using my actual OpenID, and not just the transient provider I happen to be delegating to at the moment, the OpenID features on PyPI are basically useless to me. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
