>> 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 _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
