Richard Wackerbarth writes:
On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" <stephen@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.