[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Florian Fuchs writes:

 > If the instance of the user store does not act as provider, we would either:
 > 
 > 1) effectively require every api user to have an account with some
 > other oauth provider.

Most people do.

Sites that care can bring up their own provider.  AFAIK that's not
terribly hard, and I doubt that Mailman can make it much easier.  But
we shouldn't encourage it.  Requiring a specific provider sucks if not
necessary for security reasons; users just end up managing yet another
password and get no benefit.  Adding a new provider, even if not
required, is likely to cause the same problem if the user later signs
up with a well-known provider.

The point of OAuth for Mailman is that it's nearly formally equivalent
to the traditional 3-part handshake (request subscription, receive
token by mail to subscribed address, return token thus proving you are
owner of the address), since most OAuth providers are email providers.
Perfect fit.

 > or
 > 
 > 2) use some other authentication method.

What's wrong with HTTPS + Basic Auth?

 > Anyway, we're talking about something that is absolutely not needed
 > for what we want to achieve *right now*, which is a profile data store
 > that Postorius/HK/etc can access from localhost (or maybe from an
 > internal network. Or IP-restricted through SSL. Or... ?).

OAuth (or Persona, etc) access for subscribers (to Postorius and
HyperKitty) using subscribers' existing OAuth provider is not
*absolutely* needed, but would be a very big plus.  Users hate
managing passwords for resources they don't care much about security.
Once we've got that, I would think it's a relatively small step (in
terms of code) to implementing for inter-component communications.

The security audit required might be quite a bit of work, so we might
not recommend deploying the feature in "high" security contexts.