In the PC ecosystem, when a new device (say mass storage) technology is introduced, commonly there is little standardization, vendors produce proprietary software stacks for interacting with that device, they have custom hardware interfaces for interacting with the device, custom software for managing those devices, etc.

As a device picks up in popularity common platform programing interfaces typically emerge, sometimes these are commercial in nature, other times they are standards based; in either case the goals of these interfaces are simple: abstract out the variety in the hardware ecosystem for the application developer allowing them to write software that can run on any machine regardless of which vendor manufactured a given device. These abstractions also commonly allow the sharing of devices so that multiple applications can use them at the same time.

The next phase in a devices maturity is normally the definition of a class interface for interacting with hardware, it’s this last phase that allows the “no driver needed” story that users like so much; we all reap the rewards of this with flash drives today, plug in the device and it just works (the same is true for display technologies like VGA).

These class drivers commonly cater to the lowest common denominator when it comes to functionality, but vendors are always able to add additional capabilities that are exposed when their drivers and custom software are present (again think about display technologies here as a good example).

There is one device in particular that has not entirely followed this flow that I wanted to talk about and that is Smart Cards; as a concept was they emerged in the 1970s, the first cards went into production in the late 70s. Here we are 40 years later and there is no clear “class driver” for these devices, that is not to say there have not been attempts, some even with success, but those that have had success have been closed system solutions, for example the PIV interfaces used within the US Federal Government.

In the commercial space however, no class specification that has been attempted really was viable, there are lots of reasons for this but I am cautiously optimistic that there is now a candidate.

One of the projects I was working on over the last few years was the specification of the Generic Identity Device Specification, this attempts to build on the success of the government based card specifications and extend it to commercial applications as well.

I had opportunities to work with some great folks on this effort, we all had the same goal make smart cards as reliable, cost effective and accessible as possible; I believe this work does just that.

This specification has now been released by Microsoft under the Microsoft Community Promise, that means it is available royalty free for anyone to adopt; this is a big win for our partners and above all the customers who will benefit the most from it.

So what does this mean for you? Well if you’re a customer looking to deploy smart cards you should seriously look for vendors who produce cards that are compliant with this specification, it means lower cost of deployment, makes it easier for you to multi-source cards and in the end it will likely reduce the overall cost of cards as volumes go up based on function of scale.

For a card manufacturer there are a number of benefits as well, it is possible to develop a GIDS card that is compatible with the PIV card-edge, this means you can develop a single card stock get it evaluated for FIPS (or whatever other standard) that can be sold into commercial or government applications (reducing cost) and these cards will have a great experience in Windows.

If you are a platform or operating system developer you now have a specification you can use as a baseline for testing card scenarios, a way to (hopefully) support a large number of “real” cards that will exist on the market (soon I hope), if this happens we can experience driver coverage numbers similar to other device classes.

For those of you not in this segment, this last point is super important, there is so much fragmentation in the market no solution has over a couple percent of card coverage in-box, if this specification gets adopted that number can start to look more like other device classes where the number is in the 90 percentile range.

In any event, I am pleased to see this out there, here’s hoping it gets adopted broadly…