[Mailman-Developers] Architecture for extra profile info

[Xu Wang]

On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull <stephen at 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