I&#39;d agree with that phrasing.<div><br></div><div>Another way to think about this is that OpenID affords the opportunity for people on the web to have durable, cross-site [external] identifiers. Whether they let other people use them (as some teens let their friends use their MySpace accounts or share their passwords to each other&#39;s accounts) is up to the individual. If you want to add Fort Knox type security to proving ownership of your identifier(s), you can. It won&#39;t establish trust, which, as Brandon suggested, requires a relationship, but it does create the possibility where you can start with a basic identifier (which today, for most sites, is an email address (no trust is afforded to those kinds of identifiers either) in most cases) and then &quot;level up&quot; your level of individual security as needs demand.</div>
<div><br></div><div>The problem that we&#39;ve seen in the past is that one identity-trust-security model tends to fare poorly on the web because assumptions don&#39;t scale vertically or horizontally. Technologies like OAuth and OpenID are interesting because they solve a particular component of various domain-independent problems and then allow you to remix them to create solutions bigger than the sum of their parts.</div>
<div><br></div><div>I&#39;m not familiar with the bowels of SAML2, but from my experience, it&#39;s hard enough for people to prioritize development for a &quot;simple&quot; protocol like OpenID when they&#39;re building their consumer apps... that I can&#39;t imagine the evangelism muscle that it&#39;d require to get people to back in support for these higher order protocols, unless, of course, they&#39;re dealing with banks.</div>
<div><br></div><div>Technology robustness is only one part of the equation; you must also consider the cost to implement in for someone completely uninitiated in these concepts and technologies. It&#39;s why HTML, CSS and Javascript have won on the web... and we must keep that in mind in how we design these building blocks.</div>
<div><br></div><div>Chris<br><br><div class="gmail_quote">On Sun, Oct 19, 2008 at 10:53 AM, Martin Atkins <span dir="ltr">&lt;<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That depends on what it is you&#39;re trusting. OpenID allows you to trust (man-in-the-middle attacks and phishing not withstanding) that a user &quot;owns&quot; a given URI.<br>
<br>
When OpenID talks about &quot;identity&quot; it is that URI it&#39;s talking about. This is why I tend to make a point of using the word &quot;identifier&quot; instead of &quot;identity&quot;, since it makes it clearer what we&#39;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 &quot;rightful&quot;.[1]<br>

<br>
Since users can self-issue identifiers, OpenID itself can&#39;t tell you anything else about a user other than that they &quot;own&quot; 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&#39;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 &quot;OpenID is not a trust system. Trust requires identity first&quot; would be better stated, I feel, as &quot;OpenID is not a trust system. Trust systems are easier to build when you have globally-significant verifiable identifiers.&quot; Doesn&#39;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&#39;t allow everyone to be the &quot;owner&quot; of it per OpenID&#39;s definition. Likewise, though, there&#39;s no reason why I can&#39;t put some local user credentials on BugMeNot and create a &quot;public&quot; account that way.<br>

