Address Bar

Breno breno.demedeiros at gmail.com
Thu Mar 26 06:11:28 UTC 2009


I think there is no need to explain to end user's anything about the
security of an iframe. We should simply tell the users that they
should trust the parent frame with whatever is it that they are
handing out. That is what the previous explanation boils down to.

Unless, of course, they are not handing out anything (which is the
case if they are using an authentication token instead of a password).
In which case, they just need to trust their own computer.

On Wed, Mar 25, 2009 at 8:19 PM, Johannes Ernst
<jernst+openid.net at netmesh.us> wrote:
> Now can you explain to 99% of internet users that in one case it is "more
> secure" because it is an iframe, and in another case it is "more secure"
> because it is NOT in an iframe? In our life times? ;-)
>
> I'm failing to come up with a good idea here, but this is the kind of
> education requirement that gets in the way of adoption, and in the way of
> security at the same time. We should somehow come up with a way of squaring
> that circle ...
>
>
> On Mar 25, 2009, at 18:29, Breno 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.
>>
>> 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



More information about the user-experience mailing list