On Apr 18, 2013, at 12:21 PM, "Stephen J. Turnbull" <step...@xemacs.org> wrote:
> 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. Perhaps I didn't understand you. I thought that you were advocating the omission of any channels other than "shell" and "localhost". I was trying to point out that HTTPS, oAuth, etc. should be equally viable (and they don't REQUIRE that the components reside on the shame host). _______________________________________________ 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
