I got a note from Myk Melez yesterday who had a great question about OpenID:
Hey Scott,
I went to open an account on a web site today, and it offered to let me log in via OpenID. It pointed me to openid.net to get more info about OpenID, which told me that I can run my own OpenID provider or “use a third-party identity provider”.
My (perhaps stupid, but I’m an OpenID newbie and very much an end user for this technology) question is: what third-party identity providers can I use, and how do I pick between them?
-myk
Doing OpenID stuff all-day, every-day I sometimes forget that the answers to obvious questions aren’t all that obvious. This is question falls into that category.
As some people may know, OpenID is a decentralized protocol for doing single sign-on on the web. An OpenID is a URL that you can use to sign into sites that support OpenID. These OpenID URL’s look something like user.foo.com (for example, mine is kveton.myopenid.com). OpenID’s are served up by OpenID identity providers (sometimes referred to as an IdP). In the first example, the identity provider would be ‘foo.com’, in my case, its MyOpenID (full disclosure: MyOpenID is developed by JanRain the company I run). Because of its decentralized nature, it means anybody can provide OpenID identity services and participate in the complete eco-system. There is no membership fee to join, committee to cajole or people to convince. If you bring up an an identity provider that conforms to the OpenID specification, you can deliver OpenID’s that can be used on any site that supports OpenID’s.
There is a growing number of these identity providers in the marketplace today. The complete list can be found here. We run MyOpenID.com which we strive to be completely up-to-date with the OpenID protocol as well as delivering new features to help users do more with their OpenID’s. Verisign and claimID are also great OpenID identity providers as well. The best thing here is that consumers have a choice in the marketplace. If you don’t like your OpenID identity provider you can switch to a different one.
So what do you need to think about when choosing an OpenID identity provider? Since your OpenID is a URL, you will want to make sure you pick one that you know will be around for awhile. As you go around the Internet using your OpenID you’ll be making contributions that are linked back to your OpenID (effectively your identity). If your provider should go out of business or not keep up with features and the protocol, you could lose access to that identity that you may have spent considerable time using. You also want to look at what kind of features the identity provider has. Do they let you customize it? Control your personal data to your liking?
For the vast majority of users going with a well-respected OpenID identity provider will meet their needs. However, some people might want to use their own domain because no matter how great the identity provider is, they may not want their identity associated with it. In that case, you’ll want to look at delegation. With just two lines of HTML and your own domain, you can delegate your OpenID to any provider you like. So instead of having to use user.foo.com you could delegate you.yourdomain.com to user.foo.com and use the you.yourdomain.com to sign in at all of the OpenID enabled sites. If the user.foo.com provider goes away or does bad things, you simply change the delegation to another provider that supports OpenID. You still have you.yourdomain.com so the contributions you’ve made across the Internet will still link to you. This is definitely a great feature for “early adopters”.
I got a note back from Myk earlier today:
Yes, thanks, it helps enormously! Before this info I had no idea how to get an openID. Now I’ve got one from myopenid.com (mykmelez.myopenid.com) and am using delegation so that my ID can be melez.com/myk.
With the following two lines of HTML he was able to accomplish this:
Its that easy. Thanks for the question Myk.
Update: I’ve tried to make the delegation information more clearer. Thanks for the heads-up Ian.
After I clicked allow from myopenid, it would send me to a Wordpress login page. But then I allowed session cookies from kveton.com (by default I block all cookies) and commenting worked OK. I think you need a check whether cookies are enabled.
Also, the help for the [Allow Once] and [Allow Forever] buttons at https://www.myopenid.com/static/trusthelp.html has visible bits of dyanamic page code (“assert your identity #if $sregreq or $sregopt …”), maybe it shouldn’t be static.
OpenID is very cool! If I had a dime for every phpBB forum that made me create yet another login, I’d have $100.
Thanks for the information about OpenID… I’ve been seeing a lot of posts about it on planet.mozilla.org lately (probably all from you) and had a heck of a time figuring out how to make it work. I know have an OpenID of jacob.steenhagen.us which is delegated to jsteenhagen.myopenid.com (currently). I also installed the wpopenid plugin for WordPress (is that the one you use?) on my blog. Hopefully I can learn more about this whole OpenID thing in the near future :).
I do have one question… is a <link> tag the only way to delegate openid? I used to have jacob.steenhagen.us silently redirect to my blog, but now there’s a intermediate page with a 0 second refresh so I can put the <link> tags in. Is there a way to do that with HTTP headers instead?
You can put the links in the head of your document. You can also do this in the headers (note: different than the head) so you don’t have to land on a page and can do an automatic re-direct to your blog, web page or whatever.
Jake: yeah, I think I’m grandfathered into Planet Mozilla from when I worked at the OSL … :-)
I use the wpopenid plugin. I unintentionally scooped the author of the plugin when I found it via some blog aggregator, installed it and announced it before he had. Quite funny actually. The author was quite nice about it … :-)
As for delegation in the headers? The short answer is ‘yes’, you can do this. However, its not widely supported and requires OpenID v1.1 support at the relying parties. I’ve updated the delegation article here:
to show you how to do it in the headers. The gist of it is that you put a header that points at something called the Yadis file. The Yadis file is a means of doing discovery on what services an OpenID has and where to look for them.
One thing I’d like to hear you blog about is phishing. What’s to stop a site pretending to redirect me off to my OpenID provider, but actually sending me to a spoofed site to steal my login?
Jwatt: glad you got it setup … I’ve got in my queue to do a post about phishing. IMHO its the biggest problem we face in the OpenID community. There are some clever solutions that include user-chosen images as well as browser extensions that I’ll talk about in the post in the next couple of days.
Thanks for the information. Looks like I’m going to have to keep the ugly redirect page, at least for the time being. It looks like the wpopenid plugin doesn’t support the header-only method.
Also, I made a minor modification to my theme to indicate comments that are authenticated by OpenID. It can be seen using some of the test comments I made on the post where I announced that I had OpenID support.
I think I understand how OpenId works, but I am a little confused about its relationship to i-names.
As I understand it right now:
OpenId uses a URL
i-name uses XRI
Correct me if I am wrong please.
If this is so, isn’t XRI superior because of its permanence? Or is the i-name / XRI model locked up in a proprietary system of some kind?
My concern is that I want to form an essentially permanent relationship with my online identity (this is the whole point right?) but OpenId sounds like it is still disposable?
You are correct. The key here is that OpenID v2.0 supports resolution of i-names (or XRI’s). That means a user can enter in =user.name in an OpenID form field (like the one on this page) and have it work with their i-name.
It should be noted that my blog doesn’t yet support OpenID v2.0 but as soon as its out and the libraries are there, I’ll be upgrading.
As for which is more superior, I think that’s up to the market. I like being able to use kveton.com/blog as my OpenID URL. With i-names, I have to leverage the i-names global registry and hope that it will be around forever and ever. Also, there is a central registry for i-names that although is very well managed, it is in fact centralized.
We partnered with the i-names community to bring them on board with OpenID because we were thinking along the same lines; give users control of their identities. The technologies are different but our hearts are all in the right place.
So the relationship between OpenId and i-name is codified in a future release of OpenId and is meant to provide interoperability for i-name users.
Since i-name (and XRI are more locked into the centralized registery), do you favor OpenId (and thus provide the MyOpenId service) because of the portability of OpenId?
Can you explain what happens in the future when I have an OpenId and I decide to move to a different IdP? What if I have provided my OpenId to a large number of websites for account login (say 50+)? Will I have to change my OpenId with each website?
The process being something like this:
1. Create new OpenId with new IdP
2. Login to each account on the web and switch to new URL.
3. Deactivate (if this is possible) with my old IdP.
If this is the case, then the 50+ accounts I have to login to is going to be really tedious, like moving to a new house and having to contact all service providers to update a postal address.
I (personally) prefer OpenID’s that are URL-based but that is just my bias. I also understand the reasoning and the work done by the i-names community. In fact, we are an accredited i-broker.
Yes, the URL-based identities are not portable. However, if you use your own domain with delegation, you have the ability to move from OpenID Identity Provider to a new one and not have the pain that you mention above. Not ideal, but it does help with your problem.
In a general sense, we need to find a more complete solution to this that allows users to “transfer” their identity from provider to provider.
If delegation is a step towards making URL flavor OpenId more portable then its seems like it could be a product offered by a hosting company.
The host provides a home for both your domain name (content, e-mail, etc.) and your domain-based OpenId. That way when you transfer hosts, you would naturally transfer IdPs.
Of course, there are plenty of sketchy hosts and over time there may be plenty of sketchy IdPs. I read somewhere that OpenId should only be used for non-sensitive accounts (i.e. not providing opportunity for identity theft or access to financial information.) Or at least not yet.
Are there any other major topics of development in the OpenId arena besides security and portablity?
Rian: this is great idea and one that we are looking to pursue as a value-added service we can provide for customers.
OpenID is an evolving platform. Its quickly maturing and although it may not be ready for banking information just yet (remember when people said that about the Internet as a whole?), I believe it will be in the very near future.
The biggest topics in the OpenID world are attribute exchange and phishing at the moment. This will change over time as we hopefully figure those out.
(3rd try) I followed this post to do something similar to Mr. Melez. Testing…
After I clicked allow from myopenid, it would send me to a Wordpress login page. But then I allowed session cookies from kveton.com (by default I block all cookies) and commenting worked OK. I think you need a check whether cookies are enabled.
Also, the help for the [Allow Once] and [Allow Forever] buttons at https://www.myopenid.com/static/trusthelp.html has visible bits of dyanamic page code (“assert your identity #if $sregreq or $sregopt …”), maybe it shouldn’t be static.
OpenID is very cool! If I had a dime for every phpBB forum that made me create yet another login, I’d have $100.
skierpage: Wordpress requires the cookies for some session management it does.
We’ll take a look at the visible bits of dynamic page code that show up on the Allow Once and Allow Forever buttons. Thanks for the heads up!
I didn’t understand it until I read the “delegation” link.
It’s clearer if you mention that when you sign in, you then use your URL as the ID.
Thanks for the information about OpenID… I’ve been seeing a lot of posts about it on planet.mozilla.org lately (probably all from you) and had a heck of a time figuring out how to make it work. I know have an OpenID of jacob.steenhagen.us which is delegated to jsteenhagen.myopenid.com (currently). I also installed the wpopenid plugin for WordPress (is that the one you use?) on my blog. Hopefully I can learn more about this whole OpenID thing in the near future :).
I do have one question… is a <link> tag the only way to delegate openid? I used to have jacob.steenhagen.us silently redirect to my blog, but now there’s a intermediate page with a 0 second refresh so I can put the <link> tags in. Is there a way to do that with HTTP headers instead?
Ian: good point. I’ll update the post.
So where does one put the two lines of HTML code? On ones homepage? In the header or in the body?
Peter: take a look at this:
http://www.openidenabled.com/openid/use-your-own-url-as-an-openid
You can put the links in the head of your document. You can also do this in the headers (note: different than the head) so you don’t have to land on a page and can do an automatic re-direct to your blog, web page or whatever.
Jake: yeah, I think I’m grandfathered into Planet Mozilla from when I worked at the OSL … :-)
I use the wpopenid plugin. I unintentionally scooped the author of the plugin when I found it via some blog aggregator, installed it and announced it before he had. Quite funny actually. The author was quite nice about it … :-)
As for delegation in the headers? The short answer is ‘yes’, you can do this. However, its not widely supported and requires OpenID v1.1 support at the relying parties. I’ve updated the delegation article here:
http://www.openidenabled.com/openid/use-your-own-url-as-an-openid
to show you how to do it in the headers. The gist of it is that you put a header that points at something called the Yadis file. The Yadis file is a means of doing discovery on what services an OpenID has and where to look for them.
Thanks. Set up now. :-)
One thing I’d like to hear you blog about is phishing. What’s to stop a site pretending to redirect me off to my OpenID provider, but actually sending me to a spoofed site to steal my login?
Jwatt: glad you got it setup … I’ve got in my queue to do a post about phishing. IMHO its the biggest problem we face in the OpenID community. There are some clever solutions that include user-chosen images as well as browser extensions that I’ll talk about in the post in the next couple of days.
Kveton,
Thanks for the information. Looks like I’m going to have to keep the ugly redirect page, at least for the time being. It looks like the wpopenid plugin doesn’t support the header-only method.
Also, I made a minor modification to my theme to indicate comments that are authenticated by OpenID. It can be seen using some of the test comments I made on the post where I announced that I had OpenID support.
I think I understand how OpenId works, but I am a little confused about its relationship to i-names.
As I understand it right now:
OpenId uses a URL
i-name uses XRI
Correct me if I am wrong please.
If this is so, isn’t XRI superior because of its permanence? Or is the i-name / XRI model locked up in a proprietary system of some kind?
My concern is that I want to form an essentially permanent relationship with my online identity (this is the whole point right?) but OpenId sounds like it is still disposable?
You are correct. The key here is that OpenID v2.0 supports resolution of i-names (or XRI’s). That means a user can enter in =user.name in an OpenID form field (like the one on this page) and have it work with their i-name.
It should be noted that my blog doesn’t yet support OpenID v2.0 but as soon as its out and the libraries are there, I’ll be upgrading.
As for which is more superior, I think that’s up to the market. I like being able to use kveton.com/blog as my OpenID URL. With i-names, I have to leverage the i-names global registry and hope that it will be around forever and ever. Also, there is a central registry for i-names that although is very well managed, it is in fact centralized.
We partnered with the i-names community to bring them on board with OpenID because we were thinking along the same lines; give users control of their identities. The technologies are different but our hearts are all in the right place.
So the relationship between OpenId and i-name is codified in a future release of OpenId and is meant to provide interoperability for i-name users.
Since i-name (and XRI are more locked into the centralized registery), do you favor OpenId (and thus provide the MyOpenId service) because of the portability of OpenId?
Can you explain what happens in the future when I have an OpenId and I decide to move to a different IdP? What if I have provided my OpenId to a large number of websites for account login (say 50+)? Will I have to change my OpenId with each website?
The process being something like this:
1. Create new OpenId with new IdP
2. Login to each account on the web and switch to new URL.
3. Deactivate (if this is possible) with my old IdP.
If this is the case, then the 50+ accounts I have to login to is going to be really tedious, like moving to a new house and having to contact all service providers to update a postal address.
Yes, i-names is a part of the future of OpenID.
I (personally) prefer OpenID’s that are URL-based but that is just my bias. I also understand the reasoning and the work done by the i-names community. In fact, we are an accredited i-broker.
Yes, the URL-based identities are not portable. However, if you use your own domain with delegation, you have the ability to move from OpenID Identity Provider to a new one and not have the pain that you mention above. Not ideal, but it does help with your problem.
In a general sense, we need to find a more complete solution to this that allows users to “transfer” their identity from provider to provider.
If delegation is a step towards making URL flavor OpenId more portable then its seems like it could be a product offered by a hosting company.
The host provides a home for both your domain name (content, e-mail, etc.) and your domain-based OpenId. That way when you transfer hosts, you would naturally transfer IdPs.
Of course, there are plenty of sketchy hosts and over time there may be plenty of sketchy IdPs. I read somewhere that OpenId should only be used for non-sensitive accounts (i.e. not providing opportunity for identity theft or access to financial information.) Or at least not yet.
Are there any other major topics of development in the OpenId arena besides security and portablity?
Rian: this is great idea and one that we are looking to pursue as a value-added service we can provide for customers.
OpenID is an evolving platform. Its quickly maturing and although it may not be ready for banking information just yet (remember when people said that about the Internet as a whole?), I believe it will be in the very near future.
The biggest topics in the OpenID world are attribute exchange and phishing at the moment. This will change over time as we hopefully figure those out.
Write your comments here, please.