Address Bar

Thu Mar 26 16:18:01 UTC 2009

Verified by Visa is really a program for merchants: It makes it easier
for them to comply with regulations for safekeeping data by directly
connecting to a payment processor.

Users get a security benefit in the sense that they need to place
slightly less trust on the site: They still need to trust that the
site is not actively malicious or compromised, but they do not need to
trust in their backend data handling practices as much.

I am not sure what other verifications Visa does in the backend. Maybe
stealing your Visa credentials is not sufficient, and instead you need
to be a registered player to initiate a transaction. But I am not
familiar with the product, so I am only speculating here.

On Thu, Mar 26, 2009 at 9:01 AM, Ben Laurie <benl at google.com> wrote:
>
>
> On Thu, Mar 26, 2009 at 3:04 PM, Breno <breno.demedeiros at gmail.com> wrote:
>>
>> The idea is that you must trust the site with your verified by visa
>> credentials to start with.
>
> But that is not correct - verified by visa includes a password that the site
> doesn't know.
>
>>
>> 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
>> _______________________________________________
>> 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