[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Xu Wang writes:

 > No OpenID does not uses OAuth protocol.

My mistake.

Let's talk about what Mailman needs, then.  OpenID (or an equivalent
based on a more general system) is all that Mailman needs as far as I
can see.  AIUI, the resources that can be accessed or mutated, in
order of frequency of use, are

1. Moderation queues.  Moderators need access.  List owners grant
   access on the basis of identity of the moderator.

2. Subscriptions.  Subscribers and list owners need access.
   Subscribers usually own the subscribed address and have a privacy
   (no spam) right.  (In employment and education cases, subscribers
   may have restricted rights, but ID == authorization holds.)  List
   owners are delegated authority from site (or vhost) admin.  They
   may have "legal" (or "precedent") rights to the subscriber list and
   archives.  Either way, ID is authorization.

3. Lists.  List owners need access.  List owners are delegated
   authority from site (or vhost) admin.  ID is authorization.

4. Virtual hosts (vhosts).  A namespace for lists based on a domain
   name (DNS MX).  Delegated by site admins.  ID is authorization.

5. Site (collection of vhosts).  A physical system.  Delegated to site
   admin from outside.  ID is authorization.

Corner cases: (1) People with multiple roles may prefer to have to
re-login (or "su") use "higher" privilege.  "su" or "sudo" mechanisms
can address this.  (2) Delegators may wish to de-authorize
delegatees.  An ID-based authorization means some lag.  This can be
mitigated by granting authorization with short expiration, but that
has its issues too.

 > Mailman can't use GMail as OAuth provider to protect mailman's own
 > resource as a general authorization solution.

Evidently it can't use it at all, if OpenID isn't based on OAuth (and
the OAuth protocol exposed to GMail users).

 > As you put it,  mailman don't have to support OAuth, but if it dose, it's
 > better stick to the protocol.

I don't see how anything general I said doesn't stick to protocol.

*Validation* is a syntactic operation.  Contacting the resource owner
and asking "is this token one of yours?" is one way to validate.
(Traditional 3-way handshake for validating mail addresses when
subscribing is exactly this.)  But using encryption or signatures is
another way.

 > I'm new to mailman and have a very limited knowledge about what
 > kind of "fine-grained" authorization it may need other than
 > authentication. (read: Xu had no clue ...)
 > 
 > >From the api implementation point of view, a role base authorization can
 > be bundled in, which allows admin or resource owner to associate user with
 > roles and roles with endpoints/methods.

AFAICS this is all we need, see above.