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.
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
