=...@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/
>>
>>>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
