[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> 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 have no problem with, and actually encourage, that we act as a consumer of oAuth credentials.
However, the issue here is whether we should be provider of oAuth credentials (which might then be presented to some outside, totally unrelated, entity.