[Catalog-sig] OpenID login to PyPI

[Ben Finney]

"Martin v. Löwis" <martin at v.loewis.de> writes:

> > The verification, though, should be done by PyPI. You shouldn't be
> > trusting the OpenID provider to verify an email address, that's not
> > its job (and, as you rightly point out, you can't trust an arbitrary
> > OpenID provider to do so).
>
> 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.

That's not a promise ever made by the protocol, so I don't know why
you're expecting that. The relying party gets information from the
provider, but there is no guarantee that the email address is verified
to anything but the *user's own* standards.

If you (the relying party) trust the user (via their provider) to
provide you an email address that you then trust, that's great. But
nothing about OpenID makes any such promise. If you have a particular
standard of verification for an email address, it's *not* the job of the
OpenID provider to do that for you.

> 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.

> 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).

Right. So continue vetting the user-supplied data as you would normally,
whether that user-supplied data comes from an OpenID provider or from
the user putting data into a form on your web site.

> > Of course, if during registration it happens that you *do* trust the
> > provider to verify the user's email address, then that's up to you.
> > But this should not limit the providers from which you accept
> > *authentication* of an OpenID.
>
> Hmm. Then integrating OpenID only complicates matters. I don't gain
> anything.

What you gain is more users: the barrier to their entry is lowered.
That's the primary gain. I know that there are countless *thousands* of
sites that I don't bother creating an account with, because they don't
support OpenID.

You also get to offload the task of authentication of *identity* to
another party, chosen by the user. That is, you don't need to manage
their password; someone else is responsible for that.

> But not all of the information in SREG is user-generated. Thinks like
> full name, email address, date of birth, gender, postcode, country of
> residence are administratively not user-*generated*.

The user generated all those at some point.

> 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? 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.

> Of course, I don't much of this information, so I don't care whether
> the user lies about the gender; I can accept that the user lies about
> the full name. For the email address, I really need to rely on it
> being valid.

Right. So you do what just about every site I've been to that needs to
use this information (including PyPI) does: verify it to your own
standard before using it.

This, again, is no worse than what you already have to do in the absence
of OpenID. So while OpenID doesn't make this go away (nor could it), it
also doesn't change it.

> But I *want* to trust the provider. I hope this message makes that
> clear.

Yes, thank you. That's not its job though. By nature of being a
*distributed* identity protocol, where the user is in control of their
own identity information, you must therefore treat the information
provided as you would treat any user-provided information.

> > With OpenID, registration should happen *after* authentication […]

> No, it happens simultaneously. That's how the protocol is defined.

I stand corrected; so much the better, then.

> > So, none of this replaces the need to gather and keep information
> > about the user's account on PyPI, nor to do verification of any
> > user-provided information that PyPI needs to use in a trusted
> > manner.
>
> OpenID is certainly designed to replace traditional registration.

Only in the sense of the web form, not the data validation or
verification.

> I think you'll agree that the password setup and the "lost password"
> procedures can be eliminated;

Yes, but that's not by dint of the registration process; only the
authentication process (which is the primary benefit to most OpenID
users).

> 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.

Since PyPI already knows how to verify email addresses, I hope you can
arrange that it continue doing that while supporting OpenID fully.

-- 
 \       “Facts are meaningless. You could use facts to prove anything |
  `\                that's even remotely true!” —Homer, _The Simpsons_ |
_o__)                                                                  |
Ben Finney