[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
 > persona, kerberos, etc.) were protocols whereby one system (the
 > provider) furnishes credentials for a second system (the client) to
 > some third system (the consumer).

That's correct.

 > If we assume that we distribute the MM implementation to include
 > more than the two (core and web UI) systems by having, for example,
 > a user manager, there might be an argument for passing around such
 > credentials.

But the does provide a user manager, and the "extra profile info" is
in fact intended to be a user manager external to the core.

 > Thus, although we need some level of authentication of the agent,
 > there is no need for third party credentials such as those
 > implemented in oAuth.

The point is that in many cases we would like to dispense with the
agent authentication process altogether, and let a third party manage
that.  This is perfectly acceptable in the case of open subscription
lists where we simply want to ensure that only the subscriber can
change their subscriptions.  For example, a person subscribing a Gmail
account to use that account's credentials rather than creating new
owns inside of Mailman -- which we trust only because the person
demonstrates in a roundabout way that they can access that mailbox.
OAuth allows us to make that check directly in real time.

I suppose that what Florian is thinking is that some owners want
*closed* subscription processes, and therefore want to control the
authentication process themselves.  I agree that that is a valid and
likely (if unusual) use case.  I just think it's better for such users
to go find a provider implementation themselves, rather than offer
them something that I know *I* can't properly design or review, and
haven't seen credentials from anyone else on the team that they can do
it, either.

 > 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.