[Catalog-sig] OpenID login to PyPI

Paul Boddie paul at boddie.org.uk
Wed Nov 18 20:10:15 CET 2009

On Wednesday 18 November 2009 06:46:43 Martin v. Löwis wrote:
> > Since OpenID is an authentication solution, you should probably just
> > accept the claimed identity as the username.
> It can't work that way, and shouldn't. First, OpenID defines the Simple
> Registration extensions (SREG) to explicitly cover a nickname, and also
> provide an email address. Whether or not I trust these data - at a
> minimum, I should use them - that's what OpenID users expect to happen.

I misinterpreted what you wrote, there. Yes, there's probably a difficulty in 
presenting a single page to all users and letting them type in a username (or 
identifier) and having a single piece of software work out whether they can 
authenticate that person or not. Some kind of pass-through from 
mod_auth_openid to the existing solution would be necessary, aside from 
having separate entry points to the application.

I was actually just saying that the claimed identity is the thing that you'd 
probably end up with as the "username" from mod_auth_openid, and that's the 
only thing you'd ever need to actually tell users apart. Certainly, I 
wouldn't want to put anything else in my users table.

Ben Finney wrote: "Martin is correct here. The ‘nickname’ field is expected to 
become the username for the newly-registered site-local account."

SREG doesn't guarantee that a nickname exists for an identity, and whether the 
user wants their identity to be displayed using a particular nickname is 
separate from the nature of their identity itself. Sure, you could let people 
use nicknames to log in (having associated a specific identity with a 
nickname) on a first-come first-served basis, but the claimed identity would 
still have to float around in the application somewhere.

> I see that mod_auth_openid has some support for AX (a similar protocol)
> since 0.3, and that may also support SREG, but again, I'm unsure how to
> use it.

I guess it could be used (presumably via various environment variables, but I 
don't know) to pre-fill any registration or preference details.

> In addition, existing users will expect to be able to use OpenID, and
> will expect to be able to map OpenIDs to existing accounts.

This is where you'd probably have to do some work, yes.

> > In fact, mod_auth_openid provides this  as the REMOTE_USER CGI
> > environment variable.
> That can work for logins, but not for registrations.

Well, upon authenticating themselves - providing their OpenID identity - you'd 
be able to tell whether the application knows them from before by seeing if 
that identity is recorded anywhere. If it isn't, you could send the user to a 
registration page where they get to fill out their e-mail address and other 

OpenID is, after all, only an authentication technology. What you do with the 
user identity and whether you let the user in or trust them in any way is an 
authorisation problem.

I'm not saying that mod_auth_openid will solve all problems instantly, but I 
just thought that it could do a lot of the work and minimise changes to the 
applications, and that's presumably what its developers intended.


More information about the Catalog-SIG mailing list