willnorris.com » yadis

improving OpenID support

Will Norris — Mon, 12 Nov 2007 07:03:26 +0000

Sam Alexander of MyVidoop emailed me last week to say that they’d be rolling out some new features in regards to OpenID support. Sure enough, you can see on the OpenID Support table that they’ve added support for xrds-header, yadis-html, and most importantly, content-type. Additionally, IDtail, a Korean OpenID provider, added support for content-type as well since I last updated the table. That’s very exciting to see providers beefing up support, as everyone really does win. For those not aware of why I harp on content-type support so much, it is the only XRDS discovery method that can be done in a single request. It allows a consumer to include a header in the request and immediately receive the XRDS document. The other two methods (using a response header, or embedding HTML code) simply advertise the location of the document, which requires a second request to actually retrieve. Sure it’s not that much more work, but every bit helps, and it reduces the risk of parser problems when using embedded HTML.

I really wish I had the time to setup some automatic detection of when provider support changes and make a blog post or something… work that benefits the community should be recognized.

How well does your OpenID Provider stack up?

Will Norris — Thu, 25 Oct 2007 21:37:15 +0000

There are increasingly more specs in the OpenID space, and many of the extensions rely on XRDS documents to publicize support. To help enable that, I’ve been looking to update my yadis plugin for WordPress to automatically include the correct protocol support for the major OpenID Providers. Of course, in order to do that I have to actually find out what all protocols they supported, so I pulled out JanRain’s OpenID library and began writing my script. I first checked all the different ways in which you can request an XRDS document… using a request header of Accept: application/xrds+xml, looking for a response header of X-XRDS-Location, looking in the tags, etc. Once I had the XRDS document, I checked which protocols they advertised support for, and compiled that all into a nice little table.

See the OpenID Support Table.

The results are about what I would expect… there are just a few front-runners that are really making an effort to support the emerging technology (likely because they are also involved in authoring these new protocols). Everyone else is supporting some version of the (technically, still current) OpenID 1.x protocol and about half have also added sreg support. That same half have basic XRDS support (since it’s required for sreg), but none of them are doing more than the most basic XRDS discovery method. Only a couple of the leaders are supporting the more advanced (and much faster) XRDS discovery.

OpenID delegation and XFN

Will Norris — Fri, 12 Oct 2007 19:51:34 +0000

I contacted the FreeYourID folks earlier this week to ask them about adding an XFN link to my forwarding page at will.norris.name. They seemed receptive to the idea and should hopefully be adding that soon. I was then telling Chris Messina about it and I think he misunderstood me, but in the process got me thinking. You see, FreeYourID does delegate OpenIDs off to MyOpenID, but the openid.delegate is the same as your FreeYourID URL. In addition to this, they have a meta refresh tag to forward web traffic to a site of your choosing (claimID in my case). I was asking for a rel="me" link for this forwarded URL be added.

But what about OpenID delegate URLs? Is there ever a case when it does not make sense to add rel="me" to an OpenID delegate? I can’t imagine that there is, since the very act of delegating is saying “this is my ID over at this other service”. With that in mind, I propose that openid delegates always include rel="me" in addition to rel="openid.delegate". Rel is a space delimited multi-valued attribute, and I’ve successfully tested a couple of different services. Here’s a concrete example of my OpenID delegation links here on willnorris.com…

I will be updating my yadis plugin to behave in this manner as well.

plugin updates

Will Norris — Mon, 01 Oct 2007 07:31:26 +0000

In trying to reach my Oct 1 goal, I did a good bit of work on two of my plugins this weekend, wp-openid and wp-yadis. For anyone that has been trying these plugins recently, please download the latest from subversion and see how they work for you. I’ve tested with Wordpress 2.3 using PHP 5.2.2 and PHP 4.4.7. I didn’t actually try Wordpress 2.2 myself, but I can’t think of any reason there should be problems. Please let me know your results in the comments here or by email.

update: I’ve also added Alexandre Passant’s nice FOAF/SIOC auto-discovery code.

wp-xrds

Will Norris — Tue, 13 Feb 2007 00:04:53 +0000

I started writing this XRDS (Yadis) plugin for wordpress several months ago, but never really finished putting in the features I had planned. With so much going on in the OpenID community the past couple of weeks, I decided to blow the dust off and clean it up a bit.

I have to say though, I’ve been very frustrated with the direction a lot of implementors seem to be going with their OpenID deployments. It seems like everyone wants to be your identity provider… they’ll hold all your data and your password, and you can use them to login to all of the OpenID sites. Even better, you get to have a spiffy cool username with their corporate branding all over it like http://openid.somecompany.com/users/joeuser/. Isn’t that great?! *sigh* While this is all well and good for a lot of people that need something like that, this completely ignores the whole user-centric identity model this is all based on. Unless a user is ridiculously devoted to your site and community, they don’t want an ID under your domain. If you’re someone like Technorati, then all of your users likely have their own blog anyway, and thus their own URL to use for OpenID! It seems that very few of the larger Identity Providers out in the wild today are really making an effort to advertise the delegation feature of OpenID, which I think is by far one of its most attractive qualities. The beauty of delegation is that someone else gets to do the grunt-work of supporting the infrastructure for actually running the IDP, but your public face is always at your own domain. Your identity is still your own… always. If a provider says mean things about your cat or won’t respond to your constant MySpace friend requests, it takes about 10 seconds to jump ship and move somewhere else. This also helps to ensure constant competition between providers to develop the best tools for managing your identity and keeping it secure. While I’m curious to see what the business model will actually be in running an Identity Provider, this model is certainly in the best interest of the end-user.

So how do you actually delegate your OpenID to another server? It’s actually relatively simple, even if you’re doing it by hand. All it requires is a couple of lines of code at the top of your webpage that identifies what server you want to use, and the ID that server knows you as. This plugin does just that, but gives you a nice interface for managing it and won’t break when you change themes. Eran Sandler actually has another plugin that does this exact thing; it’s a little simpler in implementation but he has much better user documentation in the config screens… hey Eran, you interested in working together?

Get the plugin at http://willnorris.com/projects/wp-xrds/