On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" <stephen@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.