[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

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).

 > In another words, unless your are the provider, how do you validate
 > the access token issued by a provider at the resource endpoint?

I'm not sure what you mean.  In the security context (as others),
"validate" means mostly "check the syntax".  But a valid token is
assumed to be authentic (otherwise the provided has been suborned).

Remember, a provider does not *authorize* anything.  A provider offers
a channel of communication to the resource owner, who does the
authorization.  Ie, provider tells owner "client tells me consumer
wants to access the X Files", and on success returns a token to the
client indicating "I've confirmed that you are indeed talking to the
owner, and by the way, *she* says it's OK to let consumer look at
them."

 > > 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.

I'd have to look again to be 100% sure, but I'm pretty sure that what
the provider returns is well-defined.  What the client gives to the
application is application-defined.

 > 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.

Again IIRC, the provider doesn't know what the token is.  The *client*
does.  The provider just passes a message saying "Access to the X
Files, which you own, have been requested.  Is that OK?"

In practice, the common case is that consumer == owner, so effectively
the message boils down to, "Click OK if you are you".

 > 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.

OAuth providers don't know about the protected data.  OAuth consumers
do.  The provider-client combination only offers a communication
channel.  That's what is so elegant about the OAuth concept.

Steve