Address Bar

Thu Mar 26 18:16:02 UTC 2009

I think the problem Visa is trying to solve is not one of security, but one
of identity.
With a typical order, you use

*your name
*your address
*your cc#
*your phone number
*your cc-expiration
*your cc security number ###

these might as well be a public cert, as someone can steal your mail, your
wallet or any number of things to get this list.

verified by visa is more like a private cert that signs the request.

i think Visa will just ask you to change your password if unauthorized
access occurs.  so, i think Visa is only trying to reduce the liability
associated with unauthorized access.  so, i think Verified by Visa, does not
prevent a bad site from stealing your password, but it does mean that you
were the person that initially leaked it, either into a bad site, or into a
good site.

I think discover card used to generate a unique credit card number for each
online purchase for a while there.  i wonder if they still do that.  in this
sense, one would go to discovercard.com and get essentially a security token
(the temp cc#) and then authorize the purchase with it. this sounds like a
request token to me.

I have also been wondering about RSA key fobs and if we might some day add
an extension that allows for out of band temp password generation like a RSA
key fob does.

the question is,

On Thu, Mar 26, 2009 at 9:18 AM, Breno <breno.demedeiros at gmail.com> wrote:

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