The Freak Parade

This is the final post in a series of posts about managing digital identity in a .NET world. See Part 1, Part 2 and Part 3 for background and some discussion.

The Foundations

The Laws of Identity
Kim Cameron’s Laws of Identity - setting the rules for the Identity Metasystem

Introducing the Identity Metasystem
Kim Cameron introduces the Identity Metasystem

The Identity Metasystem
Kim Cameron’s white paper on the Identity Metasystem

The Architecture Journal - Issue 16 - Identity and Access
A whole issue of the Architecture Journal dedicated just to Identity. Very good issue. The PDF of the issue is here.

Digital Identity for .NET Applications: A Technology Overview
This is an in depth examination of digital identity, claims, tokens SAML and the lot, in the .net world by Dave Chappell

Zermatt Links

Zermatt Whitepaper for Developer’s
A developer oriented overview of Zermatt, its architecture and its capabilities. The first thing you should read if you are interested in Zermatt.

A New .NET Identity Class
This is a general purpose article examining the new Zermatt class library.

Implementing an Identity Provider and Relying Party using ASP.NET MVC
An end to end examination of using Zermatt to create an IP and an RP using MVC.

Using Zermatt’s claims model on WCF: ClaimsPrincipal.Current
A blog post describing how to set up Zermatt to work with WCF’s security model

Getting Down with Zermatt
A nice, brief introduction to getting up and running with the Zermatt SDK

A Visual Studio Template for Zermatt Powered Websites
Well ain’t that cool…

Steve Maine (of the MVC world) introduces Zermatt…

Zermatt: Using Forms Authentication in a Passive STS
Setting up Zermatt as a non-Windows Auth based STS

Create a Basic STS Using Zermatt
Another good article on creating an STS using Zermatt

Identity Oriented Blogs

Kim Cameron’s Identity Blog
This is THE blog for keeping abreast of the identity landscape. Kim Cameron proposed the Laws of Identity which sets up the rules for the Identity Metasystem. A very interesting blog by an identity luminary.

Least Privelege
This blog deals with many things WCF and Identity related, but is an excellent resource if you have any interest in this topic at all.

Vibro.NET
This blog is listed on the MS Connect site for Zermatt as one of two blogs to follow for Zermatt info. The other is Kim Cameron’s blog.

Claim’s Based Security in WCF

Building a Claims Based Security Model in WCF, and Part 2
This is a set of articles by Michele Leroux Bustamante describing how to set up a claims based security model in good old legacy WCF (that is, WCF prior to Zermatt).

Misc Links

Creating an STS in .NET
This is a general purpose MSDN article on creating an STS. Really it’s a short description of signing tokens and setting up a SOAP response.

Introducing InfoCard (via CardSpace)
Dave Chapell talks about CardSpace

The face of Identity is changing, as I’ve discussed in agonizing depth in Part 1 and Part 2 of this monologue. So hurrah for the Identity Metasystem, Identity  Federation and all that swinging jazz, but now what? Well, if you’re in the business of designing and building software systems and you want your applications to be able to run with the jet set you’ll probably want to be thinking about how an application should go about implementing support for externalized authentication, claims based authorization and the like. In many cases you may also want to buy or build your own Identity Provider / STS so you can have the benefits of federated identity but still keep the keys to the castle inside your organization.

If you’re on the .NET Platform, and therefore on the Microsoft platform, you have a few options available to you.

Commercial Turn-Key Solutions

