[OpenID] Combining Google & Yahoo user experience research
Andrew Arnott
andrewarnott at gmail.com
Mon Oct 20 04:20:54 UTC 2008
Brandon,
You make some good points. However, consider the following non-OpenID
example:
I have managed to open a bank account over the Internet without ever showing
any photo ID. I gave my birthdate, SSN, address, and some other
information, but besides describing myself thoroughly, the bank never met me
in person. In fact, somehow they got my birthdate wrong in their database
one day and when I called in and failed to answer the challenge question
they made me fax in my gov't-issued photo ID with birthdate to prove that
they were wrong and I was really who I claimed to be. The point is that it
wasn't until my identity was in question that they ever ensured that I was
indeed a person. They seem to have not even validated the information I
initially gave them or they probably would have caught the incorrect birth
date.
Anyway after my initial registration they let me choose a username and
password, which I did. And I have ever-after used it to log in.
After I picked a username/password at my bank, the only reason my bank had
to believe that there was exactly one person on my end of the credential is
that that unseen person gave a lot of PII (personally identifiable
information) as part of the registration process. The trust mechanism was
implied that since I gave up all that information, I would want to maintain
exclusive control of my credential to that bank, and that bank trusted that
my self-interest would protect the bank as well.
So what does this mean for OpenID and actions of transactional value? Well,
as you say OpenID Identifiers don't enforce a correlation to exactly one
human being -- it could be more or less than 1. But if the bank took me
through the exact same process as I described above, but instead of asking
me to pick a username and password asked me for my OpenID Identifier, then
all the above self-interest and trust would seem to still apply. Whether an
OpenID Identifier or username/password, if either credential were stolen
from me, my assets at the bank could be stolen. I don't see one as any more
or less secure than the other -- from my perspective.
The risk to the bank in becoming an OpenID RP would seem to be that if my
Identifier was compromised and my money stolen, I might be tempted to call
the bank and blame them for giving my money away to someone else. I don't
know if that's the concern banks have or if they would be legally obligated
to refund my money, but it's a risk either way. The bank could mitigate
this risk by researching OPs and picking a few they deem trustworthy (i.e.
phishing resistant) and only allowing Identifiers to be used at the bank
that are issued by those few OPs. In fact, the banks could get together and
create one united Provider that collected my SSN, and all that PII so that I
could log into any bank's web site and (with my permission) automatically
have all that PII sent to the bank using the AX extension when creating a
new account at the bank. If the banks' united Provider took care of
verifying my PII once, each bank could trust the Provider's assertions of my
PII and my UX setting up an account would be more convenient and the bank's
costs would go down.
Personally, I feel my myopenid.com account is much more secure than any of
my banks' logins are. I can use InfoCard to log into myopenid.com and lock
my account down to only allow that. But my banks still use
username/password, which can be phished.
On Sun, Oct 19, 2008 at 8:38 PM, Brandon Ramirez <
brandon.s.ramirez at gmail.com> wrote:
> But the trust model is what makes that leap between an open id identifier
> and an actual identity. When we identify a user, we don't really care about
> the URI or XRI, we care about the identity of the remote entity. The
> identifier is just a token. It means nothing without some assurance that it
> means something.
>
> An authentication protocol that does not actually handle the authentication
> or trust is merely a validation technique. It validates that a given OpenID
> identifier *is* valid. It makes no assurances as to who it is. As a
> result, I concur that it's great for transactions of no value. Financial
> transactions needs to actually authenticate a living person, and that is
> impossible to do without an established trust model. So OpenID won't scale
> to high-security environments. Was it really only designed to work for
> blogs?
>
> - Brandon
>
>
> On Sun, Oct 19, 2008 at 1:53 PM, Martin Atkins <mart at degeneration.co.uk>wrote:
>
>> That depends on what it is you're trusting. OpenID allows you to trust
>> (man-in-the-middle attacks and phishing not withstanding) that a user "owns"
>> a given URI.
>>
>> When OpenID talks about "identity" it is that URI it's talking about. This
>> is why I tend to make a point of using the word "identifier" instead of
>> "identity", since it makes it clearer what we're talking about. An OpenID
>> identifier is similar to a social security number or credit card number in
>> that it gives you a name to call something or someone by. The OpenID
>> Authentiction protocol allows you to verify that someone is the rightful
>> owner of that name, for some definition of "rightful".[1]
>>
>> Since users can self-issue identifiers, OpenID itself can't tell you
>> anything else about a user other than that they "own" an identifier. When
>> OpenID folks talk about building trust apon this, they generally mean using
>> OpenID identifiers to identify parties in trust relationships.
>>
>> I hope this clears things up. I'd agree that some of the terminology that
>> has been historically used around OpenID is a bit confusing. In particular,
>> the text that originally said "OpenID is not a trust system. Trust requires
>> identity first" would be better stated, I feel, as "OpenID is not a trust
>> system. Trust systems are easier to build when you have globally-significant
>> verifiable identifiers." Doesn't make for quite as catchy a soundbite,
>> though.
>>
>> Cheers,
>> Martin
>>
>> [1] There is, of course, no reason why someone who owns a URL can't allow
>> everyone to be the "owner" of it per OpenID's definition. Likewise, though,
>> there's no reason why I can't put some local user credentials on BugMeNot
>> and create a "public" account that way.
>>
>> Brandon Ramirez wrote:
>>
>>> Can we have identity without trust? Can we have trust without identity?
>>> In my mind, the two are interwoven. When a person identifies themselves,
>>> we need some element of trust (if we're in person and we've met them before,
>>> our memory provides that trust, if not, a photo ID , etc.). To rephrase,
>>> I'd say that identity can technically exist without trust, but it's
>>> meaningless to us humans.
>>>
>>> Trust can also not exist without identity. If you login to my web site,
>>> a 3rd party vouches for your claim of identity. In order to trust this 3rd
>>> party, I must know who they are. If it's a random entity, then why should I
>>> trust them? It's like a driver's license. It's only a valid form of ID
>>> because it's certified by the government, and we know who the different
>>> government entities are (DMV, Department of State, etc.). If I were a
>>> bouncer checking ID's, I'd be a bit suspicious if someone gave me a driver's
>>> license issued by "State of MyFakeState". The same goes for virtual
>>> identity. Why should I trust a random OP?
>>>
>>> - Brandon
>>>
>>> On Sat, Oct 18, 2008 at 12:23 AM, Chris Messina <chris.messina at gmail.com<mailto:
>>> chris.messina at gmail.com>> wrote:
>>>
>>> I don't think that it's necessarily OpenID's job to solve these
>>> specific problems. It's really an identity protocol; trust, veracity
>>> and authenticity (in the human sense) are, by design (and by
>>> extension, politics) purposely kept out of scope.
>>>
>>> Several of our companies, mine included, operate in the space
>>> afforded by the adoption of a technology like OpenID, where you can
>>> choose to have increasing levels of complexity, encryption, circuity
>>> and sophistication to thwart those who would gain by attempting to
>>> act as though they were you.
>>>
>>> Whether you verify that you're human by receiving a $1 transaction
>>> or a 5 character text message is actually an opportunity for
>>> innovation and research, and by promoting the adoption of OpenID as
>>> a common conduit, we enable the pre-conditions for such an industry
>>> to grow up with consumer-facing services (as opposed to enterprise).
>>>
>>> My girlfriend today commented that OpenID is too hard because it
>>> requires too many steps. She wasn't talking about the authentication
>>> dance -- and she didn't even mind typing in her blog address to sign
>>> in (she's delegated to ClaimID.com). Instead her gripe was with the
>>> form-filling process *immediately* following the sign in process
>>> where, even though her OpenID provider has her name, email, bio and
>>> a bunch of other choice tidbits, the relying party either didn't, or
>>> didn't know how to, ask for it from her IdP. And since she had to
>>> re-enter this data *yet* again, OpenID as a whole ended up looking
>>> bad.
>>>
>>> The point that I'm ultimately making here is that we could sit here
>>> all day arguing over the need to secure one's identity and how to do
>>> it, but for most people, that's self-referential bike shed painting.
>>>
>>> We need this stuff to just work and get out of the way (unless a
>>> user chooses otherwise), and no user interface research is going to
>>> be complete unless we also weigh the second order benefits of
>>> time-saving and smoother flows that can come by enhancing the
>>> standards-based identity technologies.
>>>
>>> To that end, I think we need to think beyond just authentication
>>> here, and look at what happens immediately AFTER you've signed in
>>> with OpenID. How can we make that experience intuitive, compelling,
>>> desirable and motivating? How can we get it in people's heads that
>>> the OpenID experience is the one that they WANT -- and the one that
>>> they should DEMAND from their favorite web services?
>>>
>>> If we can't improve even the basic sign up and sign in flows from
>>> where they are today, indeed, we will continue struggle with basic
>>> issues like awareness and adoption.
>>>
>>> Chris
>>>
>>>
>>> On Fri, Oct 17, 2008 at 8:50 PM, Peter Williams
>>> <pwilliams at rapattoni.com <mailto:pwilliams at rapattoni.com>> wrote:
>>>
>>> This assurance/practice using email is essentially identical to
>>> the infamous dollar auth transaction, against VisaNet. If one
>>> can get an auth from VISA to allow the user a $1 credit, then
>>> you can infer the VISA number is accurate, and in good standing.
>>> It implies identity verification (and you can invoke fraud law
>>> against any law breakers).
>>>
>>> This it itself only a variant of a 100year old FBI trick, to
>>> induce someone under prosecution threat to commit formal mail
>>> fraud ... so one can get obtain leverage (incarceration, anal
>>> probing, association with the explicit violence of gangland
>>> present in holding cells etc) during a plea bargain over
>>> something much harder to prove.
>>>
>>>
>>> Attack surfaces tend to be multi-level (and that's a pun).
>>>
>>>
>>> -----Original Message-----
>>> From: general-bounces at openid.net
>>> <mailto:general-bounces at openid.net>
>>> [mailto:general-bounces at openid.net
>>> <mailto:general-bounces at openid.net>] On Behalf Of Allen Tom
>>> Sent: Friday, October 17, 2008 8:35 PM
>>> To: Dick Hardt; OpenID List
>>> Subject: Re: [OpenID] Combining Google & Yahoo user experience
>>> research
>>>
>>> Dick Hardt wrote:
>>> >
>>> > The UX of getting a verified email and then auto binding an
>>> existing
>>> > account is cleaner. It does mean that if I can prove I have
>>> your email
>>> > address, that I can take over your account. Seems to broaden
>>> the
>>> > attack surface rather then narrow it.
>>> >
>>>
>>> Hi Dick,
>>>
>>> Many sites allow an account's password to be reset by sending a
>>> Reset
>>> Token to an email address associated with the account. An
>>> attacker who
>>> gains access to the email address is able to reset the password,
>>> and is
>>> therefore able to take over the account. If the ability to reset a
>>> password is equivalent to logging in, then the attack surface is
>>> really
>>> unchanged.
>>>
>>> Allen
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net <mailto:general at openid.net>
>>> http://openid.net/mailman/listinfo/general
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net <mailto:general at openid.net>
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>>
>>>
>>> -- Chris Messina
>>> Citizen-Participant &
>>> Open Technology Advocate-at-Large
>>> factoryjoe.com <http://factoryjoe.com> # diso-project.org
>>> <http://diso-project.org>
>>> citizenagency.com <http://citizenagency.com> # vidoop.com
>>> <http://vidoop.com>
>>> This email is: [ ] bloggable [X] ask first [ ] private
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net <mailto:general at openid.net>
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>
>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081019/7e8f8e1d/attachment-0002.htm>
More information about the general
mailing list