Address Bar

[Breno]

The idea is that you must trust the site with your verified by visa
credentials to start with.

On Thu, Mar 26, 2009 at 5:00 AM, Ben Laurie <benl at google.com> wrote:
> On Thu, Mar 26, 2009 at 1:29 AM, Breno <breno.demedeiros at gmail.com> wrote:
>> I think we are stretching this analogy to the breaking point.
>>
>> Visa Payment Trust Model   vs OpenID Trust Model.
>>
>> Visa Payments: User trusts parent frame (merchant/bank) with
>> credentials (credit card)
>> OpenID: User does not necessarily trust parent frame (RP) with that
>> particular set of credentials (own credentials at the OP)
>>
>> Visa Payments: User does not necessarily trust the framed site
>> (payment processor) with his credentials because of lack of brand
>> recognition.
>> OpenID: User trusts the iframed site (OP) with this particular set of
>> credentials.
>>
>> Visa Payments: Parent frame (merchant/bank) has explicit agreement
>> with payment processor and wishes to leverage the user's trust in the
>> merchant to have him/her enter this credentials at the processor.
>> OpenID: No explicit agreement between RP and OP.
>>
>>
>> So the iframe in Visa Payments is the mechanism by which one
>> accomplishes a transfer of trust (user -> merchant/bank) --> (user ->
>> payment processor), and this is covered by legal agreements.
>> Accordingly, the burden on the user to protect him/herself against
>> phishing is simply to recognize the merchant/bank site. Iframing is
>> the appropriate mechanism in this case.
>
> I totally don't understand this. When the "merchant" is a phishing
> site whose purpose is to get my "verified by visa" password, what
> legal agreement is protecting me?
>
>>
>> In the case of OpenID, iframing requires that the user transfers (user
>> -> OP) --> (user -> RP). This implies that the OP is leveraging its
>> brand identity (in the login box) to convey trust to the user in the
>> RP (including trust in releasing own OP's credentials there). There is
>> no contractual framework in OpenID to allow that. The user is burdened
>> with the need to recognize that the iframe points to the OP.
>>
>> That is not to be said that the analogy is _never_ good. If the OP
>> implements non-spoofable authentication (e.g., token-based auth), then
>> the trust transference is not required. However, for OP that accept
>> password-based authentication, the iframe model does not work without
>> an explicit (and publicly recognizable by the user base) mutual
>> agreement.
>>
>>
>> On Wed, Mar 25, 2009 at 5:23 PM, jDavid <jdavid.net at gmail.com> wrote:
>>> I wonder if the story for HTTPS/SSL is a good one for us to look at?
>>>
>>> or did it just happen so early in browser life that it was easy?
>>>
>>> 2009/3/25 Johannes Ernst <jernst+openid.net at netmesh.us>
>>>>
>>>> This is really interesting.
>>>>
>>>> It seems to me that we are struggling with a problem that is in no way
>>>> specific to OpenID. It sounds like we should try and get everybody in a room
>>>> that has the same problem -- like Visa in this example -- regardless of
>>>> whether they have ever heard of or like OpenID, and come up with:
>>>>
>>>> 1. this is the best we can do with existing browsers, and we all educate
>>>> the user the same way about the flow
>>>>
>>>> 2. a wish list for the browser companies how to offer better browser
>>>> support natively for this particular pattern. Some generic pattern markup
>>>> (not OpenID-specific, but for the redirect pattern) might be advantageous.
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 25, 2009, at 10:57, Martin Atkins wrote:
>>>>
>>>>> Allen Tom wrote:
>>>>>>
>>>>>> Do you have more details about the verified by visa process? I'm not
>>>>>> familiar with it.
>>>>>> I actually bought something online this morning, and I noticed that the
>>>>>> merchant's checkout confirmation page mentioned something about portions of
>>>>>> the screen being rendered by my credit card issuer in an iframe, which I
>>>>>> thought was a weird thing to tell to the end user.
>>>>>
>>>>> I'm by no means an expert on 3D-Secure (which is the technology
>>>>> underlying Verified By Visa), but the flow seems very similar to OpenID:
>>>>>
>>>>> * Merchant does "discovery" on your credit card to find out who your
>>>>> provider is.
>>>>>
>>>>> * Merchant sends you to that provider where the provider authenticates
>>>>> you by some means -- in my case, I get asked to enter three letters out of a
>>>>> secret word and some other security questions, but I assume this varies from
>>>>> provider to provider -- and sends an assertion back to the merchant.
>>>>>
>>>>> * The merchant recieves the assertion and processes the transaction.
>>>>>
>>>>> The ever-reliable Wikipedia tells me that the Verified By Visa brand of
>>>>> the protocol recommends loading the provider's UI in an iframe in order to
>>>>> *stop* users seeing the address bar, because many savvy users mistook it for
>>>>> a phishing scam:
>>>>> http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/
>>>>>
>>>>> (one might argue that this would be less of an issue if the issuing banks
>>>>> served the data in their own domain rather than outsourcing it, but I
>>>>> digress.)
>>>>>
>>>>> The "criticism" section of the Wikipedia page on 3D-secure details a
>>>>> bunch of problems that OpenID implementors have also encountered.
>>>>>
>>>>> _______________________________________________
>>>>> user-experience mailing list
>>>>> user-experience at openid.net
>>>>> http://openid.net/mailman/listinfo/user-experience
>>>>
>>>>
>>>>
>>>> Johannes Ernst
>>>> NetMesh Inc.
>>>>
>>>>
>>>>
>>>>  http://netmesh.info/jernst
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> user-experience mailing list
>>>> user-experience at openid.net
>>>> http://openid.net/mailman/listinfo/user-experience
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Justin Kruger -- Sr. Software Engineer - MySpace MDP
>>> http://jDavid.net
>>> jDavid.net at gmail.com
>>>
>>> Anton Freeman: Vincent! How are you doing this Vincent? How have you done
>>> any of this? We have to go back.
>>> Vincent: It's too late for that. We're closer to the other side.
>>> Anton Freeman: What other side? You wanna drown us both?
>>> Vincent: You wanna know how I did it? This is how I did it Anton. I never
>>> saved anything for the swim back.
>>>
>>> _______________________________________________
>>> user-experience mailing list
>>> user-experience at openid.net
>>> http://openid.net/mailman/listinfo/user-experience
>>>
>>>
>>
>>
>>
>> --
>> Breno de Medeiros
>> _______________________________________________
>> user-experience mailing list
>> user-experience at openid.net
>> http://openid.net/mailman/listinfo/user-experience
>>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>



-- 
Breno de Medeiros