Abhilash Raj writes: > Hi all, > I wrote a brief summary[1] of this thread.
You've misinterpreted or mistyped a couple things I wrote: I'm not against OAuth in general, just against Mailman being an OAuth *provider*, or bundling one, because we can't support it properly. Users should get auth stuff from somebody whose primary interest is security stuff. When I write authentication and authorization should be avoided, I don't mean Mailman doesn't authenticate and authorize users. I mean the implementation should be delegated to robust, well-tested modules or external applications (eg, Apache) whereever possible. The last quote needs to be fleshed out. "This practice" refers to not exposing keys and other secrets to the whole application, including cooperating processes. If authentication can be done in one place and an internal session or one-time authorization be granted, that's what should be done, rather than exposing user credentials to other parts of the application to do their own authentication and authorization. In making such a summary, I think it would be better to organize by topic. Eg, a partial outline: REST API for extended user profiles Authorization Trusting local connections HTTP Basic OAuth - Recommended for "outside world" [Florian] - Advocates including an OAuth provider as a non-default, experts-only option [Florian] - Opposes bundling an OAuth provider [Stephen] - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for now? [Stephen] - Don't need an OAuth provider to share authorizations (in fact, at least in OAuth 2.0, providers don't provide sharing at all) [Stephen] - Implementing OAuth provider doesn't provide the benefits of OAuth (ie, add an OAuth provider means users have yet another set of credentials to manage) [Stephen] - OAuth architecture = provider + client + consumer [Richard] - Agrees to Mailman as OAuth consumer, not provider [Richard] - OAuth may be overengineering, at first [Barry] Database schemas Database implementations Wire Protocol etc... Also, in that format it's easy to reorganize: REST API for extended user profiles Authorization Trusting local connections HTTP Basic OAuth - OAuth architecture = provider + client + consumer [Richard] - Use client in Mailman? - Recommended for "outside world" [Florian] - Agrees to Mailman as OAuth consumer, not provider [Richard] - OAuth necessary? Why isn't HTTPS + Basic Auth good enough for now? [Stephen] - OAuth may be overengineering, at first [Barry] - Use provider in Mailman? - Advocates including an OAuth provider as a non-default, experts-only option [Florian] - Opposes bundling an OAuth provider [Stephen, Richard] - Implementing OAuth provider doesn't provide the benefits of OAuth (ie, add an OAuth provider means users have yet another set of credentials to manage) [Stephen] - Don't need an OAuth provider to share authorizations (in fact, at least in OAuth 2.0, providers don't provide sharing at all) [Stephen] Database schemas Database implementations Wire Protocol etc... By the way, don't go out of your way to reorganize what you've already done, except as it's useful to you. Gradually improve it as it helps you to recall discussion. _______________________________________________ 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