Sorry: Almost all of the proposed solution attempt to minimize the possibility that user at B is NOT the same as user at C.
is what it should say... On Apr 25, 10:19 pm, pkeane <pjke...@gmail.com> wrote: > Here is an attempt to help spell out the OAuth security in simple > terms and thus provide a framework to judge various proposed fixes. I > float this as either a useful shared assumption OR a strawman to knock > down so the the issue can be addressed in some other way. > > Eran, in his explanation, outlined there steps that are not connected > but *need* to be connected for the protocol to be secure. > > A. user initiates a consumer-to-provider handshake > B. user logs in to provider (or verifies they are logged in) and > authorizes this handshake from the provider side > C. now back at the consumer, users does useful things based on the > securely transacted handshake > > The OAuth spec MUST accomplish either of the following to close the > security hole: > > 1. verify that the user at A is the same user at B > 2. verify that the user at B is the same user at C > > Almost all of the proposed solution attempt to minimize the > possibility that user at B is the same as user at C. Is that enough? > It's true that actual "verification" will impact the user experience > negatively (as actual authentication/verification inevitably does). > > It's probably worth thinking about what "verification" means and how > that might be achieved. Otherwise, I think the community needs to > decide if "minimizing possibility" is enough. > > --peter keane --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
