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

Xu Wang writes:

...

On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull < stephen@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@xemacs.org; email:stephen.turnbull.fw@u.tsukuba.ac.jp; owner: fs-phil@turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta@xemacs.org ...; OpenID: stephenjturnbull@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.