On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <step...@xemacs.org>wrote:
> Xu Wang writes: > > On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull < > step...@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: step...@xemacs.org; > email:stephen.turnbull...@u.tsukuba.ac.jp; owner: > fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...; > OpenID: stephenjturnb...@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. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9