On Apr 26, 2009, at 12:32 AM, Nat Sakimura wrote: > > 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.
+1 > > 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. Assuming that the "verified_identifier" is the same at both sites, and that the same user doesn't maintain two OpenIDs... - johnk > > > =nat > > On Sat, Apr 25, 2009 at 8:26 PM, pkeane <pjke...@gmail.com> 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 <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 >>> >> > > > > -- > 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 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 -~----------~----~----~----~------~----~------~--~---
