I agree that "2. test(B==C) , i.e., verify that the user at B is the same user at C" is not the same as "2b. min Prob(B!=C)".
The former is clearly more desirable. If someone logs in to the both sites using something like OpenID, then it is trivially achieved without much user interaction impact, assuming OpenID AuthN is safe enough. For example, make verified_identifier a part of tokens. Then, user AuthN at the SP can be done automagically by browser redirect. =nat On Sat, Apr 25, 2009 at 8:26 PM, pkeane <[email protected]> wrote: > > 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 <[email protected]> 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 > > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
