needs the DOR thing, the DMV thing, etc., [and] so if there are five [passwords] for each citizen, then that's either managing 8 million names and password pairs -- or 40 million.

It doesn't bother me that I might have to type that same name and password 10 times a day, as long as it's the same name and password.

We make this practically transparent, and in many cases, it's only a few lines of code. That's easy. Passing certificates around so once you've logged in -- you're always logged in. That's hard. That is technically hard. It would be equivalent to boiling the ocean, you'd never get there.

As we get more portal-based interfaces and more things that allow us to walk through those portals and build in that way so the credentials pass through and get handed, then it might get easier. But why would I want to give up 90 percent of the benefit by struggling with that really hard technical piece when I can bring both end-users and the systems very significant benefit and security?

Looking at the differences between now and the first effort, for the ID management technology, is it pretty much the same or is the technology different now?

We kept the same licenses. When we took a look at reinvigorating the project, there are a couple of things out there. The software we had licensed still held a very significant portion of the market share.

We took the licenses we had; we spent a significant amount of money strengthening the underlying infrastructure; we replicated things; we invested a lot of effort and significant money in bringing the application up to speed; we did some enterprise licensing for things like LDAP [lightweight directory access protocol] directories so we can deploy them without significant additional cost.

We did a number of things and made some investments in our capability and in our infrastructure, and we keep it up. It can become -- if you're not careful -- a serious single point of failure. So you want to mitigate that, both with resiliency and survivability in your application itself and in many cases, like our ERP system. It has its own set of LDAP directories that it will run off of, and we'll sync with it.

If for some reason our ID management system goes down, the only thing they can't do is change names and passwords. They'll still run totally without it. That's important for survivability and performance.

Do you have any plans for anything like biometrics or public key infrastructure?

We do have plans. We are in the later stages of planning two-factor authentication. We do need, in some cases, a two-factor authentication. We will be implementing that, and that could proceed to biometrics if necessary. And this is where the potential for Real ID comes in. A Real ID could be viewed as not much more than a well authenticated second-factor authentication that everybody had ...

... Ideally I think, according the government anyway...

We thought about this. We know and knew about the Real ID stuff coming. But first off, it's not very well defined to me yet.

Not to anyone.

Secondly it's not a DMV problem. It's a statewide problem. Nobody is going to make those deadlines, I believe. I don't think anybody is going to come close to those deadlines.

Do you believe North Carolina will be Real ID-ready in May 2008?

Not a chance. We need a way to manage identities across our state employee population and across our citizens -- and we need it sooner than waiting till 2008 to even figure out what's going on. All the investment we've made in this,

Chad Vander Veen  |  Editor, FutureStructure

Chad Vander Veen is the editor of FutureStructure.com