On Wed, Apr 29, 2009 at 4:34 AM, Nat Sakimura <[email protected]> wrote:
>
> I think C can send the info that it is A who is requesting the data to S:V.
>
> In the four legged case, the privacy leakage is not a problem, because
> the data acquirer must identify himself to the data provider anyways
> to obtain permission.
>
> In the tree legged case, it might pose a sort of correlation problem
> (privacy), but since S cannot learn too much activity of V at C, it
> probably would not be that bad.
>
> And, yes. This is not a technical approach, but legal and social
> approach, but is valid IMHO.
What if, in the case of "Login with Twitter", the "identity" of the
user logging in is a random cookie string?
We're not going to solve verifiable identity federation here.
Furthermore, I posit that OAuth will not work if you require some kind
of OpenID login before connecting. The whole point is that OAuth works
without user accounts being a pre-requisite on the consumer side.
Desktop and mobile apps are one case, "twitter connect" is another,
but there might also be cases where a full three-legged flow is
completed, but the entity being approved *is* a website, not a
user-of-a-website. For example, I might want to give permission to a
private community site (e.g., a university class website) to crawl a
private feed and make the resulting data available to everyone that
has access to the site (not just me).
What we need right now is a careful vulnerability assessment of the
verification key ("signed callback") approach. It seems like we have
by far the most consensus around that approach, and it is relatively
simple to implement for both consumer and service provider alike. If
anyone has any ways that the two proposals on the table *do not* solve
the security problem that we face *right now*, then please raise them!
We can move forward based on concrete criticism of this approach (or
lack thereof), but we can't just keep assessing new proposals based on
unexplained theoretical biases, all due respect.
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
-~----------~----~----~----~------~----~------~--~---
