[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

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.