On Tue, Apr 28, 2009 at 8:46 AM, Blaine Cook <rom...@gmail.com> wrote:
>
> On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane <pjke...@gmail.com> 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.
>
That is an interesting & useful way to look at it. The SP "trusts"
its own authentication mechanism and the consumer signing up for OAuth
services. I had though, though, that this was about the SP offering a
trustworthy service to its *users*. In other words, saying -- "we
offer OAuth w/ these consumers because we trust all of the pieces to
work." The exploit is a danger to the SP only inasmuch as it is a
danger to the user.
As a convenience mechanism, OAuth is just fine. But I was imagining
3-legged OAuth as potentially useful for more highly *risky*
operations, like access to confidential personal or health records.
That may not be a safe assumption on my part, tough (?).
> 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.
I would definitely agree that if the verification token does
"guarantee that the person that clicks 'Authorize {consumer}' is the
same one that is interacting with the consumer" that's everything we
need. But that *is* "authentication" -- to actually verify that
(given the statelessness of HTTP) is tricky. Essentially, the
verification token is attempting to establish "state."
-peter
>
> b.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
