[Mailman-Developers] Architecture for extra profile info

Stephen J. Turnbull stephen at xemacs.org
Mon Apr 29 06:07:16 CEST 2013


Xu Wang writes:

 > As oauth supported google's userinfo API, one need to present a valid
 > google's oauth access token to get access.
 > s/google/mailman/g  on above statement, it will be true too.

I disagree, in the sense that Google (as an OAuth provider) is in the
business of *providing* enterprise workflows such as AppEngine.
That's why they need to be an OAuth provider.  Mailman is a support
function for workflows (enterprise or otherwise).

So it's not a "Mailman" token.  It's an <enterprise> token, and the
enterprise, not Mailman, should be the provider.  If Mailman provides,
then we have to take responsibility for foreseeing enterprise needs.

If we go Wacky's route and make everything as generic as possible, we
may need the power of OAuth to handle all that genericity.  (We may
also then need another 5 years to release Mailman 3....)  But if we
stick to the current role-based authorization model with a small fixed
set of roles, then OpenID-like workflows (whether implemented via
OAuth protocol or otherwise) should be enough.

If a site demands more control over authentication than public OpenID
providers can afford, then Basic Auth over HTTPS fits into the "user
has role" authorization model as well as OpenID does.  I don't see a
need for Mailman to provide an authentication provider, and there are
serious downsides to the proliferation of authentication providers.

Steve


More information about the Mailman-Developers mailing list