Best of this Week Summary 25 May - 31 May 2009

• Facebook is now also supporting registration/login via a GMail account and OpenID, see the image below. I especially like that they've implemented it with a lightbox ("popup") so the user doesn't get as much confused anymore, as was the case in the old/standard implementation where the user is completely redirected to Google or the OpenID provider's website. Note that it is actually more "Facebook Connect" like this way! See here another example where OpenID is combined with OAuth to enable a popup login.
  
  
  
• Understanding how the JVM uses native memory on Windows and Linux. The extensive article explains what native memory is, how the Java runtime uses it, what running out of it looks like (so you're not running out of heap space!), and how to debug a native OutOfMemoryError on Windows and Linux. A companion article covers the same topics for AIX systems.
  


• Quite big news was of course Google's announcement of Google Wave at the Google I/O conference. It has been built with GWT. A good description can be found here. It's open source with plugin-like APIs with many integration possibilities. See the 80 minutes video for the full details. It hopes to become the replacement for email... Servers can be run by anybody. Wonder how Google is thinking of making money with it. Ads, just like in GMail? Maybe they are going to charge you for using their Wave server instances (SAAS version)? An interview with Wave's creators can be found here. And six reasons why Wave could be game-changing.
  


• Eight generic best practices for scalable high performance systems.
  


• Are you any of these two tools with almnost the exact same name? SonarJ is a plug-in for Eclipse that helps you validate your code against a software architecture, using static analysis (free for projects up to 500 classes). And now for the confusion: check also Sonar: enables to collect, analyze and report metrics on source code. It leverages the existing ecosystem of quality open source tools (ex. Checkstyle, PMD, Maven, Cobertura …), to offer a fully integrated solution to development environments and continuous integration tools.
  

Best of this Week Summary 11 May - 17 May 2009

• About three weeks ago, a serious vulnerability was detected in OAuth: a Session Fixation Attack. This article describes how the hole was handled by the 30 or so companies offering OAuth, and how Twitter took the heat for it.
  


• More on OAuth: how to get OpenID and OAuth working on Google App Engine.
  


• Here's an interview with Bruce Eckel regarding his thoughts on the RIA landscape.
  


• A short implementation guide on how to integrate performance management into development - or more specifically Continuous Integration.
  


• Which webframework is the Dutch software company JTeam using for what type of application?
  
  
  
  • Rich Internet Application: GWT and Flex
    
  
  
  • General-purpose, public website: Wicket
    
  
  
  • Miscellaneous website: Spring MVC
    
  
  Focus of the article is on why they pick Wicket for the second category of websites.
  


• A great insight in the BBC's iPlayer innerworkings and data usage. E.g, during peak hours, it streams 12G of data per second, making a total of seven PetaByte a month! For streaming CDNs are used, and each program is created in about 14 formats.
  

Best of this Week Summary 26 January - 01 February 2009

• Part 1 of a series on how to represent XML schema types taking into account the mismatch between XML and the datatypes of a programming language.
  


• Nice non-techie explanation of what OAuth is. Plaxo and Google are now trying out a combination of OpenID for federated authentication and OAuth for the authorization process, and including the Google Contacts API in the workflow. Thus, more and more towards the Open Stack.
  


• A great series of SOA Patterns by Thomas Erl. This is the first one, a Service Façade.
  


• An interesting opensource effort to make consuming REST services more object oriented and Rails ActiveResource like with Rapa. "Rapa uses the tried and tested Jakarta Commons HttpClient and JAXB."
  


• And as the last item this week, get ready to test your websites with Internet Explorer 8, RC1 can be downloaded now and should be nearly identical to the final version.
  

Best of this Week Summary 16 December - 28 December 2008

• Great insight on Second Life's architecture. For example: "A physical server (1 CPU) is responsible for about 16 acres of land and it is connected to neighboring ones which are each responsible for another 16 acres. The server is responsible for the objects existing in its area, the scripts running, the users logged in and standing in its area". Presentation is one hour in total.
  


• There's more to REST than meets the eye. And many REST APIs are not really as REST as Roy Fielding defines it. Media type design is an important item that was not in his original REST dissertation. Some interpretation of what Roy actually means can be found here.
  


• JanRain (known for their OpenID libraries) have created a nice widget named RPX that allows you to integrate authentication within your existing site in an easy and user-intuitive way. I really like the clear, easy and non-intrusive way the possibilities are shown. For real novice users the redirecting to and from the authenticating sites might still be a little bit confusing though. Supported protocols are: OpenID 1.x/2.0, Facebook Connect, MySpaceID and Google. Below is a screenshot of what the registration part looks like:
  
  A couple of example sites where this is already implemented can be found here. And some more on the possibilities here.
  Note that from the technical overview you can see that the RPX server sits in between. That is the only disadvantage of this solution: that you are dependent on an intermediate server.
  


• The W3 Consortium has released a webpage mobile-friendliness checker. The tests it performs can be found at the mobileOK Basic Tests 1.0 specification. Other validators you might know from them are the feed validator, XML Schema Validator, CSS validator or Markup validator. Running these very succesful services without any advertising is costing a lot of money. Therefore you can now donate here for support. If you compute how much time those validators have saved you, donating any small percentage of that will already help W3C keep these validators running.
  

Best of this Week Summary 15 December - 21 December 2008

• A nice and simple logical diagram of the "open stack" for the social web and how the different technologies relate, including OpenID and oAuth.
  
  
• Mostly quite valid points of criticism on the currently available Java persistence frameworks. Some more comments on the article on TSS.
  


• A bit off-track interview with Bjarne Stroustrup (designer of C++) on educating software developers and the fact that companies are complaining about the lack of skills of current computer science university graduates. Especially in the area of writing maintanable code.
  


• Google just released the free Browser Security Handbook whitepaper, which is "meant to provide web application developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers".
  


• Awesome, unit testing for Javascript with FireUnit is now available, a Firebug/Firefox extension.
  

Best of this Week Summary 04 November - 16 November 2008

• Part 2 in a series on server load architectures: application-level load balancing, including client-stickiness.
  


• How to write maintainable CSS; a presentation by Natalie Downe.
  


• ProgrammableWeb is tracking APIs and has now reached the 1000 milestone. In the pie charts you can see the top 15 categories and which protocols they use: 63% of the APIs uses REST! 22% SOAP. The protocols diagram is shown below:
  
  


• Here's some more details on why Google forked OpenID. See my related post of two weeks ago.
  


• A presentation with the current state (it's growing big time!) of OpenSocial shown at OpenSocial's first birthday at MySpace's headquarters.
  


• I'm currently trying out Wicket with Spring and Hibernate, using AppFuse Light as a starting point. In case you're looking for an introduction to Wicket, check out this one that has been around for a while, and this new one that's been posted this week.
  

Best of this Week Summary 29 October - 02 November 2008

• Lots of OpenID news this week: Microsoft Live ID will be an OpenID provider. It is still in a testing phase; you can already try it out. Google is also going to be an OpenID provider, including the use of OAuth. But that looks less promising when looking carefully: the implementation is not completely following the OpenID standards! See step 3 and 4 in the image below.
  
  A clarification on why Google has done this can be found here. Basically, two reasons:
  
  1. this way users can use their Gmail accounts instead of the normally required URLs. But a URL does exist in the form of 'https://www.google.com/accounts/o8/id'.
     
  2. Google doesn't allow OpenID for users at sign-in, because its federated login would break many of their rich-client applications. Google is working on this one.


• Whitepaper on how the JTeam company has implemented Continous Integration. Their complete list of CI tools is described; handy when you're looking for inspiration.
  


• Things to think about when considering Maven as your build tool (different angle on the post :-)
  


• Interesting posts from the Google Chrome team on the decisions they made creating the browser.
  

Best of this Week Summary 11 August - 17 August 2008

• Water & Stone survey of market share in the open source content management system market. Out of the 19 investigated, WordPress, Joomla! and Drupal came out best.
  


• Tip for when you are losing your JRuby session in a clustered environment. You're probably using in-memory storage (:memory_store) for your session, while you should be using database storage (:active_record).
  


• Beginners tips for unit testing: why do you need to do them, how etc.
  


• Three extensive articles on Java runtime performance monitoring.
  


• Reaction on an article in the New York Times on three problems with OpenID: authentication, information cards, and no adoptation.
  


• This week Yahoo! opened its geolocation platform Fire Eagle to everybody. "Fire Eagle is a storehouse for personal location information. If you tell Fire Eagle where you are, or have applications or devices that can do so on your behalf, then other applications can grab that info (with your permission) and provide you geo-related services or social network features". Another explanation here.
  
  
• This IBM Alphaworks tool automaticly generates an Ant build file after analysing your project's structure. Finally! Amongst others an Eclipse plugin. Weird part: needs Microsoft Word!!
  

Best of this Week Summary 28 July - 03 August 2008

• Introduction from google on OAuth and why you should/might want to use oAuth, including a few examples.
  


• A bit more than a week ago (July 20th to be exact), Amazon's S3 had a big outage of several hours, affecting many (startup) websites. Here's the explanation why, from Amazon. The short story: message corruption in server-to-server communication.
  


• In this blog I of course also take care of the starting software engineer :-), so here's ten concepts every software engineer should know.
  


• MySpace is now also supporting OpenID.
  


• Finally, Sun introduced the JavaFX preview SDK. Official announcement here. Below a screenshot of the demo application:
  
  
• In case you're not using it yet, definitely worth checking out this opensource LGPL static Java analyzing tool Findbugs.
  

Best of this Week Summary 19 May - 25 May April 2008

• Wow, that's quick: Spring now already supports oAuth. For a refreshment on a practical example of oAuth, see this TSS article.
  


• Two great JavaOne2008 summaries here and here.
  


• Opera's answer to Firefox's Firebug: Dragonfly.
  
  
• MyOpenID now gives you the ability for an additional security check with your mobile phone(!) when logging in with your OpenID. When signing in, you'll instantly get a call on the phone number you setup at MyOpenID and you have to answer with pressing '#'. Nice!
  

Best of this Week Summary 28 January - 10 February 2008

• Interesting idea mentioned in this post: the very basic site inursite.com validates your markup daily and you get sent the result via email or RSS. Of course during the building your site should already validate, but this site can help for Continous Integration of your front-end.
  


• Great overview of Javascript/AJAX performance issues in all major browsers (except Opera). You can use this information to know where to focus your Javascript optimizations on.
  


• This week several BIG names joined OpenID: Google, Verisign and IBM.
  


• Google's just released Social Graph API. It tries to find public relationships between people's accounts.
  

Best of this Week Summary 14 January - 20 January 2008

• Benchmark test of the Javascript performance of Opera, Safari, Explorer and Firefox. Firefox 3b2 vs Ffox 2 seems to head in the right direction too (i.e, 3 getting better and better).
  


• Article that discusses the AjaxComponent strategy to introduce Ajax into your JSF application, including a step-by-step example which uses MyFaces 1.1.5 and the Dojo. If you would handle an Ajax request via a standard JSF component method or using a phase listener, it would give you not enough control or you'd break encapsulation. Combining these two approaches you get what you want (and need): input/output logic nicely packaged in the renderer! There's also mention of a related pattern introduced by the writer: the JSF AjaxCommand strategy, which you would use if the functionality you're providing is only required by one component.
  


• An automated solution on how to implement Yahoo's Rule #3 from YSlow: setting the Expires header on your static data (images, css, javascript etc). Not obvious since it means dynamically incorporating the version nr in your CSS, javascript files for example.
  


• BIG news was of course this week the two large acquisitions: Sun buying MySQL and Oracle buying BEA Systems.
  Gigaspaces is expecting Oracle to either discontinue WebLogic or continue with little innovation. Rod Johnson from SpringSource (formerly Interface 21) is expecting (hoping?) quite the opposite: Oracle will discontinue their OC4J application server, because of WebLogic's market position. Here's some more considerations. My expection is a merge of the best of the two products. Only time will tell...
  


• Great news was of course that Yahoo! is now allowing all users to OpenID-enable their user account. It adds a total of potentially 250M new OpenID users. I still doubt it will be enough to get OpenID widely accepted, most of the points I mentioned here still apply; just allowing more users to use an OpenID is not taking these away.
  

The Future of OpenID

This is my final post in a series on OpenId. Previous posts you can find here, here, here and here.

This last post is about where OpenID is going to or might be going to, and related technologies/things that come to mind. Of course I can't see in the future, but the points described below seem quite viable to me...
Finally I'll list some more links related to OpenID I couldn't place in any other post before.

Of course you've seen the release of the OpenID 2.0 specifications. See here for what has changed from OpenID 1.0 and 1.1. One thing it supports now natively is XRI.

An intesting new specification is Open Authenthication. It provides an open standard for API access delegation. OpenID does not support this, thus this protocol seems to be a good complement for it when using APIs. OAuth has not been made an extension to OpenID because "OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords (and other credentials). If OAuth depended on OpenID, only OpenID services would be able to use it, and while OpenID is great, there are many applications where it is not suitable or desired. Which doesn’t mean to say you cannot use the two together. OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are. They should work great together."

Related to identity is being able to pass human relationships using hyperlinks. For that XFN (XHTML Friends Network) was introduced, a simple HTML microformat. Can OpenID identities in some way be integrated with this? Six Apart is trying with this demo of the so-called Social Graph.

A very relevant question is whether OpenID can converge with SAML, which both have for example different levels on user experience and (not) being a trust system. In the article some interesting viewpoints/potential next steps are discussed.

Of course the outstanding issues I wrote about in this post still apply; can they all get resolved and will this increase general acceptation of OpenID?

An interesting approach is the one Vidoop takes via MyVidoop. It is an OpenID provider, but it works with images instead of passwords. See more details here and definitely check the comments, especially this one and the ones below it. Also this one from Sam Sethi is worth reading.

And finally, here's a bunch of miscelleneaous links related to OpenID I couldn't place in any of my other posts, but are still interesting:

• The OpenID wiki
  


• Directories of sites that support OpenID: The OpenIDDirectory (you can submit your own sites) and myOpenID Directory (but you can't submit a site yourself)
  


• Two handy simple tools from JanRain, Inc to test your OpenID server and page.
  


• A howto on adding OpenID to a Rails (RoR) application
  


• A Firefox OpenID plugin
  


• This is a nice little tutorial on OpenID including a clear explanation on Yadis
  


• Here's some more cons of OpenID, some different from the ones I already listed in my previous post
  


• In an effort to get more and quicker acceptance of OpenID from users, this site Spread OpenID site has opened. Including a comparison of OpenID Providers. See of course also my comparison here.
  

Well, that concludes my series on OpenID. I hope you found it useful in some way or another!

Best of this Week Summary 03 December - 09 December 2007

• Interview with Bruce Schneider, Internet security guru on security (duh), privacy, electronic voting, encryption, passwords and more. One of the ways to attack identity theft is to not rely on authenticating the person, but on authenticating the transaction, as credit card companies do. Another thing he mentions is to *write down your passwords*, which is contradictionary to what you read everywhere; but he says, just put the paper in a safe place like your wallet! And because you write it down, you will more likely pick a strong password.
  


• Summary of this week's held Google Web Toolkit conference "Voices that matter".
  


• Nice inside view on how BT uses social software like RSS, Wiki, Podcasts etc. on their intranet.
  


• Pattern specification of the requester side caching pattern and its implementation.

  The requester side caching pattern is one of mediating the interaction between one or more clients and one or more data providers. The mediation consists of holding data items that have been produced by the provider(s) and using them to support requests from the client(s).



• Finally the OpenID 2.0 specifications have been made final and released!
  

Outstanding issues with OpenID and tips for improvements

In this fourth post about OpenID I'll try to give a complete overview of the outstanding issues with OpenID. At the end I'll give a couple of tips for improvements on the outstanding issues. You can find my previous posts here, here and here.

Not average-internet-joe ready
An OpenID is just not in the format an average user currently understands. My parents for example would not be able to "grasp" the idea of a URL being your identification. XRI is a work in progress to let people pick a username that is more or less like regular usernames like '=Paul.Smith'.

Many websites that support OpenID just point to OpenID.net (just renewed by the way, where it's now a lot easier way to find OpenID providers). From there on the user is just "on her own" to figure out what to do. This is not really OpenID's fault, but if the sites that are OpenID-enabled (consumers) are not making it easy for the user to create an account, users will just give up and sign in the "old fashioned" way. These sites should provide direct pointers to solid OpenID providers.

Delegation is quite hard to explain and understand. Even harder to actually use. It is just too hard for the average internet user to set it up. Though delegation is a real important aspect of OpenID, because it allows you to not be dependent on one OpenID provider. If you don't set up delegation for yourself from the start (because that will be your OpenID URL which you can then point (delegate) to any OpenID provider you want), you are out of luck if ever your OpenID provider goes busted.

Different OpenID providers show different, sometimes even confusing, messages when the user has to confirm the site they want to get access to. It gets even more difficult when you can assign multiple personas (see my second post for an explanation of personas). Which one to pick? And why?


Security
Of course there's the phishing issue (man-in-the-middle) that a malicious consumer site can just redirect the user to a fake OpenID provider. A solution some providers take is forcing the user to login via their regular login page first (and bookmarklet). Though it provides a small barrier, it makes the whole OpenID process just more confusing to the user. And it is not a full solution against phishing; on the phishing site, just tell the user the separate login-page has been fixed (just a bit of social engineering :-). Note that OpenID trusts DNS to direct the given URL to the correct machine; DNS servers are known for being hacked too.

There's also the replay-attack issue, where a sniffer can grab the authenticating response and replay it to the consumer. A partial barrier for that is the use of a nonce (number-used-once, see my third post for some references). Version 2.0 of OpenID should by default contain the nonce-fix for replay-attacks. This does not protect against the case that the man-in-the-middle is the first to use the resonse-URL (more a "pre-play" attack).

If an attacker gains access to a user's OpenID login, he immediately has access to all sites that user can login to; with the same OpenID/password combination.

Since all OpenID providers have the option to stay logged-in to it (thus authenticating without providing a password), CSRF attacks become very easy: no password is required.

Exploitation of an XSS flaw on trusted domains as something.CNN.com or else.microsoft.com to prevent an OpenID provider to know where the user is really signing in to. For a full explanation see "[OpenID] What's broken in OpenID 2.0? (IIW session)".

How can a consumer use OpenID in an API it provides? The consumer can not ask the user for credentials at each API call. It should ask via the OpenID provider. Work in this area is the oAuth protocol, which I'll cover a bit more in my next post about OpenID.

Privacy
Since all authentication (ownership prove of the OpenID) goes via the OpenID provider, the provider can track all the sites their users are accessing.


Improvement tips
Below I list a couple of ways OpenID can be improved to tackle the above mentioned problems:

• Integrate the flow of signing up to an OpenId provider into your consumer/relying party (OpenID enabled) website.
  
• OpenID providers should provide clarity upfront to the users whether their service will always be for free, whether it does support multiple personas etc.
  
• Consumer sites should implement OpenID more transparently. There is no need to make a distinction at registration between OpenID or not. If the user enters no password, it's probably an OpenID so try OpenID authentication, otherwise it's probably a regular signup.
  
• Find a better solution to handle phishing and replay-attacks. SSL client-certificates could be a solution, but then you'd have to bring the public-private keys to every browser and delete them again. The solution could be cryptography using private/public keys (thus not using a password).
  
• OpenID providers should not recycle inactive accounts or at least use a nonce, which the consumers should also check.
  

References
- The Identity Corner » The problem(s) with OpenID
- Beginner's guide to OpenID phishing
- Single Sign-On for the Internet: A Security Story

Hands-on experience implementing OpenID

This is my third post about OpenID. To get you started, see my previous posts here and here.
In this post I'll be providing an overview of programming libraries that implement the consumer (a site that enables an OpenID login) and/or identity provider (service/site where a user has registered her OpenID), and also my experiences with them.
For many programming languages an implementation exists (both consumer and server). Libraries are available for: Java, C#, C++, Perl, Python, Ruby, Coldfusion and PHP. For an extensive list of these libraries, see this list.

My experiences with PHP libraries
As I mentioned in my first post, I've been working on a project where I had to add OpenID to an existing site. This site was built in PHP, so I had to look for a consumer library to OpenID-enable the site.
At first I looked at the high-quality opensource OpenID libraries provided by JanRain, Inc, which you can find here. These support also older PHP versions, from PHP 4.3.0 and upwards. The site I had to add OpenID to, still runs on an older PHP version, so this requirement was met. But after trying to integrate the library, I found out that it requires many PHP extensions the customer who the site belongs to, did not want to install all of them. For example PEAR::DB is needed if you use SQLite, PostgreSQL, or MySQL to store the OpenID data. (You might wonder: who does't use PEAR::DB? Well this customer doesnt' :-) Note that you might get away with a FileStore, as mentioned in this EasyOpenID implementation.

So to make the implementation more lightweight (I only needed a consumer supporting OpenID 1.1, preferably w/o any PEAR dependency), I started to look for alternatives. The most lightweight PHP library I could find was the Simple OpenID PHP Class. The only requirement it has is CURL. Basically it is only one PHP class file. It did contain some bugs originally, in the forum of the class you can find the most up-to-date code with a bunch of fixes.
Since the site I had to modify already had existing users, I had to come up with an implementation plan that handles migrating them too. This meant allowing existing users to be able to have an OpenID too. One problem is: how do you associate them with an OpenID? We basically did the same thing as is elaborately described in this nice article from Joseph Smarr, who implemented OpenID for their Plaxo platform. A recommened read if you're about to do the same job!
Basically, the implementation of adding OpenID to an existing site is a significant task. Your users will not see much change from the outside, but internally you most likely will have to modify your login flow, your forgot password flow and your change password flow. Still, providing your users to register with an OpenID is definitely a step forward for the user-friendliness of your site.

Other libraries
My main interest lies in Java, so I was seriously interested in the Java versions of these libraries. I've looked at the code of the OpenId4Java implementation, which originally was created by Sxip and donated to the Google code system.
It supports auto-detection for OpenID version 1.1 and 2.0. If for example the consumer finds out the OpenID version supported by the provider is not 2.0, it will create a client-nonce and append it. Thus a really elaborate library. Check here for a quick introduction btw to see what a nonce is.
But sadly I've not yet been able to integrate or implement one of the Java libraries.
A few note on the Java libraries listed at openid.net:

• The idprism.org link is dead.
• The NetMesh site gives quite a few warnings about the libraries being unsupported or in pre-release.
• As mentioned above, the Sxip library can now be found at Google Code.
• The "Informed Control Schemat Consumer, AX attribute metadata retriever" is not really a consumer/provider library, but a library for parsing and generating RDF.

Conclusion
I definitely recommend the mentioned PHP class if you only need to build a consumer with OpenID 1.1 support. If you need OpenID 2.0 support, I recommend one of the JanRain libraries. If you don't want to use PEAR::DB, you might be able to get away with this EasyOpenID implementation of a consumer. If you're using CakePHP, I'd recommend checking the OpenID module built for it (I've not tried this library). I've not been able to try out any of the Java classes yet, but I'd definitely recommend checking out the above mentioned quality implementation.

Eight top OpenID providers comparison

This is my second post in a series on OpenID. See my previous post here.
For a project I did, I had to add OpenID to an existing website. One requirement of the project was that external OpenID providers should be used (thus the site would not also "be" an OpenID provider). To make sure the newly added code to support OpenID registration would work with most OpenID providers, I tested quite a few of these providers. This gave me quite a good overview of what functionality OpenID providers (should) provide, and how they compare to eachother. The OpenID providers I used for testing and this comparison are a sub-list from here.

The comparison table below lists each OpenID provider and gives a comparison of the most important features these providers (should) support. To be part of this comparison, the provider has to provide all functionality at least in English.

OpenID provider details the OpenID providers.
Version shows which OpenID version is supported. Listed will be either 1.1, and/or 2.0 (still in draft), and/or XRDS and/or Yadis.
HTTPs indicates whether HTTPs is enforced during the authentication, even if you type in the OpenID without the protocol (i.e. no leading http:// or https://).
Login redirect indicates whether the OpenID provider will allow you to login from a consumer (regular website that provides an OpenID login) by redirecting the user to the OpenID provider's login page. Already a few providers don't allow you this anymore. They will send the user to a very basic page, telling the user to first login to the OpenID provider. This page usually does not even contain a link to the login page. That page mentions that not putting a link on the page is to prevent phishing. I don't see that. How does not showing a link prevent phishing? A user would only know there is no link on that page if she has ended up on that page before. And even if she has seen the page before, would she remember that if ever ending on a phishing page with a link to the supposed login? I doubt that.
Simple registration ext indicates whether the OpenID provider supports this extension which allows very basic profile information to be passed back to the consumer. Examples are an email address and the nickname.
Personas allows you to assign a multiple of those profiles to the same OpenID (URL).
Additional features lists any specific features worth mentioning.

OpenID provider	Version	HTTPs	Login redirect	Simple registration ext	Personas	Additional features
WordPress	1.1	No	No. Shows after login whether you want to continue signing in.	Yes	1	N/a
LiveJournal	1.1, Yadis, XRDS.	No	No. But shows username + password fields on the landing page.	No, e.g. nickname is not passed back.	0. Could not find where to enter e.g nickname.	N/a
AOL	1.1, Yadis.	Yes	Yes	No	0. Could not find where to enter e.g nickname.	The OpenID takes the form of openid.aol.com/yourname instead of yourname.aol.com or similar.
VeriSign PIP	1.1, 2.0, Yadis, XRDS.	N/a	No. Does not show whether you want to continue after login.	Yes	1. At authentication you can indicate which fields should be passed back. You can also create new custom fields!	Still in beta. I do remember seeing multiple personas but it seems they dropped it. Very basic landing page if you go to the OpenID URL.
MyOpenID	1.1, 2.0, Yadis, XRDS.	Yes	Yes	Yes	Yes, many.	Very elaborate OpenID provider. Provides the most functionality. From JanRain, Inc, which also provides many libraries for implementing OpenID.
GetOpenID	1.0, maybe 1.1.	Yes	Yes	No	0. Could not find where to enter e.g nickname.	The OpenID takes the form of getopenid.com/yourname instead of yourname.getopenid.com
Videntity.org	1.0, maybe 1.1.	No	Yes	No. At least, you can fill it in on a profile page, but I noticed multiple sites not being able to find any nickname in the OpenID reply.	1	Strange that they seem to support a profile, but I couldn't get it to return for example a nickname when logging in with an OpenID. In any case, on the page where you have to allow/deny, it does NOT show any of the fields I filled in on the profile page.
ClaimID	1.0, maybe 1.1, Yadis, XRDS.	Yes when you specify the protocol in your OpenID	Yes	Yes	1. If you haven't filled in your profile, you can enter it there on the spot.	The OpenID takes the form of claimid.com/yourname instead of yourname.claimid.com.

I was really surprised to find out that not all providers perform the authentication in HTTPs. Sounds like a basic security feature that be enabled by default as OpenID provider. Also all above OpenID providers seem to be run by a commercial company. Not many non-profit versions exist (like mijnopenid.nl). This one I did not include because it is in Dutch.

If you want a free anonymous OpenID, check this Anonymous OpenID server. Note that anybody can use that anonymous OpenID since it requires no authentication!
This service lets you use your Yahoo! account as an OpenID.

Conclusion
Based upon the above table and my experience, the most secure (i.e. HTTPs), solid (not in beta) and flexible (multiple profiles) OpenID provider is myOpenID.com. Of course you should try not to be dependent on one provider and therefore use delegation; see my previous posting for an explanation of delegation.

An introduction to OpenID

Recently I've been working on extending an existing site with OpenID. In the coming weeks I'll be going into details of OpenID in different ways. This week I'm going to give an overview of OpenID and the areas of the specification that can be improved for readability. In the following weeks I'll be addressing:

• A comparison of OpenID authentication providers.
• A description of my experience implementing OpenID, including a comparison of libraries.
• Outstanding issues with OpenID (security).
• Where's OpenID going to.

In this first post I'm not going to give a full detailed explanation of OpenID. There are many sources that provide quite a good description. Here's a list of what I am not going to describe, but can be a good starting point to learn about OpenID:

• Wikipedia has a good definition:
  
  

  "OpenID is a decentralized single sign-on system. Using OpenID-enabled sites,
  web users do not need to remember traditional authentication tokens such as
  username and password. Instead, they only need to be previously registered on a website with an OpenID "identity provider", sometimes called an i-broker. Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in; OpenID solves the problem without relying on any centralized website to confirm digital identity."

• A good starting point is of course the home of the OpenID specification. You'll see there that the current version is 1.1 and 2.0 is in draft.
• The difference between SAML and OpenID. Here's a good starting point.
• Examples of major websites supporting OpenID are: WordPress, LiveJournal, AOL and Digg.

I'd like to focus on a few elements that I found not very well explained on the OpenID website. For example, not very well described (to me :-) is how the delegation of your OpenID provider works. It took me quite some investigation and looking at other sites to figure out how it exactly works. What is comes down to is that OpenID is all about you being able to prove that you are owner of a URL. And a URL is basically just a webpage. The idea is that normally that page contains a <link> tag in its HTML, within the tag, providing where your OpenID provider/authenticator is located. Say you have an OpenID account named 'mytest' at myopenid.com. Than you can actually go to the URL mytest.myopenid.com with your browser. When you look at the HTML you'll find this:

<link rel="openid.server" href="http://www.myopenid.com/server" />

Use <link rel="openid2.provider" href="http://www.myopenid.com/server" /> for version 2.0 providers

This tells you which OpenID server should be used to authenticate the URL mytest.myopenid.com. There are two major disadvantages to this:

• Maybe you want to use a different URL, not with "myopenid.com" in it. E.g. mytest.com.
• What if myopenid.com goes out of business? You can't login anymore to *any* of the sites you registered with that OpenID!

The solution for this is to use delegation. In that case the <link> tag in the page returned when going to the URL mytest.com would look like this:

<link rel="openid.server" href="http://www.myopenid.com/server" />

<link rel="openid.delegate" href="http://mytest.myopenid.com/" />

Note the additional "openid.delegate" <link> tag. In the above example it points to the myopenid.com OpenID provider and uses mytest.myopenid.com for authentication: authentication of mytest.com is delegated to myopenid.com. If ever myopenid.com is not available anymore, you can just create an account at another OpenID provider and put that in the href attribute in the above <link> tag instead of mytest.myopenid.com. This is using the essential OpenID principle that you actually own the URL. Since you can change the OpenID provider that was contained in the URL, you must be owner of the URL!

Another thing to realize is that the OpenID protocol has no failover requirements defined for OpenID providers. You as owner of the URL will have to arrange that and make sure that you can still authenticate your URL in case the OpenID provider is down/out of business. The only way you can do that is via via delegation. I find this one of the lesser things of OpenID. Delegation is quite hard to understand for "average" Internet users, thus putting the responsibility of "failover" in their (own) hands can cause quite some suprises for them.

The third area where I found the OpenID home and this other good source of OpenID information not well done is giving a good visual diagram of the OpenID protocol. Much clearer is this very detailed description of the protocol flow in OpenID 2.0, including a nice sequence diagram, in this ServerSide article. It is already discussion version 2.0, but it also applies to 1.x except the XRI/XRDS parts. Below that diagram is shown for easy reference:

Best of this Week Summary 27 May - 02 June 2007

• This article shows why you probably shouldn't use subdomains to differentiate user accounts as in http://username.mydomain.com, giving a very good reason not to if you're using SSL. Use a REST style (like on Flickr, Del.icio.us) instead, like http://www.mydomain.com/username/. A reason you *could* be using it is to prevent XSS in user generated content sites...


• How does OpenID work and how can you integrate it into your applications.
  OpenID is an open centralized authentication approach. It performs the same functionalities as SAML but is a slimmed down and lighter version to use. The article gives a good overview and also goes into the protocol details. It also shows how to implement OpenID with OpenID4Java.


• Firefox plugins are getting more and more attention of hackers via a man-in-the-middle attack. An effective way of implementing this kind of attack is by setting up your own wifi-accesspoint, let your malicious code scan for what comes by, and insert a modified Firefox plugin. SSL connections like on the offical Firefox plugins website do not run this risk (or to be more precise, very limited).


• Of course the announcement of the availability of Google's Gears was a biggie.
  
  It consists of three major components:
  LocalServer:
  Database:
  and WorkerPool (async javascript):
  Dojo Offline will be ported to move its API on top of Gears. Trying to make this an industry standard, Google is working with Adobe to get it integrated with Apollo.
  You can use the three components also seperately, you don't need to only use it for writing synchronzation software.
  Note that the workers in the WorkerPool are not threads, that is, they don't share anything with eachother, so they should be considered more as separate processes rather than threads.
  Here's a couple of nice examples with explanation on how you can use Gears.
  The question you can ask yourself is whether we should go down this Javascript road. It is so hard to create rich controls which work well always on all browsers. Are the desktop solutions (Apollo, JavaFX) the better way to go?