Address Bar

Thu Mar 26 16:01:40 UTC 2009

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090326/af2205a2/attachment-0002.htm>