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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9