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