Although I’m only aware of one vendor in this space, Ping Identity, I imagine there are others. Buying a turnkey solution will probably offer the least touch, most expedient route to enabling new and existing applications with the capabilities to participate in the Identity Metasystem or any other identity system. I say turn-key, but of course some integration is required. Ping Identity offers products like Ping Federate, offer highly polished, low friction components that will allow your existing IT components to play ball with partners using any of a number of federation protocols (SAML 1.1, 2.0. + more) and they have .NET client and server libraries and even offer a free trial of their stuff. If you know what you want and just want to get started, I’d recommend looking there first.

Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS) is a component that is part of Windows Server 2003, so it doesn’t add any cost. ADFS provides a framework on which you can build an STS that integrates Active Directory with external applications. I looked closely at this product at one point, and from my perspective it seemed a bit complex. Internet searches revealed that implementation of ADFS isn’t a proverbial walk in the park. As ADFS is going to be re-implemented using Microsoft’s latest and greatest identity platform called Zermatt, which I’ll talk about in a moment, you may way to hold your horses on a ADFS implementation.

WCF Claims Based Security - the System.IdentityModel Namespace

WCF has extensive support for claims based security built into it, and it is documented very well in many books and online articles, blog posts, etc. Claims based authorization in WCF (although not limited to WCF) is in the System.IdentityModel namespace. Unfortunately, however, it seems that Microsoft’s newest, shiniest identity effort (Zermatt) is not backwards compatible with System.IdentityModel. In the discussion forum on the Connect Web site for Zermatt they even called systems based on the WCF 3.0 model Legacy. So…I’m not sure building new applications using System.IdentityModel would be very future proof.

Zermatt = Identity.NET

Microsoft has released to public beta a brand new framework code named Zermatt. Zermatt is billed as providing the .NET component libraries required to easily add robust claims based authorization and interoperable identity federation capabilities to your .NET based software, as well as making it a boilerplate experience to put together a custom Security Token Service, which is really quite something. Building an STS has not historically been a simple undertaking on the MS Platform thus far. There is a very good white paper on Zermatt which goes into some depth about all of these topics that I highly recommend reading. The big downer, though, is that the Zermatt SDK won’t install on XP. It requires Vista or a Windows Server OS. However, the Zermatt SDK looks so enticing, and promises to deliver powerful digital identity management to our software with such little effort, that it may be the carrot that spurs us to upgrade our development environment from XP to Vista (or Server 2008). One way or the other Zermatt is the future for identity management on the Microsoft platform, so if you don’t take a look at it now, you’ll be taking a look eventually.

Information Cards (eg CardSpace)

I didn’t end up getting into this aspect of the identity puzzle, but one of the major issues with the current state of identity management is the proliferation of passwords and the general weakness of the username/password concept itself. Identity Selectors were invented to solve this problem, and provide a highly secure, certificate based approach to authentication that supports the claims based model and eliminates the need for using usernames and passwords entirely ( as long as all the systems you use accept cards ). Information Card’s (such as those provided by the CardSpace technology) can be issued by Identity Providers and accepted by Relying Parties. Alternatively, self issued Identity Card’s can be directly accepted by relying parties in lieu of a username/password. You can read about CardSpace here.

OpenID, OAuth

On the consumer end of things, OpenID provides an open standard that can be used by public facing web sites to allow users to centralize their identity management. Similar in concept to the original Windows Passport concept (you can still use Live ID, the Passport successor, if you like) Open ID and similar standards allow you to design your application to delegate authentication of users to third party servers who you elect to trust. This is a gift to your users because they can manage a much reduced quantity of digital identities, have one place to manage username / passwords and change them if they become compromised, and more or less maintain more control over their online information. OAuth is a similarly open standard for centralizing authorization to open APIs and other web services to allow applications to create mash-ups of users data without having to ask the user for credentials for each service they wish to use in the mashup. I don’t work on consumer software, so my knowledge of these technologies is limited, but if you are working on public facing software OpenID and OAuth are probably where you want to put the tip of the Identity chisel.

So there you have it folks. Let me know if I’ve forgotten any major pieces of the puzzle. There wasn’t room in this post for the list of links, so I’ll follow up shortly with those.

Kill the User! Or, at least the Users table. As I explained in Part 1,  you’ll have a better chance of going to heaven if you do. In this post I’m going to offer my nearly-layman’s understanding of the Identity landscape as it seems to be  unfolding in the industry. The next post will be a link post, so if you tire of my rambling and ceaseless blah blah blah you can go read about some of this stuff from qualified experts.

