[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
 > 
 > > Richard Wackerbarth writes:
 > 
 > >> There is no reason why alternate channels [to a connection from
 > >> localhost authorized by the OS] cannot be substituted as long as a
 > >> means of identification (such as shared secrets) is utilized.
 > > 
 > > Sure, but didn't you notice the elephant in the room as you swept it
 > > under the rug?  The implementation of "alternate channels" matters *a
 > > lot*, and it's not trivial.
 > 
 > Just because something is important or non-trivial to implement
 > properly does not imply that it is difficult for us to utilize it.
 > Rather than developing our own, we can, and should, leverage the
 > efforts of "the professionals" and use the tools that they provide
 > (such as https and oAuth, etc.).
 > 
 > Certainly, the proper administration of each, and every, host is an
 > essential element to prevent access "on the coat tails" of the
 > trusted agents. But that also applies to the "localhost"
 > implementation.

I don't understand what you're advocating, your comments are way too
general.

My position is that secure authentication and authorization is a hard
problem, and we should avoid doing that as much as possible (partly
because as far as I know none of us are experts).  No channels that
few sites will use, ditto OAuth providers.  Concentrate on a couple of
channels with specific, well-understood, universal (or at least very
common) use cases.

The channels I have in mind are (1) shell access, (2) Basic Auth over
HTTPS for people who need to control access fairly tightly, and (3)
OAuth and/or Persona clients allowing authentication by any of a
number of public providers for user (especially subscriber)
convenience.  I'm not wedded to any of those (except (1), for obvious
reasons), but I don't think it's a good idea to extend the list if we
can avoid it.