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