So the question that is on everyone’s lips is this: if it no longer makes sense for each individual application to maintain its own catalog of users then what is the alternative? If you don’t maintain a list of users and what roles they have, how will you determine what they should or shouldn’t be able to do? If you don’t examine their usernames and passwords, how can you be sure they are who they say they are? Or, maybe it is time to abandon access control in computer systems entirely, issue in a new age of freedom and love, a sort of modern day hippie revolution? No?

Then welcome to the Identity Metasystem. The Identity Metasystem is an architectural arrangement that classifies Identity related activities into three distinct roles and specifies the interoperable protocols (all smelling strongly of SOAP and WS-*) available to each role when conducting Identity related business with each other. These three roles are:

1. Identity Provider (IP)
2. Relying Party (RP)
3. Subject

The basic idea is that if your system is participating in the Identity Metasystem, as all good, socially responsible systems strongly consider doing, you agree to relinquish control of authenticating your users and delegate that task to specialized systems, or Identity Providers (IP). Systems giving up their Users table that are now relying on an IP to authenticate their users are Relying Parties (RP). The users actually being authenticated by an IP in order to gain access to an RP are Subjects. To make all this a little more clear, I offer a parable:

A Subject walks into an RP and says ‘Give me a pint of your strongest data.’ The RP looks suspiciously at the Subject and says ‘wait just a minute buddy, I don’t have the foggiest idea who you are…’  The Subject pulls out his username and password and holds them out to the RP, who waves his hands in front of his face and shouts ‘Don’t show them to me! I don’t want to see your freaking password, show your credentials to the IP! So the Subject turns to the IP sitting at the next barstool and shows him his username and password. The IP examines the Subject’s credentials, sees they are valid, and initiates a complex series of hand signals that look a lot like gang signs. The RP compares the hand signals to a set of approved hand signals in a little book he keeps behind the bar and verifies that he trusts this particular IP. Satisfied, he serves the Subject his data.

To make this work the various roles in the Identity Metasystem  get on with each other by following the Laws of Identity as formulated by Kim Cameron, an architect at Microsoft and an Identity luminary. Additionally, all Identity funny business is transacted using interoperable, WS-* based protocols like WS-Trust and WS-Federation, allowing complete freedom in platform and technology choices when building or migrating systems to participate in this New World Order.

Claims Based Authorization

Many, if not most, existing systems rely on Role Based Authorization to authorize user activity. Role Based Authorization is often very specific to an individual system - the system stores what roles a user has, and looks up those roles when a user logs in to make decisions about what that user can do. This is all good and well, but it isn’t exactly practical in a system that has outsourced its authentication to an IP (even if the IP is controlled by the same organization as the system in question) because individual software systems don’t own their users in the Identity Metasystem - the IP’s maintain user records on behalf of users of multiple systems.

The solution is for the IP’s to maintain what roles a user has, and those roles will travel from system to system along with the user. And instead of just having a flat list of roles, users travel around with all kinds of useful information that might be useful to RP’s wanting to make authorization decisions, like a users age or how long an employee has been with the company. These bits of information are known as Claims. A Claim is really nothing but a name value pair, but like ID cards in a person’s wallet, all of this identifying information is always with the user. At any time a Relying Party can examine the authenticated user’s set of claims to make an authorization decision. In the end this way of working is infinitely more  flexible and sociable than the old way.

From a technology perspective, claims are represented and transmitted as encrypted, signed interoperable tokens (usually SAML - Security Access Markup Language) that are issued upon request by the Security Token Service (STS) of an IP and presented to a Subject to give to an RP. Alternatively tokens may be provided directly to the RP once the user has been authenticated.

I think that is more than enough for now. Next post I will talk about specific technologies in the Microsoft world that can make building this kind of functionality into your own applications pleasantly easy, as well as give a very brief overview of Identity Selectors, such as Windows Card Space, and where that technology fits into this picture. And of course the usual collection of links. Next: Part 3 and Part 4.

