On Mon, Apr 27, 2009 at 9:42 AM, Eve Maler <eve.ma...@sun.com> wrote: > > Other than injecting identification into OAuth explicitly, *and* then > using a uniform identification system on both the consumer and service > provider side (e.g. OpenID), strong equivalence -- test(B==C) -- is > impossible. And if identification in any one case is associated with > a sufficiently weak or phishable means of authentication, strong > equivalence may come into question again. > > There is great value in OAuth remaining agnostic on the identification > question -- for example, it allows OAuth to be applied in "brownfield" > situations where the consumer and service provider started out with > different systems, vs. creating a hard dependency on a disruptive > change to those systems. Many of my use cases depend on parties > applying OAuth dynamically without knowing yet if the same > identification system is in use. I hope there is interest in > developing a solution for the weaker form of equivalence -- min Prob(B! > =C) -- perhaps in addition to the strong form. >
Hi Eve- I completely agree on the need for OAuth to be agnostic re: identification. My various scenarios "verify" B==C entail a "temporary" agreement. Specifically, a PIN (or "valet key" as I called it in a previous proposal) that the user can remember just for completing the handshake. Essentially, identity in the "local" scope rather than identity in the "global" scope (e.g., OpenID). OAuth hooking into a global scope identity creates a dependency that makes OAuth much less attractive. I'm not convinced we need to settle for prob(B!=C), but if a local scope shared identity mechanism is not implemented (or seen to be too detrimental to UX), that may be the case. --peter > Eve > > On Apr 26, 2009, at 8:13 AM, Nat wrote: > >> >> >> >> =...@san Francisco via iPhone >> >> On 2009/04/26, at 5:38, John Kemp <j...@jkemp.net> wrote: >> >>> >>> 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... >>> >> >> It is either the verified identifiers matches (among other things) >> thus the access is granted or does not match and the authorization >> fails. >> >>> - 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/ >>>> >>>>> >>> >>> >>>> >> >> > > > > Eve Maler eve.maler @ sun.com > Emerging Technologies Director cell +1 425 345 6756 > Sun Microsystems Identity Software www.xmlgrrl.com/blog > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