<br>
Brandon Ramirez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="Ih2E3d">
Can we have identity without trust? &nbsp;Can we have trust without identity? &nbsp;In my mind, the two are interwoven. &nbsp;When a person identifies themselves, we need some element of trust (if we&#39;re in person and we&#39;ve met them before, our memory provides that trust, if not, a photo ID , etc.). &nbsp;To rephrase, I&#39;d say that identity can technically exist without trust, but it&#39;s meaningless to us humans.<br>

<br>
Trust can also not exist without identity. &nbsp;If you login to my web site, a 3rd party vouches for your claim of identity. &nbsp;In order to trust this 3rd party, I must know who they are. &nbsp;If it&#39;s a random entity, then why should I trust them? &nbsp;It&#39;s like a driver&#39;s license. &nbsp;It&#39;s only a valid form of ID because it&#39;s certified by the government, and we know who the different government entities are (DMV, Department of State, etc.). &nbsp;If I were a bouncer checking ID&#39;s, I&#39;d be a bit suspicious if someone gave me a driver&#39;s license issued by &quot;State of MyFakeState&quot;. &nbsp;The same goes for virtual identity. &nbsp;Why should I trust a random OP?<br>

<br>
- Brandon<br>
<br></div><div><div></div><div class="Wj3C7c">
On Sat, Oct 18, 2008 at 12:23 AM, Chris Messina &lt;<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a> &lt;mailto:<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>&gt;&gt; wrote:<br>

<br>
 &nbsp; &nbsp;I don&#39;t think that it&#39;s necessarily OpenID&#39;s job to solve these<br>
 &nbsp; &nbsp;specific problems. It&#39;s really an identity protocol; trust, veracity<br>
 &nbsp; &nbsp;and authenticity (in the human sense) are, by design (and by<br>
 &nbsp; &nbsp;extension, politics) purposely kept out of scope.<br>
<br>
 &nbsp; &nbsp;Several of our companies, mine included, operate in the space<br>
 &nbsp; &nbsp;afforded by the adoption of a technology like OpenID, where you can<br>
 &nbsp; &nbsp;choose to have increasing levels of complexity, encryption, circuity<br>
 &nbsp; &nbsp;and sophistication to thwart those who would gain by attempting to<br>
 &nbsp; &nbsp;act as though they were you.<br>
<br>
 &nbsp; &nbsp;Whether you verify that you&#39;re human by receiving a $1 transaction<br>
 &nbsp; &nbsp;or a 5 character text message is actually an opportunity for<br>
 &nbsp; &nbsp;innovation and research, and by promoting the adoption of OpenID as<br>
 &nbsp; &nbsp;a common conduit, we enable the pre-conditions for such an industry<br>
 &nbsp; &nbsp;to grow up with consumer-facing services (as opposed to enterprise).<br>
<br>
 &nbsp; &nbsp;My girlfriend today commented that OpenID is too hard because it<br>
 &nbsp; &nbsp;requires too many steps. She wasn&#39;t talking about the authentication<br>
 &nbsp; &nbsp;dance -- and she didn&#39;t even mind typing in her blog address to sign<br>
 &nbsp; &nbsp;in (she&#39;s delegated to ClaimID.com). Instead her gripe was with the<br>
 &nbsp; &nbsp;form-filling process *immediately* following the sign in process<br>
 &nbsp; &nbsp;where, even though her OpenID provider has her name, email, bio and<br>
 &nbsp; &nbsp;a bunch of other choice tidbits, the relying party either didn&#39;t, or<br>
 &nbsp; &nbsp;didn&#39;t know how to, ask for it from her IdP. And since she had to<br>
 &nbsp; &nbsp;re-enter this data *yet* again, OpenID as a whole ended up looking bad.<br>
<br>
 &nbsp; &nbsp;The point that I&#39;m ultimately making here is that we could sit here<br>
 &nbsp; &nbsp;all day arguing over the need to secure one&#39;s identity and how to do<br>
 &nbsp; &nbsp;it, but for most people, that&#39;s self-referential bike shed painting.<br>
<br>
 &nbsp; &nbsp;We need this stuff to just work and get out of the way (unless a<br>
 &nbsp; &nbsp;user chooses otherwise), and no user interface research is going to<br>
 &nbsp; &nbsp;be complete unless we also weigh the second order benefits of<br>
 &nbsp; &nbsp;time-saving and smoother flows that can come by enhancing the<br>
 &nbsp; &nbsp;standards-based identity technologies.<br>
<br>
 &nbsp; &nbsp;To that end, I think we need to think beyond just authentication<br>
 &nbsp; &nbsp;here, and look at what happens immediately AFTER you&#39;ve signed in<br>
 &nbsp; &nbsp;with OpenID. How can we make that experience intuitive, compelling,<br>
 &nbsp; &nbsp;desirable and motivating? How can we get it in people&#39;s heads that<br>
 &nbsp; &nbsp;the OpenID experience is the one that they WANT -- and the one that<br>
 &nbsp; &nbsp;they should DEMAND from their favorite web services?<br>
<br>
 &nbsp; &nbsp;If we can&#39;t improve even the basic sign up and sign in flows from<br>
 &nbsp; &nbsp;where they are today, indeed, we will continue struggle with basic<br>
 &nbsp; &nbsp;issues like awareness and adoption.<br>
<br>
 &nbsp; &nbsp;Chris<br></div></div></blockquote></blockquote></div><br clear="all"><br>-- <br>Chris Messina<br>Citizen-Participant &amp;<br> &nbsp;Open Technology Advocate-at-Large<br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br>
<a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>This email is: &nbsp; [ ] bloggable &nbsp; &nbsp;[X] ask first &nbsp; [ ] private<br>
</div>