Another free e-book is available to the knowledge thirsty among you. This time it is Data Structures & Algorithms, a topic which nicely compliments some of the other free e-books that have become available recently. With free learning materials like this around, why waste your money on college? If you’re currently in college, drop out now. If you’ve already graduated, demand a refund! Instead, read Data Structures and Algorithms to get your foundations in computer science, then Foundations of Programming to become familiar with how modern, forward thinking .NET systems are built, and follow it up with Domain Driven Design Quickly to top off your education in cutting edge object oriented design. You can add some spit-shine to your newly enlightened brain with Service Oriented Architecture - Getting It Right and a free subscription to The Architecture Journal. BAM! You’re a high priced, SOA savvy Enterprise Architect with a swagger in your step and farts that smell like french perfume.  And you haven’t dropped a dime on college.

I have uploaded a new project, Simple Expression Evaluator, to Codeplex. I haven’t had time to create any documentation yet, but as usual the project contains unit tests and a sample application to play with. Simple Expression Evaluator abstracts the the parser+compiler from the object model, allowing any kind of parser to be used to construct expressions. Simple Expression Evaluator works by converting an Abstract Syntax Tree into an Expression Tree and evaluating the expression tree. A discussion of dynamic expression evaluation and links to resources can be found here. It is very simple to add new language elements, operators or functions, and comes with an array of options for plugging in custom variable evaluators or function evaluators by either implementing an interface or by associating events with delegates. 

