What if we just remove that as an option?

*Important:* Google has deprecated OpenID 2.0 and will shut it down after a migration period. If your app uses OpenID 2.0, you must migrate your app by the shutdown date April 20, 2015

But what happen to existing users who registered with OpenID? Is PyPI planning to migrate to OAuth 2.0 https://developers.google.com/accounts/docs/OAuth_ref#migration (and what about warehouse?) Thanks. John On Sun, Feb 8, 2015 at 6:37 PM, Richard Jones wrote:

Google has discontinued support for OpenID, so we're not going to be putting any effort into debugging this issue.

Richard

On Sun Feb 08 2015 at 6:09:22 AM anatoly techtonik wrote:

...

Hi,

Attempt to authorize with Google gives "Something wen wrong" page shown at https://pypi.python.org/pypi?:action=login&provider=Google

Please, CC. -- anatoly t. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:

Google has discontinued support for OpenID, so we're not going to be putting any effort into debugging this issue.

I hope you'll continue to support other OpenID providers, e.g. Launchpad. Cheers, -Barry

On Feb 10, 2015, at 9:27 AM, Brett Cannon wrote:

On Mon Feb 09 2015 at 2:42:46 PM Barry Warsaw mailto:barry@python.org> wrote: On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:

...

Google has discontinued support for OpenID, so we're not going to be putting any effort into debugging this issue.

I hope you'll continue to support other OpenID providers, e.g. Launchpad.

Does Launchpad support OpenID Connect? If so then migrating to that would solve this.

Otherwise it may be time to have a serious look at our federated login support and consider adding GitHub and Bitbucket for wider reach as OpenID 1.0/2.0 is extremely niche at this point.

Honestly, I’d rather have less federated login not more. I wish the current OpenID support had never been added. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Feb 10, 2015, at 11:23 AM, Martin v. Löwis wrote:

Am 10.02.15 um 15:36 schrieb Donald Stufft:

...

Honestly, I’d rather have less federated login not more. I wish the current OpenID support had never been added.

Can you please elaborate on that position? Why is it useful to have separate accounts on separate systems?

