On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull <step...@xemacs.org>wrote:
> Xu Wang writes: > > > For OAuth <http://en.wikipedia.org/wiki/OAuth>, you need to > > implement token based auth in API, as well as a provider service > > because there is no open OAuth provider service for third party API > > out there :-( > > No, we don't *need* to implement *anything*. We implement what we > want to. That's the nature of a volunteer project. > Loud and clear. > > I'm recommending against becoming a provider because I think it's too > hard to provide the enterprise-strength implementation you focus on. > The client side is much easier. > Agreed. > > In my view, OAuth really belongs to an enterprise system, rather > > than a specific api or one application. It requires a existing > > robust web-based auth system on the provider's site. > > It very much depends on how accurate the identification of the client > needs to be. For an open subscription service where the only thing > you really need to do is confirm ownership of the subscribed address, > any provider the user trusts is good enough. > The problem is how do you "confirm ownership of the subscribed address" when a request coming with an access token. In another words, unless your are the provider, how do you validate the access token issued by a provider at the resource endpoint? > > This will also make the API less "independent" because it is depending > on > > the provider service and provider's auth system. > > Why? The whole point of the OAuth protocol is that the authentication > is delegated to an OAuth client, which contacts the provider, and if > successful returns a token to the customer. The customer then > interprets that token as it likes. The tokens have a specific, > well-known form, so the authentication subsystem is completely > independent of the application API. > > I may misunderstood you, but OAuth doesn't specify the format or content of the access token. It is left to the implementation of a provider. This is true for both OAuth 1.a and OAuth 2. To control the access of a resource, a provider have to authenticate both client and the resource owner, issue an access token if authenticated resource owner authorized the resource access for a specific client (authenticated by a client id and a secret). When the access token coming with a request at the API, only the provider or an agent of the provider knows what it is. What I'm saying is that if OAuth is supported, mailman will be a part of provider because it holds and protects the user's data. > There does need to be coupling to the UI, to provide a channel to the > OAuth provider. > > > Only if there is a strong 3-legged auth use case, should one push to > this > > controversy route. > > I don't see 3-legged auth as the killer app for OAuth here. Rather, I > see convenience for subscribers as the main feature, although it might > also be useful for moderators and other admins. > > Stev _______________________________________________ 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