I agree that the signed callback solves the problem iff the Consumer waits to correlate the request token with the account/session making the callback, not the one obtaining the request token.
Does this put too much of a burden on Consumers? jesse On Wed, Apr 29, 2009 at 8:04 AM, pkeane <[email protected]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
