Peter, thanks for putting the PIN idea in context for me. This is
perhaps a dumb question, but since testing equivalence of the *user*
(a bag of protoplasm) is sort of a last-mile problem anyway, and since
-- if I'm understanding the long Security Advisory discussion thread
correctly -- even PINs have social engineering risks, aren't we really
just looking for ever-better ways to do "weak" equivalence rather than
testing true equivalence?
Eve
On Apr 27, 2009, at 8:01 AM, Peter Keane wrote:
>
> On Mon, Apr 27, 2009 at 9:42 AM, Eve Maler <[email protected]> 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 <[email protected]> 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 <[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/
>>>>>
>>>>>>
>>>>
>>>>
>>>>>
>>>
>>>>
>>
>>
>> Eve Maler eve.maler @
>> sun.com
>> Emerging Technologies Director cell +1 425 345
>> 6756
>> Sun Microsystems Identity Software www.xmlgrrl.com/
>> blog
>>
>>
>>>
>>
>
> >
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 [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
-~----------~----~----~----~------~----~------~--~---
