Hi Martin,<div><br></div><div>I was thinking more about your point on how users are already accustomed to being represented by their ISP for email. You have a good point there. In fact, I've become convinced that there is no way to allow a user to maintain his own OpenID identity independent of any OP or ISP given the profile of a common Internet user today.</div>
<div><br></div><div>But then it dawned on me: InfoCard! I mean, yes of course I knew what it was before, but after fully appreciating how difficult it could be to achieve this self-hosting identity in OpenID, I came to more fully appreciate how elegantly simple and exactly right InfoCard is. The user truly is completely hosting their own self-issued cards. To the point where there is no OP or ISP in the mix <span class="Apple-style-span" style="font-style: italic;">at all</span>. Sounds pretty good to me.</div>
<div><br></div><div>Of course, I still feel OpenID has a huge space. It's easier to accept OpenID than it is to accept InfoCard for a web site (for instance: RPs don't <span class="Apple-style-span" style="font-style: italic;">have</span> to implement HTTPS for it to be secure and replay-protected for OpenID). I'm just not sure how big that space is in relation to InfoCard any more.</div>
<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Thu, Jan 1, 2009 at 7:09 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Andrew Arnott wrote:<br>
><br>
> Both of these ideals of OpenID are very worthwhile and desirable IMO. But<br>
> the second one cannot possibly come true for the average user as far as I<br>
> can imagine. There is *no* way to have a Claimed Identifier that can<br>
> withstand a change in its hosted provider unless the user owns his own<br>
> domain name. The average user won't know that they should (let alone *how*)<br>
> add a layer of indirection to their OP-provided identity page in order to<br>
> give themselves greater flexibility in the future and avoid vendor lock-in.<br>
><br>
<br>
</div>As with most things in OpenID, we can look to email for inspiration.<br>
<br>
Email suffers a similar problem. Most users get their email address from<br>
a provider whose domain is reflected in the email address. How do users<br>
deal with this problem for email? There are a number of answers:<br>
<br>
* They don't. Most users are quite happy with the idea that they're<br>
attached to a specific provider and that their email address will change<br>
if they move providers.<br>
<br>
* Third-party services provide the layer of indirection. This can either<br>
just be another service provider domain such as <a href="http://bigfoot.com" target="_blank">bigfoot.com</a> (though<br>
arguably this doesn't solve the problem at all) or an all-in-one<br>
"register a vanity domain with us and we'll forward your email for you"<br>
package as offered by hundreds of domain vendors.<br>
<br>
* Users buy their own domains and set up their own email servers, or pay<br>
someone else to do it for them. This is how businesses often approach<br>
this problem; most companies with more than a few employees have their<br>
own email domain.<br>
<br>
All three of these answers can equally apply to OpenID. The second<br>
relies on a service that is not commonly available for OpenID today, but<br>
there are already small examples of it out there, such as <a href="http://freeyourid.com" target="_blank">freeyourid.com</a>.<br>
<br>
<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>
</blockquote></div><br></div>