Sure. So the basic premise behind federated auth is that you can get a single set of credentials on all (or most) of your sites and eliminate the need to have a password for each site you visit. My opinion is basically influenced by a number of factors: 1. I feel like the goal of federated auth has failed in general and is unlikely to ever succeed. As a user of websites I have over 400 different entries in my password manager, even if 50% of them implement federated auth (which I feel like is a high number but that's not backed by math, just gut feeling) that's still over 200 entries I need to maintain in my password manager. In this case federated auth has not meaningfully reduced the burden of maintaining password for me since maintaining 200 isn't any easier than 400 and instead it just complicates my login flow 2. As a site operator I feel like authentication is a core part of the experience of using my site and by allowing federated auth on my site I'm giving up control over that user flow. A relevant example from PyPI is that a number of users signed up using MyOpenID which is no longer being maintained. This means that either PyPI has to tell those people "tough shit" or PyPI needs to figure out a mitigation tactic against that. Another example is that launchpad randomly starts failing for people, and it'll fail consistently for the same person until it just stops failing for them. I'm unable to actually reproduce this error so it's extremely hard for me to do anything else but shrug and tell them not to use it. 3. I feel like unless you solely rely on federated auth, then federated auth is always going to be a second class citizen for any particular website. For instance Travis CI uses federated auth via Github only, but that's the only thing they support for authentication so everything works well with that. On the other hand a number of sites support federated auth ontop of local accounts and federated auth is almost always worse in some ways, sometimes as simple as the username you get is kinda crappy (dstufft_<somehash>) sometimes some features don't work (or don't work very well) at all like on PyPI where we need to authenticate people outside of a web context so if we don't have usernames/passwords then we end up needing to require the user to register a secondary "api password" or API key. 4. I feel like none of the current solutions to federated auth are very good. OpenID relies on using an URL as your "personal identifier" which I feel like is a strange and foreign concept to most users. The way around this is often to just hardcode a list of sites, but then as a site operator you're implicitly recommending that users go sign up for one of those sites and use them on your site to login. This is creating an explicit relationship between your site and the other site, a relationship in which you often have no power (for instance, Google <-> PyPI, we're powerless to do anything about them deprecating OpenID other than just sucking it up and dealing with it). Persona did offer a way around this, but persona had other failings like relying on the domain that you happened to be using for your email to implement a persona IdP or otherwise falling back to an implicit relationship with the fallback provider, again one where you're more or less powerless to the operators of that service. Overall I think that the use of federated auth, as a site operator, is really only worth it over the loss of control in two scenarios: A. When your site is already entwined with another site and relying on them for authentication is simply increasing that. An example of this from above is Travis CI where they only work with things hosted on GitHub so also relying on GitHub for authentication isn't that big of a deal and actually makes things better since they can then integrate with GitHub's permissions to check if you have commit on a particular repository. B. When creating an account is likely to be enough of a burden to make people decide not to interact with your site. This category is basically completely comprised of sites that do not have long standing relationships with their users. The only real example I can think of this of the top of my head is sites with comments enabled like blogs, news sites, etc. The commentors are unlikely to have or want a long standing relationship with your site, they just want to make a quick one off comment and then possibly never come back. Sites like PyPI otherhand the cost of creating an account is small compared to the life time of majority of our user base's interaction with us. A key thing to me, as a site operator, is keeping as much control over the experience of my users as I can. Obviously I have to outsource some things because It's not reasonable for me to make my own hardware, write my own drivers, my own kernel, my own OS, my own webserver etc. A good example of a major outsourcing that I was involved in was moving things behind Fastly. However a key difference between that outsourcing and this outsourcing is that if things go sour with Fastly or we need to migrate away from them for one reason or another we can do that without end users needing to change much or anything. However if something like Google dropping OpenID supports happens then the users who relied on that are out of luck and our ability to shield them from the fallout of that is limited. At this point we already have it enabled, so unless someone comes up with a really good migration strategy I doubt we'll be able to get rid of it. However for the reasons above I'm pretty much against adding *additional* federated auth things and I think that we should treat it more of a legacy thing and downplay the fact we have support for it. Bitbucket has downplayed support for random OpenID as well, when you go to their login pages it shows a login form that looks like http://d.stufft.io/image/1O2l2g073h0h, which still lets you login with OpenID but it's muted and downplayed. In a slightly hypocritical view point, I actually think that at some point we should get something like id.python.org which is an IdP and switch all of the *.python.org sites to authenticate against that instead of keeping local user accounts. This would reduce the number of passwords that Python inflicts on people but it still keeps authentication within our (PSF/Python/whatever)'s control. This is more along the lines of implementing SSO using a federated auth technology than actual federated auth though. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Am 10.02.15 um 18:33 schrieb Donald Stufft:

...

Can you please elaborate on that position? Why is it useful to have separate accounts on separate systems?

Sure.

Thanks! Just one comment - without the desire to get into a long-winded discussion.

1. I feel like the goal of federated auth has failed in general and is unlikely to ever succeed. As a user of websites I have over 400 different entries in my password manager, even if 50% of them implement federated auth (which I feel like is a high number but that's not backed by math, just gut feeling) that's still over 200 entries I need to maintain in my password manager. In this case federated auth has not meaningfully reduced the burden of maintaining password for me since maintaining 200 isn't any easier than 400 and instead it just complicates my login flow

I think this is your personal usage primarily. A lot of user just avoid having to use a password manager, and use the same password on many systems. (Of course, many people also *do* use different passwords, and some also use passwords managers) Regards, Martin

On Feb 10, 2015, at 07:06 PM, Martin v. Löwis wrote:

I think this is your personal usage primarily. A lot of user just avoid having to use a password manager, and use the same password on many systems. (Of course, many people also *do* use different passwords, and some also use passwords managers)

Actually, I wouldn't be surprised if most users just use the password manager built into their browser. Cheers, -Barry

On 2015-02-10 12:33:29 -0500 (-0500), Donald Stufft wrote: [...]

In a slightly hypocritical view point, I actually think that at some point we should get something like id.python.org which is an IdP and switch all of the *.python.org sites to authenticate against that instead of keeping local user accounts. This would reduce the number of passwords that Python inflicts on people but it still keeps authentication within our (PSF/Python/whatever)'s control. This is more along the lines of implementing SSO using a federated auth technology than actual federated auth though.

The OpenStack community is in the process of doing this already (for exactly all of the same reasons you stated), so I'm happy to discuss details or point you to relevant ML/IRC conversations and software if it helps in any way. -- Jeremy Stanley

On 11 February 2015 at 03:33, Donald Stufft wrote:

In a slightly hypocritical view point, I actually think that at some point we should get something like id.python.org which is an IdP and switch all of the *.python.org sites to authenticate against that instead of keeping local user accounts. This would reduce the number of passwords that Python inflicts on people but it still keeps authentication within our (PSF/Python/whatever)'s control. This is more along the lines of implementing SSO using a federated auth technology than actual federated auth though.

This is the approach that Fedora uses [1], and it offers a lot of benefits in making it possible to implement infrastructure services as independently updated components, while using role-based access control for authorisation management. One of the key practical benefits is providing a single place for people to register their public SSH keys, while one of the key community building benefits is that reliably federating identity across the various Fedora infrastructure services enables the badge system that allows people to more easily be appropriately credited for their contributions to the project. If you start doing 2FA, then the identity management server becomes the place where you do your token management. If we keep the focus specifically on PyPI, then the benefits of breaking out a separate identity service mostly amount to making it a bit easier to introduce a build service in the future (since PyPI and the build service would be peers using a common identity provider, making it easier to accommodate things like alternate experimental PyPI front ends or separating the upload service from the publishing service). Things start to get a bit more interesting once we consider a world where mail.python.org has been upgraded to Mailman 3, and we actually have the concept of a "user profile" for the mailing list infrastructure (as part of the HyperKitty archiver/web gateway). In that case, then having HyperKitty/Mailman 3/PyPI sharing an identity provider would make it feasible to let user's opt in to listing their PyPI packages on their mail.python.org profile, which may provide useful context in some discussions. And then once we expand our sphere of consideration even further into CPython core development, then I think core developers would gain the most in the near term, as we touch almost all the major identity silos (hg.python.org, pypi.python.org, buildbot.python.org, bugs.python.org, wiki.python.org) regularly, with the release managers also needing to deal with www.python.org. It's also worth noting that both of the current workflow improvement proposals suggest adding yet another identity silo in the form of a forge.python.org service. Longer term, the shared identity model does offer a benefit in terms of reducing barriers to entry: it means that anyone that has created an account on PyPI to distribute software, or on Mailman 3 to subscribe to a mailing list, will already have an account that lets them file bugs on bugs.python.org or submit pull requests on the future forge.python.org. Another aspect to consider is that once you decide to have a single authoritative identity provider *within* the ecosystem, it's also possible to adopt models like the one Stack Overflow uses, where you can *link* other profiles to your account and use them to login once you do, but you're still required to be able to authenticate directly with a password (If I recall correctly, DISQUS uses a similar setup, although I think the "native" password controlled account is optional there). So this approach isn't necessarily about "no social auth allowed" - it's about managing the risk of what happens if an external identity provider goes away at some point in the future. Cheers, Nick. [1] https://admin.fedoraproject.org/accounts/ -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Feb 15, 2015, at 5:25 PM, Robert Collins wrote:

I probably shouldn't, but I feel compelled to reply :).

On 11 February 2015 at 06:33, Donald Stufft wrote:

...

...

On Feb 10, 2015, at 11:23 AM, Martin v. Löwis wrote:

Am 10.02.15 um 15:36 schrieb Donald Stufft:

...

Honestly, I’d rather have less federated login not more. I wish the current OpenID support had never been added.

Can you please elaborate on that position? Why is it useful to have separate accounts on separate systems?

Sure.

So the basic premise behind federated auth is that you can get a single set of credentials on all (or most) of your sites and eliminate the need to have a password for each site you visit.

My opinion is basically influenced by a number of factors:

1. I feel like the goal of federated auth has failed in general and is unlikely to ever succeed. As a user of websites I have over 400 different entries in my password manager, even if 50% of them implement federated auth (which I feel like is a high number but that's not backed by math, just gut feeling) that's still over 200 entries I need to maintain in my password manager. In this case federated auth has not meaningfully reduced the burden of maintaining password for me since maintaining 200 isn't any easier than 400 and instead it just complicates my login flow

So, what is success here? I'd call 200 less passwords to maintain and rotate on a regular basis a GOOD THING. I very much doubt that you would have 2FA set up on the other 200 things, so that would mean a change from 400 sites w only a couple having 2FA to 200 with regular rotations and 2FA, and 200 liabilities.

Success (for me) is when federated auth enables me to no longer need to worry about passwords in my day to day use of the web. Currently it's not even close and it doesn't appear to be getting any closer. The places where it is even possible it's generally only possible to sign in with Github/Twitter/Facebook and I'm unwilling to place the ability to authenticate as me to a wide number of services with them. The only time I'm willing to do so is "throw away" sites where my account on those sites don't really matter to me.

...

2. As a site operator I feel like authentication is a core part of the experience of using my site and by allowing federated auth on my site I'm giving up control over that user flow. A relevant example from PyPI is that a number of users signed up using MyOpenID which is no longer being maintained. This means that either PyPI has to tell those people "tough shit" or PyPI needs to figure out a mitigation tactic against that. Another example is that launchpad randomly starts failing for people, and it'll fail consistently for the same person until it just stops failing for them. I'm unable to actually reproduce this error so it's extremely hard for me to do anything else but shrug and tell them not to use it.

I'm genuinely curious here. Why do you feel that authentication is a core part of the experience? Its a necessary part, sure. But I find it hard to imagine that many people say 'that bug tracking site, its got *awesome authentication*'! I see authentication as something that is very very hard to get right, and incredibly easy to get wrong. I don't trust folk that are experts in e.g. bugtracking. Or code hosting. Or todo list management to necessarily understand all the intricacies of password handling (e.g. *how many sites don't use PBKDF2*!) Or worse truncate the input password you give to 8 characters (yes, seriously). Its not that the site operators aren't trustworthy in general, its that password handling is nasty: - its hard to get right - you won't know if you got it wrong until you or your users are compromised - even sites with dedicated teams doing just the IdP aspect get it wrong

I consider it irresponsible for less well resources sites to get into credentials management unless they truely have no choice: they're tackling something they're almost certain to get wrong.

Authentication is like a lot of pieces of maintaining a service, where if you get it done *really well* people won’t notice it exists and if you do it wrong people will notice it’s bad immediately. Sites go out of their way to take control of the authentication flow to ensure that it gives the best possible experience for their users. Delegating that out to someone else is giving up control of it, which means that if the place it's been delegated to isn't able to keep up then you're SOL because you've exposed what should be implementation details of a particular app to the end user. You say that you don't trust them to get authentication correct, which seems silly to me given that you apparently trust them to handle ACLs or any number of other parts of a secure web app correctly. However even if a particular app doesn't want to handle their own authentication, there are better ways to handle delegation, such as something like https://stormpath.com/ which allows you to delegate the actual storage and handling of passwords and properly handling authentication to a third party that specializes in that, but without exposing the details of that to your end users, so that if you need to migrate at some point you can.

...

3. I feel like unless you solely rely on federated auth, then federated auth is always going to be a second class citizen for any particular website. For instance Travis CI uses federated auth via Github only, but that's the only thing they support for authentication so everything works well with that. On the other hand a number of sites support federated auth ontop of local accounts and federated auth is almost always worse in some ways, sometimes as simple as the username you get is kinda crappy (dstufft_<somehash>) sometimes some features don't work (or don't work very well) at all like on PyPI where we need to authenticate people outside of a web context so if we don't have usernames/passwords then we end up needing to require the user to register a secondary "api password" or API key.

Relying solely on federated auth is fine by me :). You don't need to tie yourself to one provider. Yes, most users will use just one of fb/github/google/lp/twitter in our community, but you can (and should) do unification on email address's to allow dealing with failed providers [but only for trustworthy providers or by doing an email verification step before unifying] and manage ACLs and privileged operations locally.

The fact that some sites doit crappily is in no way an inditement of the basic tech - in fact some sites do it really well. Its gotten so good that these days the only time I will sign into a site that *doesn't* use federated auth is if there is something I really really really want from it. E.g. I made an account with Elite:Dangerous.

Relying only on federated auth is an fairly poor user experience. You have to essentially tell someone that before they can use your site, they have to go pick one of these other sites to become a user of. Since I know it's relevant to you as well as me, I hate having to log into any Openstack service via Launchpad because it's an extra step that I don't have to do on any service that doesn't delegate auth, since I have to first login to launchpad and then I have to tell it to allow the login to an openstack service. Nevermind the fact that there is huge phishing potentional and that the more central auth gets the more likely you're going to see people who want to attempt to phish your login information. I do think that in some cases federated auth can make sense, especially for small sites where even a slight inconvience or delay in going from an unregistered user to a logged in user can cause you to lose traffic all together. These sites also tend to have a very low amount of inertia tied to a specific user account, if you lose access to your account spinning up a new one is low impact. Compared to PyPI where the security of an account is of paramount importance and that a lost account is incredibly disruptive.

...

4. I feel like none of the current solutions to federated auth are very good. OpenID relies on using an URL as your "personal identifier" which I feel like is a strange and foreign concept to most users. The way around this is often to just hardcode a list of sites, but then as a site operator you're implicitly recommending that users go sign up for one of those sites and use them on your site to login. This is creating an explicit relationship between your site and the other site, a relationship in which you often have no power (for instance, Google <-> PyPI, we're powerless to do anything about them deprecating OpenID other than just sucking it up and dealing with it). Persona did offer a way around this, but persona had other failings like relying on the domain that you happened to be using for your email to implement a persona IdP or otherwise falling back to an implicit relationship with the fallback provider, again one where you're more or less powerless to the operators of that service.

I agree that they're not brilliant. OpenID is basically dead, long live OpenID Connect :/. So the thing there AIUI is that OAuth worked out a lot better (more flexible, consistent with both CLI / app workflows and server side web interactions). And as such everyone is just consolidating on the one toolchain to avoid lots of needless redundancy. But as user, its fine. I don't judge a site as subordinate to Google if they allow Google logins, for instance.

Yes, if you use federated auth you need to keep up. But hell, we need to keep up if we do our own auth management. When was the last time the hash count on PyPI's password database was increased to account for hash rate growths? Managing credentials is an ongoing effort - at Canonical we split that out into its own team, and they were busy just keeping on top of it and changes in the fundamentals for years. See above about hard to get right.

PyPI uses bcrypt with a work factor of 12, we're using the excellent passlib library which means we can easily set things up to automatically migrate between different algorithms and different work factors/rounds within the same algorithm. The current settings on PyPI is roughly 0.3 (on my iMac in a completely unscientific benchmark with an iteration of 1 since any large number of iterations takes forever) seconds per password hash and bumping bcrypt to 13 makes it take roughly 0.6. I do check periodically that our work factor is appropiate and at some point I plan on migrating the algorithm to scrypt once a reasonable implementation of it is available for Python. Honestly speaking as someone who has implemented both authentication libraries, OpenID servers, and OpenID clients I feel a lot more like storing a password safely isn't really that hard, especially with good libraries like passlib to help with it, and in the grand scheme of things it's only a tiny part of what makes a secure application. Even within authentication itself there are a number of things that federated auth simply won't help with. Things like ensuring that you rotate your session identifiers when you cross authentication boundaries are things that even federated authentication doesn't handle for you and are far more likely to get forgotten when creating a site than what password storage and algorithms someone uses. PyPI in particular is a web service that needs to be designed to last decades. It's not the kind of site web service where you can just tell people that hey guess what, tomorrow we all need to switch away to some other authentication service because MyOpenID (or whatever) decided to shut down. It's less about needing to "keep up" and more about who has to do the keeping up, for ensuring we're still safely storing passwords it's simple enough for the PyPI admins to ensure that we're still "safe enough", however when using authentication where the fact it's being delegated has been "leaked" to the end user, it's up to each and every individual user on PyPI to ensure that they are using an auth provider that is keeping up, and the end users are the ones least likely to do that on any kind of meaningful scale.

...

Overall I think that the use of federated auth, as a site operator, is really only worth it over the loss of control in two scenarios:

A. When your site is already entwined with another site and relying on them for authentication is simply increasing that. An example of this from above is Travis CI where they only work with things hosted on GitHub so also relying on GitHub for authentication isn't that big of a deal and actually makes things better since they can then integrate with GitHub's permissions to check if you have commit on a particular repository.

B. When creating an account is likely to be enough of a burden to make people decide not to interact with your site. This category is basically completely comprised of sites that do not have long standing relationships with their users. The only real example I can think of this of the top of my head is sites with comments enabled like blogs, news sites, etc. The commentors are unlikely to have or want a long standing relationship with your site, they just want to make a quick one off comment and then possibly never come back. Sites like PyPI otherhand the cost of creating an account is small compared to the life time of majority of our user base's interaction with us.

I think you're underestimating the impact this has on users. It definitely creates a high barrier to entry for me, and I don't think I'm alone. For bugs.python.org I leapt on Federated auth, but for PyPI I can't use it because it doesn't allow consolidating the accounts (AFAICT). Is it a matter of toits? E.g. do you need someone to provide patches to both permit the new OpenID Connect, OAuth for console use, and connecting OpenID Connect identities to local usercodes?

Honestly, I feel like 90% of the problem people have with authentication on the python.org web properties can be solved by implementing SSO. The problem here is that you have one logical collection of sites that all have different authentication silos. I don't think that allowing someone to log in with Github, or Google, or whatever the flavor of the week is will make a much higher impact over SSO.

...

A key thing to me, as a site operator, is keeping as much control over the experience of my users as I can. Obviously I have to outsource some things because It's not reasonable for me to make my own hardware, write my own drivers, my own kernel, my own OS, my own webserver etc. A good example of a major outsourcing that I was involved in was moving things behind Fastly. However a key difference between that outsourcing and this outsourcing is that if things go sour with Fastly or we need to migrate away from them for one reason or another we can do that without end users needing to change much or anything. However if something like Google dropping OpenID supports happens then the users who relied on that are out of luck and our ability to shield them from the fallout of that is limited.

Thats true, OTOH I think I've made a reasonable case above that our ability to shield users from our own mistakes is limited, and dealing with passwords really isn't as simple as all that... and updating to OpenID Connect should be pretty straight forward, there are good libraries for it all around.

We'll likely update the Google authentication to use OpenID Connect because simply we already made the mistake of implementing and enough people are relying on it that we can't just simply drop it if there's a reasonable way for us to continue support it. If you want to submit a pull request to do that, it would be most appreciated. Going forward however I'm likely going to be -1 on adding any additional forms of federated/delegated authentication, except possibly to a global Python Auth service. That includes adding generic support for OpenID Connect or Persona or whatever other protocol is the flavor of the month. I'm also likely going to end up trying to de-emphasize the ability to use anything but a local account and try to guide users towards using local accounts where possible. Finally if I ever do come up with a reasonable way to migrate away from what federated authentication support we have today in a low impact way you'll likely see a proposal on distutils-sig for that, however I'm not very hopeful except to just wait it out for the services to die out and remove support for them.

...

At this point we already have it enabled, so unless someone comes up with a really good migration strategy I doubt we'll be able to get rid of it. However for the reasons above I'm pretty much against adding *additional* federated auth things and I think that we should treat it more of a legacy thing and downplay the fact we have support for it. Bitbucket has downplayed support for random OpenID as well, when you go to their login pages it shows a login form that looks like http://d.stufft.io/image/1O2l2g073h0h, which still lets you login with OpenID but it's muted and downplayed.

In a slightly hypocritical view point, I actually think that at some point we should get something like id.python.org which is an IdP and switch all of the *.python.org sites to authenticate against that instead of keeping local user accounts. This would reduce the number of passwords that Python inflicts on people but it still keeps authentication within our (PSF/Python/whatever)'s control. This is more along the lines of implementing SSO using a federated auth technology than actual federated auth though.

Counterpoint: why not get rid of local auth altogether (for web service, not system administration). What do we, a non-profit, do that requires direct control over auth? At least - bugs.python.org, pypi, both of which support OpenID today, we've clearly considered that there its ok.

If we didn't have local auth at all that would free up cycles to do whatever (moderate) chasing of evolving federation standards is needed.

I don't trust other services to handle authentication for something as important as PyPI, and it's unlikely that a service ends up coming around that I both trust enough to be willing to give them the ability to essentially authenticate as a wide number of users whenever they want, and where I'm willing to tie the long term operability to PyPI as a service to them in a way where we can't easily pull them out of our stack and replace it with minimal impact on end users. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA