[Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Xu Wang writes:
>  > On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
> stephen at xemacs.org>
>  > wrote:
>  > > Xu Wang writes:
>  > >
>  > >  > The problem is how do you "confirm ownership of the subscribed
>  > >  > address" when a request coming with an access token.
>  > >
>  > > You don't.  That was done when the OAuth ID was linked to the address,
>  > > using the usual 3-step handshake (submit the association, receive an
>  > > email containing a secret, confirm ownership by replying with the
> secret).
>  >
>  > I'm not sure what you mean by "OAuth ID".
>
> In the case of Mailman's use cases, it will typically be an email
> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID
> provider.  Often, but not necessarily, it will be the subscribed address.
>
>
OpenID is about authentication. OAuth is about authorisation.
What are we talking about here? Support to OpenID or support to OAuth or
both?

 > As a resource server, the API need to validate the access token but
>  > how to validate the access token is not part of OAuth.
>
> This is some of the excess complexity (if you prefer, "enterprise
> readiness") in OAuth 2.0.  In Mailman usage, the resource that the
> consumer gets access to will be a user ID.  Eg, I might be "user:
> stephen; name: Stephen Turnbull; email: stephen at xemacs.org;
> email:stephen.turnbull.fw at u.tsukuba.ac.jp; owner:
> fs-phil at turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta at xemacs.org ...;
> OpenID: stephenjturnbull at gmail.com".  So when I login via OpenID
> (which uses the OAuth v1 protocol AFAIK),

No OpenID does not uses OAuth protocol.


> the provider (GMail) asks me
> to verify who I am by presenting my credential (most users will think
> of this as "getting the login screen"), and in turn it testifies to
> the client that I own that email at GMail, and the consumer (eg, the
> HyperKitty app) then looks it up, identifies me, logs me in as
> "stephen", and gives me a cookie (session auth token).  The
> authentication *is* the validation here.
>

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

OAuth v2 envisions more complex scenarios where the client may present
> the same token repeatedly, or consumers might hang on to them and
> present them to the resource owner repeatedly, or even pass them on to
> other consumers.  In those cases, yes, there will need to be
> validation etc going on.  For example, the token might be a (ID, URI,
> expiration-date) tuple encrypted with the resource owner's private
> key.  Being able to decrypt and getting a syntactically correct,
> unexpired tuple would then be validation of an authorization to fetch
> that URI.  (In this particular case I'm thinking of "any valid user is
> OK".)  This does require prior coordination between the provider and
> the resource owner on token format and exchange of keys.
>
> But AFAICS Mailman's currently envisioned applications don't require
> this complexity.
>

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


> Do you have any ideas for Mailman that might require something more
> fine-grained than just "this user is logged in"?
>

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.