Address Bar

Thu Mar 26 12:00:41 UTC 2009

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
>