Fixing the OpenID login user experience

The user experience of OpenID at Relying Party web sites is so important to get right.  OpenID is right for your web site's visitors – no doubt in my mind about that.  But we need to make sure it's very easy for your visitors to use so you don’t lose them when they've been pre-wired for the password anti-pattern. 

Several big companies like Yahoo and Google have invested a lot of effort into figuring out how to present OpenID in a way that a user that is unfamiliar with OpenID can quickly learn or simply use.  The irony is that perhaps the best way to get people using OpenID is to not even tell them that that is what they’re using!  The sad truth is that users have been trained to trust web sites and passwords – both bad things.  We can’t undo that damage and also convince them that learning OpenID is worth their time at the same time.  So instead, webmasters can focus on fixing web sites to avoid the password and individual user account problem using OpenID – without telling the user. 

Some years down the road, users may have figured out the underlying protocol, or might not.  But who cares, really?  How many users put http:// in front of their web addresses but have no idea what it means?  There is a lot of power in OpenID that can (currently) only be harnessed if users understand OpenID and how to leverage it.  But making this power easier and safer to use will take time.  In the meantime, let’s make the parts of it that have been solved from a UX point of view well used so web surfers get used to the right way to do things.

To that end, I’ve been learning JQuery so I can write an optimally easy OpenID login UX (User eXperience).  My goal is to add the new UI to the DotNetOpenId/DotNetOpenAuth library in v3.0 or v3.1 so that it’s as easy for relying parties as just dropping in an ASP.NET control to use this super-easy UI.  Here’s a screenshot:

It’s absolutely not done yet.  And I don’t claim many original elements of this UI.  I’ve applied ideas that many other people have been coming up with and sharing with the community.  My goal in the shipping version will be to make it simple HTML with CSS that customizes everything so that theming can be applied based on the web site that’s hosting it. 

You can download and try out the interactive static HTML preview of this by downloading this zip file and opening up default.html: http://groups.google.com/group/dotnetopenid/web/openidlogin.zip. 

I really want to hear your feedback on this.  If this does get included in DotNetOpenId/DotNetOpenAuth 3.x, I want to make sure it fits your needs. If you think you’d be interested in an easy way to get this login UX on your web site please try this one out and let me know what you think of it, both good and bad.  Send your thoughts to dotnetopenid@googlegroups.com.  And drop a penny in the bucket.

DotNetOpenId v3.0 Beta 1 released

Tonight DotNetOpenId, soon to be renamed DotNetOpenAuth, released beta 1 of the major v3.0 release.  You can download the bits from Ohloh.  Although downloads should remember that as a beta this version should not be used in production, there are several new features that should be worth investigating and building a web application around while the final release is still in development:

• OAuth support (Both for Service Provider and Consumer roles.)
• RP+OP: Exceptions are now much more predictable: the host need only catch ProtocolException to handle all unexpected error cases.
• RP+OP: OpenID extensions without simultaneous authentication.
• RP: Signed callback arguments so relying parties can be confident their data was not tampered with during authentication.
• RP: Smaller authentication request messages (shorter URLs).
• OP: Ability to customize the lifetimes of each shared association type for added security.
• Over 400 unit tests (150+ more than previous version).

The biggest addition is obviously OAuth support, which is an entirely new protocol that actually has little-to-nothing to do with OpenID, except that they work great together.  To do this the entire library was rewritten on a new reusable messaging stack that both the OpenID and OAuth protocols share. 

Also keep in mind that with the product rename, the namespace has changed, and a little bit of the public API as well.  This means that this version is not simply a drop-in replacement for DotNetOpenId v2.0, and host sites will have to adjust their code accordingly.

But as always, your feedback and donations for this free, open source software are appreciated!

DotNetOpenId is looking for a new home

DotNetOpenId started on Google Code.  But we’re outgrowing it.  We’d like to move to a shared hosting server where we can have automated tests, nightly builds, and a better web site and online documentation.  This new web site will cost real money though, which is beyond my FOSS-hobby budget.

Please if you like DotNetOpenId, consider making a donation toward making this happen!

DotNetOpenId v3.0 to feature built-in OAuth support

