"Martin v. Löwis" <[email protected]> writes: > > [authenticating user-provided attributes is] 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
Exactly. If you find that the provider is giving extra features orthogonal to OpenID, please feel free to use them; but refusing providers that don't provide those extras is crippling the OpenID authentication service for others. > not even that the OpenID of the user is validated in form. Since authenticating the user's OpenID (validating their Claimed Identity) is central to OpenID, it would be quite reasonable to black-list providers that don't perform authentication sufficiently well. > > 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. I can confirm that's not the case: using Verisign's provider, I can specify any email address I like in response to registration requests, and I make frequent use of this to distinguish email addresses on a per-site basis. This is a good thing. > > 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. You already have PyPI doing validation of email addresses provided by the user. I'm advocating that you keep that in place, since that's the only way you can trust an arbitrary user-specified email address. > 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". Every service I've used OpenID with that wants a verified email address for good reasons (and yes, I think PyPI's reasons are good in this case), verifies the email address themselves. I have no problem with that; it's the status quo before OpenID came along, and it doesn't seem onerous. > 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. I have no complaint against setting up an account. What is too much of a burden in just about every case is to manage a site-specific set of authentication credentials for every new site. I hit my limit long ago, and OpenID offers a way forward. If I was to come across PyPI today, it would likely not pass the bar of “worth the effort to manage yet another site-specific authentication set”. This is one main reason why I'm so intrested in having OpenID work properly at PyPI. > > The user generated all those [attributes] 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. You are probably fully aware that I mean the *data* is generated in the computer by the user, and is only as trustworthy as any other user-supplied data. > > You can't have [provider-verified email address] 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. Until you do, you'll be stuck with supporting a limited subset of big-name providers, and anyone who deliberately controls their own OpenID in order to be *independent* of such providers will be rejected for that action. That doesn't seem likely to make the situation better. I really hope you will consider your users needs and rethink this position. -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
