[Catalog-sig] OpenID login to PyPI

["Martin v. Löwis"]

>> 2. I also want the provider to provide me with a verified email
>> address,
> 
> You can get the user's chosen email address during registration, *after*
> authentication. The OpenID Simple Registration Extension (SReg)
> <URL:http://openid.net/specs/openid-simple-registration-extension-1_0.html>
> is designed for exactly that: getting details from the user at account
> registration time, after verifying that they own the OpenID they
> presented.

It's not really *after*, but simultaneously. I request the email
address when I direct the user the OP, and when she returns, I
get the email address.

>> But you *can* get the so that a) users can start using the account
>> right away, rather than having to perform an address verification
>> first
> 
> 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.
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.

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

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

>> and b) to simplify the control flow - it's called a "provider" because
>> it provides something to *me* also, as a relying party, something that
>> I want to rely on (rather than having to verify it myself).
> 
> What is provided to you is the process of verifying the user's ownership
> of their chosen identifier.

I think it's irresponsible that the SREG spec says "Security
considerations: None." when clearly there are many issues to consider
wrt. trustworthiness of the provided information.

> That's exactly the reason why you shouldn't *trust* the data, beyond
> “this is what the user wants me to know about them”. User-generated data
> is still only as trustworthy as it ever was; using OpenID doesn't change
> that, since all that data *about* the user from the OpenID provider is
> generated by the user at some previous time.

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

> You don't have to trust the provider to do anything but verify that
> identifier is controlled by the person presenting it.

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

> With OpenID, registration should happen *after* authentication: Since
> the user needs to submit their OpenID before you can check whether it
> corresponds to an existing account, you might as well authenticate them
> *before* bothering with checking if there's an existing account.

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

> 
> Here it is in detail:
> 
>   * Initiation: user is asked for their OpenID, Michael types in
>     ‘voidspace.org.uk’.
> 
>   * Normalisation, then Discovery: after which PyPI knows the Claimed
>     Identifier is ‘http://www.voidspace.org.uk/’ and where to go *this
>     time* to verify that claim.
> 
>   * Authentication: the provider verifies Michael's claim; it then sends
>     the result directly to PyPI.
> 
>   * Assuming Michael is authenticated, PyPI now knows Michael controls
>     that identifier, and will use it to find his account.
> 
> If there's no account associated with ‘http://www.voidspace.org.uk/’,
> *then* PyPI should begin Registration for a new account:
> 
>   * OpenID SReg is used to request the common parts (‘nickname’,
>     ‘fullname’, ‘email’, ‘language’, ‘timezone’, etc.). I don't believe
>     PyPI needs other information from the user than what is available
>     with SReg, but in case it's needed, OpenID Attribute Exchange
>     <URL:http://openid.net/specs/openid-attribute-exchange-1_0.html> can
>     be used to request other arbitrary information about the user.

You misunderstand. It happens during authentication. From the SREG
specification, section 3:

"The request parameters detailed here SHOULD be sent with OpenID
Authentication checkid_immediate or checkid_setup requests."

where the "SHOULD" refers to the fact that sending them is optional -
but if you don't send them, you won't get SREG information.

As for AX: PyPI currently requests both AX and SREG. Some providers
provide SREG, others AX - and not SREG (e.g. Google).

> 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. I
think you'll agree that the password setup and the "lost password"
procedures can be eliminated; 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.

Regards,
Martin