<div dir="ltr">Brandon,<div><br></div><div>You make some good points. However, consider the following non-OpenID example:</div><div><br></div><div>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, <span class="Apple-style-span" style="font-style: italic;">somehow</span> 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.</div>
<div>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.</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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 <span class="Apple-style-span" style="font-style: italic;">any</span> 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.</div>
<div><br></div><div>Personally, I feel my <a href="http://myopenid.com">myopenid.com</a> account is much more secure than any of my banks' logins are. I can use InfoCard to log into <a href="http://myopenid.com">myopenid.com</a> and lock my account down to only allow that. But my banks still use username/password, which can be phished.</div>
<div><br><div class="gmail_quote">On Sun, Oct 19, 2008 at 8:38 PM, Brandon Ramirez <span dir="ltr"><<a href="mailto:brandon.s.ramirez@gmail.com">brandon.s.ramirez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr">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.<br>
<br>An authentication protocol that does not actually handle the authentication or trust is merely a validation technique. It validates that a given OpenID identifier <i>is</i> 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?<br>
<font color="#888888">
<br>- Brandon</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Sun, Oct 19, 2008 at 1:53 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk" target="_blank">mart@degeneration.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
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.<br>
<br>
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]<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Martin<br>
<br>
[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.<br>
<br>
Brandon Ramirez wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div>
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.<br>
<br>
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?<br>
<br>
- Brandon<br>
<br></div><div><div></div><div>
On Sat, Oct 18, 2008 at 12:23 AM, Chris Messina <<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a> <mailto:<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>>> wrote:<br>
<br>
I don't think that it's necessarily OpenID's job to solve these<br>
specific problems. It's really an identity protocol; trust, veracity<br>
and authenticity (in the human sense) are, by design (and by<br>
extension, politics) purposely kept out of scope.<br>
<br>
Several of our companies, mine included, operate in the space<br>
afforded by the adoption of a technology like OpenID, where you can<br>
choose to have increasing levels of complexity, encryption, circuity<br>
and sophistication to thwart those who would gain by attempting to<br>
act as though they were you.<br>
<br>
Whether you verify that you're human by receiving a $1 transaction<br>
or a 5 character text message is actually an opportunity for<br>
innovation and research, and by promoting the adoption of OpenID as<br>
a common conduit, we enable the pre-conditions for such an industry<br>
to grow up with consumer-facing services (as opposed to enterprise).<br>
<br>
My girlfriend today commented that OpenID is too hard because it<br>
requires too many steps. She wasn't talking about the authentication<br>
dance -- and she didn't even mind typing in her blog address to sign<br>
in (she's delegated to ClaimID.com). Instead her gripe was with the<br>
form-filling process *immediately* following the sign in process<br>
where, even though her OpenID provider has her name, email, bio and<br>
a bunch of other choice tidbits, the relying party either didn't, or<br>
didn't know how to, ask for it from her IdP. And since she had to<br>
re-enter this data *yet* again, OpenID as a whole ended up looking bad.<br>
<br>
The point that I'm ultimately making here is that we could sit here<br>
all day arguing over the need to secure one's identity and how to do<br>
it, but for most people, that's self-referential bike shed painting.<br>
<br>
We need this stuff to just work and get out of the way (unless a<br>
user chooses otherwise), and no user interface research is going to<br>
be complete unless we also weigh the second order benefits of<br>
time-saving and smoother flows that can come by enhancing the<br>
standards-based identity technologies.<br>
<br>
To that end, I think we need to think beyond just authentication<br>
here, and look at what happens immediately AFTER you've signed in<br>
with OpenID. How can we make that experience intuitive, compelling,<br>
desirable and motivating? How can we get it in people's heads that<br>
the OpenID experience is the one that they WANT -- and the one that<br>
they should DEMAND from their favorite web services?<br>
<br>
If we can't improve even the basic sign up and sign in flows from<br>
where they are today, indeed, we will continue struggle with basic<br>
issues like awareness and adoption.<br>
<br>
Chris<br>
<br>
<br>
On Fri, Oct 17, 2008 at 8:50 PM, Peter Williams<br></div></div><div><div></div><div>
<<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a> <mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>> wrote:<br>
<br>
This assurance/practice using email is essentially identical to<br>
the infamous dollar auth transaction, against VisaNet. If one<br>
can get an auth from VISA to allow the user a $1 credit, then<br>
you can infer the VISA number is accurate, and in good standing.<br>
It implies identity verification (and you can invoke fraud law<br>
against any law breakers).<br>
<br>
This it itself only a variant of a 100year old FBI trick, to<br>
induce someone under prosecution threat to commit formal mail<br>
fraud ... so one can get obtain leverage (incarceration, anal<br>
probing, association with the explicit violence of gangland<br>
present in holding cells etc) during a plea bargain over<br>
something much harder to prove.<br>
<br>
<br>
Attack surfaces tend to be multi-level (and that's a pun).<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a><br>
<mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>><br>
[mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a><br>
<mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>>] On Behalf Of Allen Tom<br>
Sent: Friday, October 17, 2008 8:35 PM<br>
To: Dick Hardt; OpenID List<br>
Subject: Re: [OpenID] Combining Google & Yahoo user experience<br>
research<br>
<br>
Dick Hardt wrote:<br>
><br>
> The UX of getting a verified email and then auto binding an<br>
existing<br>
> account is cleaner. It does mean that if I can prove I have<br>
your email<br>
> address, that I can take over your account. Seems to broaden the<br>
> attack surface rather then narrow it.<br>
><br>
<br>
Hi Dick,<br>
<br>
Many sites allow an account's password to be reset by sending a<br>
Reset<br>
Token to an email address associated with the account. An<br>
attacker who<br>
gains access to the email address is able to reset the password,<br>
and is<br>
therefore able to take over the account. If the ability to reset a<br>
password is equivalent to logging in, then the attack surface is<br>
really<br>
unchanged.<br>
<br>
Allen<br>
<br>
<br>
_______________________________________________<br>
general mailing list<br></div></div>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><div><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
_______________________________________________<br>
general mailing list<br></div>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><div><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br>
<br>
<br>
-- Chris Messina<br>
Citizen-Participant &<br>
Open Technology Advocate-at-Large<br></div>
<a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> <<a href="http://factoryjoe.com" target="_blank">http://factoryjoe.com</a>> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<<a href="http://diso-project.org" target="_blank">http://diso-project.org</a>><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> <<a href="http://citizenagency.com" target="_blank">http://citizenagency.com</a>> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br>
<<a href="http://vidoop.com" target="_blank">http://vidoop.com</a>><div><br>
This email is: [ ] bloggable [X] ask first [ ] private<br>
<br>
_______________________________________________<br>
general mailing list<br></div>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><div><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></blockquote>
<br>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br></div></div>