Last week, we released the source code to django-openid-auth. This is a small library that can add OpenID based authentication to Django applications. It has been used for a number of internal Canonical projects, including the sprint scheduler Scott wrote for the last Ubuntu Developer Summit, so it is possible you've already used the code. Rather than trying to cover all possible use cases of OpenID, it focuses on providing OpenID Relying Party support to applications using Django's django.

David: taking a quick look at Google's documentation, it sure looks like OpenID to me. The main items of note are: It documents the use of OpenID 2.0's directed identity mode. Yes this is "a departure from the process outlined in OpenID 1.0", but that could be considered true of all new features found in 2.0. Google certainly isn't the first to implement this feature: Yahoo's OpenID page recommends users enter "yahoo.

I've been playing with OAuth a bit lately. The OAuth specification fulfills a role that some people saw as a failing of OpenID: programmatic access to websites and authenticated web services. The expectation that OpenID would handle these cases seems a bit misguided since the two uses cases are quite different: OpenID is designed on the principle of letting arbitrary OpenID providers talk to arbitrary relying parties and vice versa. OpenID is intentionally vague about how the provider authenticates the user.

On the OpenID specs mailing list, there was another discussion about using email addresses as OpenID identifiers. So far it has mostly covered existing ground, but there was one comment that interested me: a report that you can log in to many OpenID RPs by entering a Yahoo email address. Now there certainly isn't any Yahoo-specific code in the standard OpenID libraries, so you might wonder what is going on here.

The following article discusses ideas that I wouldn't even class as vapourware, as I am not proposing to implement them myself. That said, the ideas should still be implementable if anyone is interested. One well known security weakness in OpenID is its weakness to phishing attacks. An OpenID authentication request is initiated by the user entering their identifier into the Relying Party, which then hands control to the user's OpenID Provider through an HTTP redirect or form post.

It looks like the OpenID Authentication 2.0 specification has finally been released, along with OpenID Attribute Exchange 1.0. While there are some questionable features in the new specification (namely XRIs), it seems like a worthwhile improvement over the previous specification. It will be interesting to see how quickly the new specification gains adoption. While this is certainly an important milestone, there are still areas for improvement. Best Practices For Managing Trust Relationships With OPs

In my previous article on OpenID 2.0, I mentioned the new Attribute Exchange extension. To me this is one of the more interesting benefits of moving to OpenID 2.0, so it deserves a more in depth look. As mentioned previously, the extension is a way of transferring information about the user between the OpenID provider and relying party. Why use Attribute Exchange instead of FOAF or Microformats? Before deciding to use OpenID for information exchange, it is worth looking at whether it is necessary at all.

One of the issues that the OpenID 1.1 specification did not cover is the fact that an identity URL may not remain the property of a user over time. For large OpenID providers there are two cases they may run into: A user with a popular user name stops using the service, and they want to make that name available to new users. A user changes their user name. This may be followed by someone taking over the old name.

Most people have probably seen or used OpenID. If you have used it, then it has most likely that it was with the 1.x protocol. Now that OpenID 2.0 is close to release (apparently they really mean it this time ...), it is worth looking at the new features it enables. A few that have stood out to me include: proper extension support support for larger requests/responses directed identity attribute exchange extension support for a new naming monopoly I'll now discuss each of these in a bit more detail

The new Canonical Shop was opened recently which allows you to buy anything from Ubuntu tshirts and DVDs up to a 24/7 support contract for your server. One thing to note is that this is the first site using our new Launchpad single sign-on infrastructure. We will be rolling this out to other sites in time, which should give a better user experience to the existing shared authentication system currently in place for the wikis.