The next major release of DotNetOpenId, slated for a release in or around March 2009, will add OAuth support to the mix.  If you don’t know what OAuth is, it basically provides a way for your site’s visitors to authorize your site to download their email address book without giving you their email address and password.  It’s of course much bigger than that, but that’s the easiest way to start thinking about it.

A little history of the last several months

The DotNetOAuth library that I started a few months ago has come a long way. Its purpose was to be a sandbox to author a new user agent redirect-based messaging framework that would serve OAuth, OpenID, and any similar framework for the future. The framework's charter included being easy, maintainable and discoverable, and very unit testable.

The framework's first application was an implementation of the OAuth protocol (thus the DotNetOAuth library name). Then I added OpenID support to DotNetOAuth, porting a few files from DotNetOpenId but mostly rewriting it all from scratch in order to take advantage of the new messaging framework. Today DotNetOAuth can do OAuth (both Service Provider and Consumer roles) and OpenID (both Provider and Relying Party roles) and I've ported the samples from DotNetOpenId over to DotNetOAuth and they work great.

This marks an important milestone for both DotNetOpenId and DotNetOAuth.  DotNetOpenId has a lot of experience out in the wild and little changes here and there to cooperate with various systems has already been made.  DotNetOAuth had the new messaging framework and added support for OAuth.  It makes sense (and in fact was part of the initial vision of what this might evolve into) to merge the two libraries so we can capture the benefits of both.

A new name for DotNetOpenId

With this merge comes a new name for the library: DotNet(OpenId) + DotNet(OAuth) = DotNetOpenAuth.  The name reflects the new capabilities of the library, and the technologies it may incorporate in the future.  Future directions may include Shibboleth, InfoCard, and the Next Big Thing for authentication and/or authorization, whatever that may be.  DotNetOpenAuth is the library to build up protocol implementations for .NET.  It is licensed under the Microsoft Public License (Ms-PL), which is a very liberal open source license that allows the software’s royalty-free use in both open source and closed source applications.

Why the new name?  That was a hard decision.  DotNetOpenId has quite a following already and there was some incentive to keep the name and leverage the momentum.  On the other hand, we want people looking for OAuth support to not pass by DotNetOpenId without considering it because of its name.  In the future we want to incorporate new protocols as well which will continue to make OpenId just one of many features the library offers.  So in the end, and after talking to Scott Hanselman and Jason Alexander about it (and getting agreement in the problem, and differing suggestions as to the proposed solution), I decided to go ahead and change the name for this major release.

In its first release(s), DotNetOpenAuth will offer an easy upgrade path for users of the DotNetOpenId v2.x releases by including the old namespace and classes in the assembly so that the new library can be dropped in and used immediately, giving webmasters the choice of when to update their code to call the new APIs.  Let me know what you think of this idea as I haven’t written these shims yet and so feedback on whether you need this would be very helpful!

What about DotNetOpenId 2.x?

Thousands of you are already using DotNetOpenId 2.x.  What does this mean for you in terms of the work necessary to upgrade to the new version?  More than usual, but not a whole lot.  First rest assured that due to its maturity and popularity, support for DotNetOpenId v2.5 (and perhaps even a v2.6) will not be cut off immediately upon the release of v3.0.  I expect to respond to bugs filed against the v2.5 versions for several months.

And when you decide to make the upgrade to v3.0, I’m working to ensure the transition will be as smooth as possible.  Although v3.0 has an all new “DotNetOpenAuth” namespace, the public API for OpenID in that namespace is very similar to the old ones in the DotNetOpenId namespace so it may be as easy as updating your “using” line in C# or “Imports” in VB.NET.  Depending on the features you were using you may have a little more work to do to get your code to compile.  Watch for a follow-up post describing the new object model and why I think you’ll like it much better than the old one even though on the outset it looks so similar. 

If there is sufficient demand for it, I’ll add a set of shims in the assembly with the old namespace so you can use all your existing code with the new library and have it Just Work.  Let me know whether you feel this feature is worth the effort.  Leave a comment, or email dotnetopenid@googlegroups.com. 

Where can one download the new version?

The v3.0 release is slated for a March 2009 release.  But watch this blog or the dotnetopenid mailing list for an announcement about the Beta 1 release in the next few days.  Of course it’s all open source, so you could download the source code to it now, but I recommend you wait a few more days so you can see it in digital shrink wrap.