On Tue, Apr 28, 2009 at 8:46 AM, Blaine Cook <[email protected]> wrote:
>
> On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane <[email protected]> wrote:
>> Yes, that's right. What it does (for the sake of the SP) is assert
>> "this user on the consumer is indeed the same user that authenticated
>> at the SP." Authorization always requires authentication (system
>> needs to know "who" it is authorizing).
>
> For OAuth, this relationship is simple. The SP authenticates the user,
> but authorizes the consumer-plus-request-token pair. The SP *does not*
> authorize an authenticated user at the consumer end. That relationship
> is up to the consumer to decide.
>
> Put another way, if TweetCash had been given authorization by many
> users to access Twitter accounts, they (TweetCash) could impersonate
> any one of those accounts in any way they choose. However, it's a
> trust relationship. If TweetCash were to abuse that trust, then
> Twitter has the ability to disable their access wholesale (via the
> consumer key) or the users have the ability to revoke access on a
> case-by-case bases. At no point can Twitter *guarantee* that TweetCash
> isn't abusing the trust, but it's probably impossible to do so without
> creating an unusable technology, particularly for the sorts of
> problems we're trying to solve.
>
Sorry -- I did not completely get what you were saying at first. Yes,
the SP definitely places a lot of trust in the consumer to "do the
right thing" regarding the authorizations it has granted that
consumer, and the ability to disable that access wholesale is a great
feature of OAuth. I certainly did not mean to suggest that the SP
should be able to guarantee that the consumer is not abusing that
trust (indeed the SP-consumer trust is a core basis upon which OAuth
is based). My goal is to make sure we have a spec that, given a
"good" consumer and a "good" SP, will not allow a bad user to
victimize a good user.
--peter
> The exploit that we're dealing with is that the consumer has no way to
> ensure that the SP has authorized access to the intended party. The
> verification token *does* ensure this, since it guarantees that the
> person that clicks "Authorize {consumer}" is the same one that is
> interacting with the consumer, and that's all we're trying to solve.
> OAuth does not, and should not, attempt to authenticate identity
> across sites.
>
> b.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
