[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

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.