[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 12:21 PM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

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