On Apr 29, 3:17 am, Blaine Cook <[email protected]> wrote:
> 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!
>
Seems like the discussions have raised interesting points, but
(reading betweens the lines) I am seeing a consensus that the "signed
callback" is indeed sufficient to address the problem at hand, and
doesn't preclude possiblility of further security-enhancing work in
the future.
I think moving forward with a revised spec incorporating the "signed
callback" method would be a good thing.
--peter
> 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
-~----------~----~----~----~------~----~------~--~---
