[Catalog-sig] OpenID login to PyPI

["Martin v. Löwis"]

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

That depends on the provider. Some providers (e.g. Google and Launchpad)
do provide additional guarantees. Clearly, the protocol cannot make
any guarantees - not even that the OpenID of the user is validated
in form.

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

Some providers (e.g. Verisign) have *exactly* that job.

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

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

Hmm. That makes the data flow even more complicated.

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

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

That sounds fairly fanatic. If I want to use some service, and I have
to setup an account for that, I just go ahead and do it.

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

That would only work if there was a chance that I could ever drop
username/password authentication. Unfortunately, that is fairly
unrealistic. So I don't gain that particular advantage.

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

Not really. At least the gender was generated by the parents, at least
for most of us (and parents likely didn't control the gender, either).
Likewise for day-of-birth.

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

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

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

It could, and in my current installation, it actually does.

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

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.

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

Well, the AX protocol is, in principle, able to completely replace
the registration process.

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

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

That's fairly difficult because I have to park so many data "in the
middle". It was easy (or, rather, already done) with username/password
pairs; with OpenID, it now gets more complicated.

Regards,
Martin