Simple Expression Evaluator’s default parser and expression language use the Irony.net Compiler toolkit. The expression language itself is a modified, stripped down version of Script.NET (S#) and supports things like array indexers and aggregate functions such as Sum, Avg, etc that can be used on collections. Here is a screen shot of the sample app:

Ernst Naezer has generously contributed some very welcome enhancements to the Simple State Machine that adds new extensibility points and support for database workflow persistence, allowing the default file system workflow persistence mechanism to be replaced. Ernst has also provided a nice, concise tutorial on using this new feature with Castle ActiveRecord. The tutorial even contains a fully functional sample application demonstrating the persistence technique. I will probably add the sample to the main project at some point, but for now the sample can be downloaded from a link on wiki page.

Thanks to Ernst for all his hard work on this library.

Identity is a big topic now-a-days. Not the identity you go backpacking across Europe to discover, but the kind of identity that a computer system uses to determine whether to allow itself to be queried or manipulated by one incoming connection as opposed to another. (Sounds kind of dirty, doesn’t it?)

As the World Wide Web continues its imperialistic drive to connect every electronic device on the planet to every other in Borg-like fashion (if you’ll permit me to lapse into slobbering geekatude) the momentum behind technology focused on Digital Identity is finally starting to catch up.

What’s wrong with digital identity the way that it is? Well, while you can access any of a billion different computer systems from your cell phone in the middle of a swamp in the Australian outback, you’ll still have to scrunch up your eyes and punch in half a dozen username-password combinations on your tiny keyboard as you move from system to system - a strange contrast. On the one hand almost godlike connectivity, bordering on omnipotence, and on the other a sad comedy of "forgot-my-password" links and identity theft. Power and Stupidity - fused together to form something as irritating as it is dangerous (see figure 1 to the right).

Affectionately known as  password hell, this kind of arrangement has implications far more sinister than simply being tremendously annoying. The cost to IT organizations and help-desks trying to support this unsupportable user-experience nightmare is huge, system integration is made much more difficult and expensive than it would otherwise need to be, and the privacy and security implications of your sensitive user information and login credentials being stored in n number of individual databases across the Internet protected by varying and unpredictable degrees of security are frightening. Then there’s just the good old fashioned loss of productivity that results from the high friction computing experience caused by the need for overly complex identity management.

So the 30,000 foot view of the root of the problem is this: most independent software applications maintain ownership of a proprietary user directory to authenticate and authorize access to themselves. (Applications that live entirely inside the corporate firewall will often rely on a shared infrastructure level directory service to synchronize or share user identity between internal applications, but this is not always the case for every application, and as Software as a Service and Cloud Computing begin to conquer the universe, the number of applications that have the luxury of living entirely within the firewall will get smaller and the number of applications living in the wild will get larger and larger. This is unavoidable.)

The 30,000 foot view of the solution is this: most independent software applications will need to give up the snuggly comfort of proprietary, internal user directories and delegate responsibility for authenticating and identifying their users to specialized, centralized systems designed for exactly that and nothing else.

Such externalized authentication systems are often referred to as Identity Providers and are implemented via a kind of server called a Secure Token Server (STS). The concept of a software application accepting authentication decisions made by a separate (though trusted) system is called Identity Federation.

Software developers, by and large, are control freaks, so this solution may be difficult for many of us to accept. We may clutch our Users table to our chests and scream "Don’t take my baby!" in a Southern accent, but in the end it won’t do us any good. As momentum behind identity federation increases both businesses and end users alike will quickly lose what is left of their rapidly deteriorating patience with any software application that insists on authenticating them personally.

Fortunately the technology part of the problem is essentially solved. In Part 2, Part 3 and Part 4 I’ll explore some of this technology, particularly the kind of stuff likely to be useful to those working with .NET. I’ll also take a closer look at the long-overdue replacement for Role Based Access Control: Claims Based Access Control, a style of determining what permissions a user has in a system that goes hand in hand with modern implementations of identity federation and the standards and protocols that enable it (such as SAML). Claims Based authorization is more powerful and more flexible than role based authorization, and so provides significant advantages even outside the context of identity federation.

Identity is no longer something that can be a foregone conclusion in the design of a new application. The old, loyal Users table with her gout-filled username and password columns is showing her age. The old girl is having trouble coping in a hyper-connected world. Time to tell the doc, "Pull the plug! For gods sake man, put her out of her misery! That just ain’t no kind of livin’!" And then it’s time to try something new.

 Our team has recently embarked on the construction of a new application that is to be delivered using the SaaS model (hey, it’s what all the cool kids are doing.) As with nearly any modern software application, especially one delivered from the omnipotent Cloud, this new application must be able to integrate with systems and participate in process automations that are outside of its firewall. Additionally, because the model is SaaS, the application must be multi-tenant.

Strictly speaking, what we’re building is an almost feature for feature re-write of an existing application. However, the original app was written half a dozen years or so ago and even that effort was mostly just a port to ASP.NET from an even older classic ASP web site. My oh my how the computing environment has changed since then. Looking back it feels to me like the difference between putting together a model airplane and building an F-16.

Any line of business application being grown in the modern world that is expected to participate in modern process automations ends up being more like a bush or a tree than an n-layer cake. You can’t just bake the thing, slop on a little icing and throw it on the dinner table. It has to be grown in layers from a carefully considered seed and surgically grafted onto the living, thriving root system of an existing technological and human powered ecosystem.

I was rather taken aback, when I started to lay all this out in my mind, how many facets there are to building a “simple” business app in today’s day and age. To try and get some grasp on the big picture (which, thankfully, isn’t the most complicated big picture out there) I ended up mind mapping my understanding of your basic multi-tenant line of business app. It is a very rough sketch, and I intend to refine it as time goes on. Some of the nodes on the map have links to previous blog posts of mine or external resources, and I intend to add blog posts for many more of the items in this diagram as I get to those aspects of our own software. The next item on the agenda is Identity Management. If you have any suggestions, corrections or comments, I’d love to hear them. You can go to a full screen version of the mind map by clicking this link.

BTW - this was done using a combination of Mindjet Mind Manager and MindMeister.

One week ago today a small rag tag team of grizzled,  war-weary .NET programmers huddled before a filthy white board clutching a copy of The Art of Agile Development  and a stack of dog eared, grease streaked story cards. An un-built, un-specified software system stretched out endlessly before them like a hole in the fabric of time, a  yawning chasm of unknown depth, and on the other side awaited another unspecified, un-built system, and on the other side of that yet another, and another, and another…

Man, I should have been a novelist. I really missed the boat with this programming gig. Anyway, today marks the end of our small team’s bold foray into Agile development, a one week long XP iteration that took us from a blank Visual Studio 2008 solution to an end-to-end Walking Skeleton of our fledgling system complete with a Domain Model, a fully configured infrastructure incorporating an ORM and an IoC, a living service layer exposing a REST API via WCF  which powers an ASP.NET MVC front end utilizing a custom implementation of the ASP.NET Membership Provider to authenticate users against the API rather than a database local to the MVC app. We didn’t have a whiteboard set up in the team room yet, so story cards migrated from one side of the wall to the other, courtesy of the miraculous substance that is scotch tape. Not all of the task cards made the journey, but 90% of them did, and all of the cards directly related to the operation of the walking skeleton were among the survivors. Tomorrow morning we’ll have our retrospective and plan the next iteration.

The verdict? It was pretty amazing, actually. Our team had made a few false starts in the past, attempting to “ease into Agile”, without much success. This time though we decided to go for the gusto, Pair Programming, TDD and all, and while we probably didn’t follow every XP practice down to the last detail, we did a pretty good job of sticking to the program, and I am here to say that it doesn’t take much acclamation time before the benefits of those techniques make themselves felt. Pair Programming in particular I have always viewed with a skeptical eye. My perception of Pair Programming has historically been a lot like my feelings about most reports of paranormal activity: I am willing to acknowledge the logical possibility that they are valid, but deep down I am pretty sure they are full of the old brown and stinky. Well, no more! Our productivity, despite working with technologies and tools none of us have used before in a production environment for each and every tier of the system, was outstanding.

Pair Programming is one of those things that I don’t think can be truly comprehended by reading about it or talking about it, you have to do it to understand how it focuses your attention and keeps you “in the zone” in a way that is almost impossible to achieve by yourself, especially in today’s environment of the social web, with twitter and e-mail and RSS feeds poking at your attention span all day long. The usual distractions lose almost all of their power when you’re collaborating with another person. For that same reason pair programming was a little exhausting the first couple of days; I wasn’t used to that kind of directed effort for extended periods of time.

In any case, my fears of pair programming halving the productivity of the team are fully vanquished. And the benefits don’t stop at increased focus, either - the knowledge sharing and cooperative learning is also priceless. And here’s another amazing effect that you’d never guess at - you have to see it for yourself: because we were programming in pairs, we were discussing everything we were doing out loud with our partner, externalizing the design thought process and keeping everyone dialed in to the same frequency, allowing us to correct overheard misunderstandings and clarify design decisions across pairs in real time, as the design was taking place, something that was not possible when the design activity was a silent thought process trapped inside each individual programmers brain. It may sound like a little thing, but those miniature misunderstandings and misaligned design decisions end up being big integration woes down the line.

The TDD experience was very pleasant as well. It took us all a few days to get into the rhythm, and I still wouldn’t say it is second nature yet or that we have become expert at it, but the benefits, even in such a short period of time, were tangible. We developed the application tier along with its associated infrastructure and WCF/REST API concurrently with the ASP.NET front end (with a separately configured infrastructure). The front end effort relied on stubbed proxies of the anticipated API being developed for the back end. The combination of a simple, testable, well factored API resulting from the test first approach coupled with a comprehensive test suite made integration of the two halves of the system a truly trivial experience. It was almost like zipping together the two halves of a jacket - integration was a non event.

So it was the first week. I’m hooked. We haven’t been at it long enough to gauge our velocity, or experience the benefits of short iterations, increased business-value, responsiveness to change, etc. etc, so there is still much to work through as well as to look forward to, but so far I’m more than pleased. My expectations have been exceeded.

I’ll continue to post about the experience as it unfolds, but based on this week alone, I can say this: if you are flirting with the idea of trying an Agile process, do it! And don’t play at it, like we did for  months before taking it seriously. I don’t think it is something you can dabble in, I think you need to jump in and start swimming - try all the recommended practices of your chosen flavor of Agile, and discard the ones that don’t work for your team only after experiencing them fail. I can recommend this because I would never have opted to do pair programming. I tried to add it to the back burner for out current project as well, but I was strong armed into it by our designated Agile Coach (well, not really, but I was *very* skeptical) and now I can say that as long as I’m running a team, that team will practice pair programming.

While I have nothing negative to say about the experience, I can say that I feel our successful iteration was at least in part due to a period of preparatory research. While we didn’t do any BDUF, we did do quite a bit of reading into the various components we knew we’d be using, as well as best practices, looking at reference architecture, etc. I don’t know how it would have went if we just dove in with guns-a-blazing. We didn’t know what we were doing exactly, but we had a good idea where to look when we ran into trouble. I think most agile projects must be like this - either experience or preparation heats the metal before you start whacking at it with a hammer, hoping something useful pops out. That being said, once we starting rolling this week, the story cards and associated task cards kept us from veering off into “best practice land” - spinning our wheels on making sure each pattern or tool being put into place was *just right* - a common weakness of mine that an agile methodology makes virtually (and thankfully) impossible.

So mine eyes have seen the glory, and I look forward to the journey ahead as we fumble through (XP > 1 week), invigorated and excited.

I do love this job

P.S.: I’d like to give a shout out to the following technologies and tool-sets that made this week possible: NHibernate, Castle Active Record, Rhino Commons, Rhino Mocks, NUnit, RESTful WCF (a bit complicated, but oh so powerful), ReSharper, ASP.NET MVC and Castle Windsor. And, of course, Visual Studio 2008. I apologize if I’ve forgotten anyone. I love you all!

Davy Brion recently posted about how he’s trying to ward off the fire-hose-in-your-face-while-you’re-trying-to-work effect of social media by replacing a large feed list with a (very) small set of link blogs. While that sounds nice in theory, and I can definitely relate to the urge to push the fire hose out of my face, I don’t think it would work for me as a turn-key solution. For one thing, the link blogs don’t cover all the bloggers I read, and for another I just hate to bank on the coincidence that one of the several .NET link bloggers will take a fancy to the same content I am interested in day in and day out. I routinely read posts in my reader that don’t end up in the link blogs.

One particular thing about link blogs, though, that generally doesn’t live up to direct subscriptions, is that the link blogs are usually just a long list of links - if I want a quick idea of what the post will be about, I need to click the link, which either takes me out of my reader and into the browser or changes the context of my feed reader from which I’ll have to back out to get back to the link list. If I get the feeds directly, I can read the first few sentences of the post directly in my reader and get an idea what the post is about, and if I should save it for later, read it right away, or let it slip on down the river.

Recently, though, I noticed my favorite link blog, Interesting Finds by Jason Haley, starting coming in two flavors - a “rough cut” version and a “final cut” version. The rough cut version is the usual long list of links. Then, a little later in the day, a “Final Cut” arrives - an attractively formatted subset of the rough cut with a short summary of the items! And pleasantly enough the items he chose to summarize were the ones that caused me to think to myself “hmm…wonder what that is about?”. Bravo! And I love that he’s publishing both versions, and not just switching to the final version only. Of course, it adds TWO points to the oppressive “unread item” count in my feed reader every day instead of one, but in this case it is well worth it. I’ll probably read the “final cut” first, only clicking on items I can now confidently be sure will interest me, and then skim over the “rough” cut very quickly, looking for things not covered in the final cut but that still might catch my interest.

I honestly can’t imagine how he has time to go to this kind of effort every single day, but I certainly do appreciate it, and I hope the two editions are a permanent feature of his blog as they more than double its value (at least for me).