[Catalog-sig] OpenID login to PyPI
"Martin v. Löwis"
martin at v.loewis.de
Mon Nov 16 07:45:17 CET 2009
>> 2. I also want the provider to provide me with a verified email
> You can get the user's chosen email address during registration, *after*
> authentication. The OpenID Simple Registration Extension (SReg)
> is designed for exactly that: getting details from the user at account
> registration time, after verifying that they own the OpenID they
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
> 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
>> 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
> 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
> * 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.
More information about the Catalog-SIG