Richard Wackerbarth writes: > On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" <step...@xemacs.org> > wrote: > > > Richard Wackerbarth writes: > > >> There is no reason why alternate channels [to a connection from > >> localhost authorized by the OS] cannot be substituted as long as a > >> means of identification (such as shared secrets) is utilized. > > > > Sure, but didn't you notice the elephant in the room as you swept it > > under the rug? The implementation of "alternate channels" matters *a > > lot*, and it's not trivial. > > Just because something is important or non-trivial to implement > properly does not imply that it is difficult for us to utilize it. > Rather than developing our own, we can, and should, leverage the > efforts of "the professionals" and use the tools that they provide > (such as https and oAuth, etc.). > > Certainly, the proper administration of each, and every, host is an > essential element to prevent access "on the coat tails" of the > trusted agents. But that also applies to the "localhost" > implementation.
I don't understand what you're advocating, your comments are way too general. My position is that secure authentication and authorization is a hard problem, and we should avoid doing that as much as possible (partly because as far as I know none of us are experts). No channels that few sites will use, ditto OAuth providers. Concentrate on a couple of channels with specific, well-understood, universal (or at least very common) use cases. The channels I have in mind are (1) shell access, (2) Basic Auth over HTTPS for people who need to control access fairly tightly, and (3) OAuth and/or Persona clients allowing authentication by any of a number of public providers for user (especially subscriber) convenience. I'm not wedded to any of those (except (1), for obvious reasons), but I don't think it's a good idea to extend the list if we can avoid it. _______________________________________________ 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