Re: [Mailman-Developers] Architecture for extra profile info

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
Moderation queues. Moderators need access. List owners grant access on the basis of identity of the moderator.
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.
Lists. List owners need access. List owners are delegated authority from site (or vhost) admin. ID is authorization.
Virtual hosts (vhosts). A namespace for lists based on a domain name (DNS MX). Delegated by site admins. ID is authorization.
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.
AFAICS this is all we need, see above.
participants (1)
-
Stephen J. Turnbull