[Catalog-sig] OpenID login to PyPI

Ben Finney ben+python at benfinney.id.au
Tue Nov 17 03:17:10 CET 2009


"Martin v. Löwis" <martin at v.loewis.de> 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



More information about the Catalog-SIG mailing list