Florian Fuchs writes:

But maybe we can take a moment to think about the usefulness of such a feature and the possibilities this might open up, rather than dismissing the use of a certain technology right off the bat.

I'm not dismissing the use; I'm saying an authentication provider is out of scope for Mailman, for several reasons.

An auth client is something we clearly need. The mail auth we use (plain text passwords) is clearly weak, and we need to improve that. Web auth is probably OK for most sites if we use HTTP Basic Auth over HTTPS. OAuth (or "social auth" or Persona) is clearly a major convenience for users, and probably significantly increases security all by itself (no need for Post-Its with the Mailman password you almost never use on your monitor bezel). Both HTTPS+BasicAuth and OAuth have the advantage that Mailman can delegate the handling of transmission of secrets over the Internet to professions. Given that HTTPS+BasicAuth is probably good enough for most of our users, and most of the rest will want to use Google/Yahoo/whatever rather than YAP, where's the need for a provider?

And I *am* thinking about the possibilities implementing a provider opens up. Namely, the possibility that we'll distribute buggy code. :-P

I remember several discussions during PyCon(s) and on IRC where scenarios of different mailman instances talking to each other came up. Of course that doesn't mean implementing a generic oAuth provider is the only answer to this. If there are better and easier solutions, fine.

The OAuth2 protocol spec (RFC 6749) makes obscure reference to "scope" and tokens acceptable to multiple resource servers. But I don't think sharing authorizations is something that a provider deals with.