On Mon, Nov 16, 2009 at 12:45 AM, "Martin v. Löwis" <martin at v.loewis.de> 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."