Address Bar

[Breno]

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.

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